On 10/11/12 11:19, Igor Bukanov wrote:
> One of potential problems with AppVM facing the Internet is that a
> kernel bug in TCP may allow to compromise all the VMs. To avoid that
> for a banking VM I did the following.
>
This statement is only true for "all the VMs" that share the same
FirewallVM (or NetVM) from which we start the attack. This doesn't need
to be true in general (we can have e.g. two different NetVMs -- one with
WiFi card assigned, and the other with the 3G modem assigned, or we can
have a completely network-disconnected VMs).
> In the firewall VM I run tinyproxy and sshd configured to listen only
> to localhost. For banking VM I disabled all the networking so the only
> networking device in it is the loopback interface. Using the
>
https://wiki.qubes-os.org/trac/wiki/Qrexec and proxy support in the
> openssh client I allowed the ssh from the banking VM to connect to
> sshd in the firewall VM using a setup similar to [1]. Then I used the
> ssh client to setup TCP port forwarding from the banking VM to
> tinyproxy in the firewall VM. After that I just pointed the browser in
> the banking VM to the the forwarded proxy port and could browse
> without any problems.
>
> AFAICS such setup should stop a kernel bug in TCP from propagating.
> That is, to subvert the banking VM from the firewall VM that was
> compromised using that bug one would need to find a bug in ssh client.
> Without such bug in ssh the only thing that the subverted VM can do
> that influences kernel networking code in the banking VM is frequency
> and size of data payload that traveled over opened loopback socket
> connection in the banking VM. I presume the exposure here should be
> magnitudes less that that of code in the kernel dealing with generic
> TCP client connections. Is it a correct assumption?
>
Yeah, I think so.
This is an interesting setup :) While one could argue that perhaps the
attack surface on the ssh client + qrexec might be comparable to that
over the Linux TCP/IP stack, I think that it's still a win because at
the worst case the attacker needs two different exploits to conduct the
AppVM1 -> FirewallVM -> AppVM2 attack.
But of course it's not very user friendly ;) I've been wondering for a
long time that it would perhaps make a lot of sense to have the service
VMs based on some non-Linux kernel, such as e.g. FreeBSD. In this case
we would achieve a similar advantage: two different exploits would be
needed (one against FreeBSD TCP/IP stack and the other against the Linux
TCP/IP stack). The difference is that it would just work seamlessly
without any need for extra configuration... Of course the "only" catch
is that somebody would need to create a *BSD-based template (which might
be cool anyways) :)
Nevertheless, I think we would be open to accept a patch for such
qrexec-based-tcp-forwarding from you. I think this should be implemented
in a similar way as the tor service we discussed with Abel recently.
joanna.