improperly mapped source privileged ports may allow for obtaining privileged resources on the host
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt |
Fix Released
|
Low
|
|||
libvirt (Ubuntu) |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Hardy |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Jaunty |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Karmic |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Lucid |
Fix Released
|
Medium
|
Jamie Strandboge | ||
Maverick |
Fix Released
|
Medium
|
Jamie Strandboge |
Bug Description
ibvirt 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-
Last login: Wed Jun 9 11:33:13 2010 from host-machine
regular-
remote-
(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-
-Rf /mnt/tmp/
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.
Confirmed in libvirt 0.6.2, as well as libvirt 0.7.7 (by upstream)
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: libvirt0 0.7.5-5ubuntu27
ProcVersionSign
Uname: Linux 2.6.32-22-server x86_64
Architecture: amd64
Date: Wed Jun 9 15:16:05 2010
ProcEnviron:
PATH=(custom, no user)
LANG=en_CA.UTF-8
SHELL=/bin/bash
SourcePackage: libvirt
Changed in libvirt (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in libvirt (Ubuntu Lucid): | |
status: | New → In Progress |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in libvirt (Ubuntu Maverick): | |
status: | Confirmed → In Progress |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in libvirt (Ubuntu Hardy): | |
status: | New → In Progress |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in libvirt (Ubuntu Jaunty): | |
status: | New → In Progress |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in libvirt (Ubuntu Karmic): | |
status: | New → In Progress |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in libvirt (Ubuntu Lucid): | |
importance: | Undecided → Medium |
Changed in libvirt (Ubuntu Hardy): | |
importance: | Undecided → Medium |
Changed in libvirt (Ubuntu Jaunty): | |
importance: | Undecided → Medium |
Changed in libvirt (Ubuntu Karmic): | |
importance: | Undecided → Medium |
Changed in libvirt: | |
importance: | Unknown → Low |
status: | Unknown → Fix Released |
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 user@guest- machine: ~$ sudo mount -t nfs -o udp,rw,soft nfs-server: /some-export /mnt/tmp
Last login: Wed Jun 9 11:33:13 2010 from host-machine
regular-
remote-
(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.