Question About Attack Surface and TCP/IP stack

User Support
1

In another forum, Graphene OS, there was discussion about Qubes.

Before continuing, I hope this thread can be extra respectful since it is question based on other forum and it’s good to be polite to developers of other operating systems.

A user of the Graphene OS forum wrote:

“It would be really hard but not impossible to get hacked in Qubes. If you get hacked, you just delete the VM. Graphene’s model is more to just prevent hacking of the OS at all cost, while being open source and free.”

A Graphene OS developer then replied:

“QubesOS doesn’t make it less likely that an individual application or OS running within it will get compromised. The purpose it serves is containing that compromise. It’s not hardened in the way that you’re implying.”

A user then said:

“That’s not entirely true about Qubes. The compatmentalization [sic] and containment means a hack may not ever really get past certain protections. An infected USB device connected to a minimal template [sic] may be less likely to have the attack surface to hack into the minimal template [sic].* Also networking often goes through multiple templates [sic] with an exploit needed to get to the next template. [sic]* Someone would need to escalate priviledges in the sys-net, then the firewall, and they could be minimal templates [sic] or different types of templates. Someone using a VM of an older vulnerable distro can still be hacked through the vulnerabilities in the VM or by downloading a malicious file, although it would hopefully not impact dom0, but it’s not correct to say that Qubes doesn’t offer attack surface reduction beyond containment.”

(user who posted this referred to VMs using certain templates as just “templates”)

A Graphene developer then replied:

“No, that’s completely wrong. You don’t have to go through those layers when targeting an application or the TCP/IP stack of the OS. They do not work that way. The rest is a contrived counterexample rather than a real world example. QubesOS does not only reduce attack surface but also increases it. Having multiple distributions involved adds attack surface too.”

The question is whether others agree that TCP/IP stack can be attacked without targeting multiple VMs so that TCP/IP stack can be compromised for a VM like Disp-Whonix-WS by compromise for sys-net, including if there are different templates (such as minimal gentoo for sys-net and Fedora for sys-firewall). When reading this did not understand Graphene developer and wanted to ask about it

1 Like
2

In a default setup:
sys-net ↔ sys-firewall ↔ sys-whonix ↔ Disp-Whonix-WS
The sys-* qubes are basically routers that route the TCP/IP packets between Disp-Whonix-WS qube and remote host.
For example, you’re accessing some website in Disp-Whonix-WS, you send a request to the website and wait for its response. The response from the website (or from someone pretending to be a website) will be sent to Disp-Whonix-WS and the TCP/IP packets with a response could be specially crafted to target some vulnerability in the TCP/IP stack and exploit it when this packet is being processed by the OS TCP/IP stack inside Disp-Whonix-WS qube.
The sys-net and sys-firewall won’t even see this packet content since it’ll be encrypted for them, sys-whonix will see its content but it will just pass it to the Disp-Whonix-WS qube.

2 Likes
3

Without any context, the TCP/IP stack is not a very good example of the issue, there is probably some theoretical exploit that only targets the last link of the chain.

What the person is saying is true about applications running in the VM, e.g. if someone can exploit your web browser, they can compromise the VM. Qubes OS is running stock Linux without any extra hardening, any exploit that works on Linux works on VMs running in Qubes OS.

The security in Qubes OS comes from how you configure trust domains and the individual VMs, and pretty much ignores the exploit vs. countermeasure arms race.

2 Likes
4

Both people in that conversation seem to be talking past one another and don’t exactly acknowledge the points of the other. Each has a bias and won’t give points where they are due.

Yes, Qubes has an OS/driver attack surface that can be exploited under specific circumstances, and so does Graphene OS. While Qubes does have multiple layers of OS sys-* abstraction, nat, and kernel filtering, adding more layers of the exact same attack surface doesn’t necessarily increase the vulnerability as much as it limits what attack is possible on that OS surface downstream closest to the application. If you can’t hack sys-net drivers directly then you are probably stuck attacking the endpoint. Its actually the endpoint app, or user, that is accepting that connection that is the weakest link in the chain, not the OS itself. Social engineering is so much easier.

The major difference here is in both in isolation and persistence. While Graphene is far more hardened than a standard Android device it does not completely address either of these cases. If a hack is successful then the Graphene device is compromised, but if you have the extra Vanadium browser isolation enabled, you then may have an extra level of protection for your data, if that data is locked at the moment of compromise. Then you just use social engineering to get the user to unlock it. Vanadium is basically an enhanced browser isolation capability, which many browsers now offer. Qubes can do the same if your configure your browser accordingly, and the OS itself gives you extra ways of reverting that compromise that Graphene can not accomplish this without a factory reset. Either may need to be restored from backup.

Qubes limits that compromise to just the isolated container/VM by default. Even so that compromise may only exist until the AppVM is restarted. Not true for the Graphene OS device in general. Each OS has its place. While I would not want to run Qubes on my phone, I might want to run Graphene on my Qubes. One is just more powerful of a hardware platform than the other.

1 Like