Bug 602455 (CVE-2010-2242)

Jeremy reported this using Fedora 11 (libvirt 0.6.2) using qemu/kvm.  I have reproduced this on Fedora 13 (libvirt 0.7.7).

A little more detailed scenario for reproducing, assuming:

 - An NFS server  (IP == 10.33.8.116 in this example)
 - A virt host    (IP == 10.33.8.111 in this example)

On the NFS server setup an exported filesystem, with the 'secure' flag set and restricted to the IP subnet of the virt hosts

  # cat >> /etc/exports <<EOF
  /var/lib/libvirt/images/export 10.33.8.0/255.255.255.0(rw,no_root_squash,secure)
  EOF
  # exportfs -a -r -v

On the virtualization host, ensure the default virtual network is running

  # virsh net-list
  Name                 State      Autostart
  -----------------------------------------
  default              active     yes       

And that it is configured to do NAT

  # virsh net-dumpxml default | grep forward
  <forward mode='nat'/>



Pick any guest OS and make sure it is connected to the default virtual network. 

eg its XML config (virsh dumpxml $GUESTNAME) should have a NIC configured to look like this

    <interface type='network'>
      <mac address='52:54:00:56:44:32'/>
      <source network='default'/>
      <model type='virtio'/>
    </interface>

Boot the guest  (virsh start $GUESTNAME)

Now, login to the guest in any manner (ssh, virt-viewer, virsh console,etc).

Attempt to mount the NFS server. Due to the NAT flaw, it will succeed. 

With the fixed NAT rules it should should fail in this message:

  # mount 10.33.8.116:/var/lib/libvirt/images/export /mnt -t nfs
  mount.nfs: access denied by server while mounting 10.33.8.116:/var/lib/libvirt/images/export

If the NFS server is then  modified to set 'insecure' in /etc/exports, the mount should work again, because this disables source port checking.

Created attachment 422978 [details]
Add a source port mapping for TCP & UDP protocols when masquerading

This patch applies to upstream GIT repo commit 3cf642a0f90551c4bde23fc0d571d1074717b0de

It should apply without trouble to any 0.8.x series libvirt. Older versions will likely need re-diffing, not least because many file locations have changed in the source tree.

I'm not sure if this is a security flaw. It's probably a bug, but I don't see a trust boundary crossed here (it's fuzzy at best).

First you need some sort of network setup where access is tightly controlled. If anyone can connect any random piece of hardware, port based access restrictions don't work.

I presume that if the virtual machine is behind NAT, we're probably talking about someone at a local machine. It's *possible* they would be connecting remotely, we'll talk about that in a bit though. If there is physical hardware access, this is a non issue, there are many other things they can do at this point that don't need virt.

If you trust someone to have root on a VM, but not on the host, you are in trouble. virt is not a security feature. One compromised virt machine can have drastic results for all the others.

In order for this to be a security flaw, you need the condition of a tightly controlled network that allows untrusted users to have root access on a NAT'd guest, who also have access to port controlled resources.

> If you trust someone to have root on a VM, but not on the host, you are in
> trouble. virt is not a security feature. One compromised virt machine can have
> drastic results for all the others.

Trusting guest admins with root on their guests is not unreasonable, if you've configured your host OS networking to protect against bad stuff they can do (IP spoofing, MAC address spoofing, etc, etc). This protection can be applied using the libvirt guest NIC filtering capabilities, or manually setup by the admin using iptables. Of course if you're doing that, you can block access to the NFS servers in question that way. So this NAT source port mapping question becomes moot.

> In order for this to be a security flaw, you need the condition of a tightly
> controlled network that allows untrusted users to have root access on a NAT'd
> guest, who also have access to port controlled resources.

I guess the decision here comes down to whether you consider the libvirt NAT based networking capability to be a security feature, as well as a connectivity feature. It wasn't designed as a security feature, rather as a quick way to give access to guests on a laptop using Wifi NICs where bridging is impossible. Any security benefit is at best a convenient side-effect from the NAT-ing of IP packets.  We have separate dedicated capabilities for doing network filtering on guest traffic.

Personally, I consider the flaw to be in NFS for expecting source port restrictions to offer any kind of meaningful security, but that's a different topic :-)

The flaw does effect actual physical NAT set ups as well... but to me it's more obvious that that set up exists, and that the NAT members are accessing privileges resources via the NAT router. With a VM, you click a few buttons, and the NAT is automatic and invisible, so you don't really know that it's happened.

I would however argue that the default for the SNAT and masquerading modules should be to NOT map to privileged ports, since that's really the root of this issue. If you're really in a situation where you have physical control over all the NAT participants, you can opt to open that up.

That would make the changes here a workaround, but push the actual fix to the kernel.

This has also been reported to Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/591943

This issue affects libvirt >= 0.2.0.

Created libvirt tracking bugs for this issue

Affects: fedora-all [bug 613625]

libvirt-0.8.2-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

libvirt-0.8.2-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0615 https://rhn.redhat.com/errata/RHSA-2010-0615.html

Statement:

(none)

*** Bug 624536 has been marked as a duplicate of this bug. ***