First published: Wed Jun 09 2010(Updated: )
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.
Credit: secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Libvirt Libvirt | =0.4.1 | |
Libvirt Libvirt | =0.5.1 | |
Libvirt Libvirt | =0.6.0 | |
Libvirt Libvirt | =0.7.3 | |
Libvirt Libvirt | =0.2.0 | |
Libvirt Libvirt | =0.8.1 | |
Libvirt Libvirt | =0.3.1 | |
Libvirt Libvirt | =0.7.0 | |
Libvirt Libvirt | =0.6.1 | |
Libvirt Libvirt | =0.4.0 | |
Libvirt Libvirt | =0.8.0 | |
Libvirt Libvirt | =0.6.5 | |
Libvirt Libvirt | =0.2.1 | |
Libvirt Libvirt | =0.7.1 | |
Libvirt Libvirt | =0.4.6 | |
Libvirt Libvirt | =0.2.3 | |
Libvirt Libvirt | =0.4.2 | |
Libvirt Libvirt | =0.3.3 | |
Libvirt Libvirt | =0.6.2 | |
Libvirt Libvirt | =0.7.6 | |
Libvirt Libvirt | =0.7.4 | |
Libvirt Libvirt | =0.6.4 | |
Libvirt Libvirt | =0.5.0 | |
Libvirt Libvirt | =0.7.7 | |
Libvirt Libvirt | =0.3.2 | |
Libvirt Libvirt | =0.4.4 | |
Libvirt Libvirt | =0.7.5 | |
Libvirt Libvirt | =0.7.2 | |
Libvirt Libvirt | =0.3.0 | |
Libvirt Libvirt | =0.6.3 | |
Libvirt Libvirt | =0.2.2 | |
Libvirt Libvirt | =0.8.2 | |
Libvirt Libvirt | =0.4.3 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.