Mirage-firewall 0.9.0 released

General Discussion
1

I am happy to announce that the latest release of Qubes Mirage Firewall has just been released (0.9.0) and improves:

  • The possibility to have a BSD sys-net (for more information see Combination of OpenBSD sys-net + MirageFW)
  • The possibility to change netvm dynamically (e.g. qvm-prefs mirage-fw netvm sys-net without the need to restart mirage-fw).

If you have any comments, please let us know, on this forum or on github.

6 Likes
2

The original blog post about mirage-firewall states:

There is another, more serious, problem. Xen virtual network devices are implemented as a client (“netfront”) and a server (“netback”), which are Linux kernel modules in sys-firewall. In a traditional Xen system, the netback driver runs in dom0 and is fully trusted. It is coded to protect itself against misbehaving client VMs. Netfront, by contrast, assumes that netback is trustworthy. The Xen developers only considers bugs in netback to be security critical.

In Qubes, NetVM acts as netback to FirewallVM, which acts as a netback in turn to its clients. But in Qubes, NetVM is supposed to be untrusted! So, we have code running in kernel mode in the (trusted) FirewallVM that is talking to and trusting the (untrusted) NetVM!

For example, as the Qubes developers point out in Qubes Security Bulletin #23, the netfront code that processes responses from netback uses the request ID quoted by netback as an index into an array without even checking if it’s in range (they have fixed this in their fork).

What can an attacker do once they’ve exploited FirewallVM’s trusting netfront driver? Presumably they now have complete control of FirewallVM. At this point, they can simply reuse the same exploit to take control of the client VMs, which are running the same trusting netfront code!

This sounds serious. Is that still true/accurate today? Has it been discussed within the community?

Also, I wonder about the reason why mirage-firewall hasn’t been included in the community templates so far. It seems popular among the community. I found a couple of old threads about including it but it seems QubesOS’ staff ignored them. (correct me if I’m wrong)

1 Like
3

Well, I understand that the part quoted was one of the motivations for the creation of qubes-mirage-firewall. The security bulletin is from 2015 and talks about PV drivers, I suppose the situation to be already fixed now :slight_smile:

Regarding the template, I think the Qubes team doesn’t have enough time to audit the mirageOS code so far, which slows down the integration process.
Another thing to keep in mind is that, although I don’t currently see bandwidth issues with mirage-firewall for daily network tasks (even for video meetings, the firewall CPU isn’t at 100%), mirageOS currently lacks TCP Segmentation Offload, which shows lower maximum bandwidth compared to Linux (with TSO enabled, see Slower bandwidth compared to sys-firewall · Issue #130 · mirage/qubes-mirage-firewall · GitHub) when you need a flow between IPsrc:portsrc ↔ IPdst:portdst. Unfortunately, this scenario is often used in speed comparison tests.

2 Likes
4

Thank you :slight_smile:

5

I have packaged the new release, available from Simple Setup, so you can
get the mirage firewall up and running by installing a package in to
dom0.
If you are already using mirage from this source, then a dom0 update will
pull in the new release.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

5 Likes