I hope this is the right discussion to ask this:
Suppose that sys-net is remotely compromised and the PCI network connection is attacked. Could this affect other components, such as the graphics cards, though the PCI?
My understanding is that the compromise could be persistent even with a DisposableVM. Does this mean that the PCI firmware has been altered? Could this be automatically checked and fixed on boot (e.g. by rewriting the firmware)?
If an adversary compromised sys-net he could manipulate traffic on the fly, i.e. dns-queries. Any http traffic could be used to BeEF all AppVMs browsers.
I recommend at least to disable http-traffic in your AppVMs.
Another solution would be to encrypt all traffic, including DNS, going through sys-net (e.g. via VPN).
The easiest and most foolproof way to achieve this is by placing a firewall between your VPN VM and sys-net, and restricting traffic to VPN servers.
Note that this thread is nearly two years old, and some things have changed in the meantime. In particular, QSB-081 (perhaps in conjunction with other recent events) has prompted the devs to reconsider the way qubes like sys-net and sys-usb are handled.
Yes, I already use VPN. But I was asking about threats such as the XSA in your original post.
I guess it was not meant to be a response to my recent query. But just in case:
After doing some more reading it seems like my question about the remotely compromised PCI hardware could only affect the rest of the system through side-channel attacks, which I will have to read up on.
What about my question about persistence? Can compromised network PCI controller be repaired by reflashing its firmware?
I’d better buy a new one and preserve that for evidence.
How well documented / realistic is this threat? So malicious firmware in the network controller creating a vector of persistence. How much could that undermine the sys-net compartmentalization framework, isn’t the network controller already treated as hostile? Seems likely in a TAO type setup.
Is setting the firewall rules in vpn-VM for the VPN ip’s not enough?
No one seen it in the wild yet. But it is realistic to certain degree.