Ubuntu

improperly mapped source privileged ports may allow for obtaining privileged resources on the host

Reported by Jeremy Nickurak on 2010-06-09
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt
Unknown
Unknown
libvirt (Ubuntu)
Medium
Jamie Strandboge
Hardy
Medium
Jamie Strandboge
Jaunty
Medium
Jamie Strandboge
Karmic
Medium
Jamie Strandboge
Lucid
Medium
Jamie Strandboge
Maverick
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-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.

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
ProcVersionSignature: Ubuntu 2.6.32-22.35-server 2.6.32.11+drm33.2
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

Jeremy Nickurak (nickurak) wrote :
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
Jamie Strandboge (jdstrand) wrote :

This was fixed in 0.8.3-1ubuntu1.

visibility: private → public
Changed in libvirt (Ubuntu Maverick):
status: In Progress → Fix Released
Alex Valavanis (valavanisalex) wrote :

Jaunty reached end-of-life on 23 October 2010, so this bug will not be fixed in that version of Ubuntu. It has been fixed in newer versions.

Changed in libvirt (Ubuntu Jaunty):
assignee: Jamie Strandboge (jdstrand) → nobody
status: In Progress → Won't Fix
Jamie Strandboge (jdstrand) wrote :

This was actually fixed in http://www.ubuntu.com/usn/usn-1008-1.

Changed in libvirt (Ubuntu Jaunty):
assignee: nobody → Jamie Strandboge (jdstrand)
status: Won't Fix → Fix Released
Changed in libvirt (Ubuntu Lucid):
status: In Progress → Fix Released
Changed in libvirt (Ubuntu Hardy):
status: In Progress → Fix Released
Changed in libvirt (Ubuntu Karmic):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.