Bug 602455 - (CVE-2010-2242) CVE-2010-2242 libvirt: improperly mapped source privileged ports may allow for obtaining privileged resources on the host
CVE-2010-2242 libvirt: improperly mapped source privileged ports may allow fo...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20100712,reported=20100609,sou...
: Security
: 624536 (view as bug list)
Depends On: 608049 613055 613625 619105
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-09 17:09 EDT by Vincent Danen
Modified: 2015-10-23 10:56 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-04 10:44:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Add a source port mapping for TCP & UDP protocols when masquerading (12.35 KB, patch)
2010-06-10 12:56 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Vincent Danen 2010-06-09 17:09:18 EDT
Jeremy Nickurak reported an issue with how libvirt creates iptables rules when guest systems are setup for masquerading.  The iptables rule will be of the following format:

# iptables-save -t nat
# Generated by iptables-save v1.4.7 on Wed Jun  9 14:59:03 2010
*nat
:PREROUTING ACCEPT [45:5146]
:POSTROUTING ACCEPT [889:54117]
:OUTPUT ACCEPT [889:54117]
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE 
COMMIT
# Completed on Wed Jun  9 14:59:03 2010

With masquerading, outgoing connections will have their source-port mapped to a NAT-selected port, and the iptables default is for privileged ports to be mapped to privileged (<1024) ports.

This will allow users in guests that have root privileges (in the guest, independent of their privileges on the host), to obtain privileged resources on the host, as well as being able to access other resources by using it.  One example is with standard NFS exports now being accessible to the guests, because the guests will appear to be from the same IP as a possibly trusted host.

To illustrate:

regular-user@host-machine:~$ ssh guest-machine
Last login: Wed Jun 9 11:33:13 2010 from host-machine
regular-user@guest-machine:~$ sudo mount -t nfs -o udp,rw,soft
remote-nfs-server:/some-export /mnt/tmp

(get UID of resources on the remote NFS server, and create a user in the
guest with that UID>
(su to that new UID)

user-with-same-uid@guest-machine:~$ cp -R /mnt/tmp/secret-data /home/mycopy; rm -Rf /mnt/tmp/secret-data

A normal user account would not normally be able to do something like this because they cannot bind to the privileged port, however in this case the NAT rules permits it.

An example modified set of iptables rules that may solve the problem was supplied as well:

/sbin/iptables -t nat -A POSTROUTING -p tcp -o $(IFACE) -j MASQUERADE --to-ports 1024-65535
/sbin/iptables -t nat -A POSTROUTING -p udp -o $(IFACE) -j MASQUERADE --to-ports 1024-65535
/sbin/iptables -t nat -A POSTROUTING -p icmp -o $(IFACE) -j MASQUERADE

The above uses the --to-ports option that forces iptables' masquerading module to only map guest reqursts to non-privileged ports.

Acknowledgements:

Red Hat would like to thank Jeremy Nickurak for reporting this issue.
Comment 1 Vincent Danen 2010-06-09 17:13:37 EDT
Jeremy reported this using Fedora 11 (libvirt 0.6.2) using qemu/kvm.  I have reproduced this on Fedora 13 (libvirt 0.7.7).
Comment 3 Daniel Berrange 2010-06-10 11:54:38 EDT
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.
Comment 4 Daniel Berrange 2010-06-10 12:56:27 EDT
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.
Comment 7 Josh Bressers 2010-06-16 13:54:46 EDT
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.
Comment 8 Daniel Berrange 2010-06-16 14:38:39 EDT
> 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 :-)
Comment 9 Jeremy Nickurak 2010-06-16 14:55:51 EDT
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.
Comment 11 Vincent Danen 2010-06-25 11:47:11 EDT
This has also been reported to Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/591943
Comment 13 Petr Matousek 2010-07-12 07:28:10 EDT
This issue affects libvirt >= 0.2.0.
Comment 15 Petr Matousek 2010-07-12 09:03:52 EDT
Created libvirt tracking bugs for this issue

Affects: fedora-all [bug 613625]
Comment 16 Fedora Update System 2010-07-26 22:36:50 EDT
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.
Comment 17 Fedora Update System 2010-07-26 22:48:49 EDT
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.
Comment 19 errata-xmlrpc 2010-08-10 13:02:36 EDT
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
Comment 20 Vincent Danen 2010-08-10 16:53:11 EDT
Statement:

(none)
Comment 21 Cole Robinson 2010-12-01 11:33:59 EST
*** Bug 624536 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.