Wednesday, March 13, 2013

CLONE_NEWUSER trickery: CVE-2013-1858

Recent kernels (3.8+ something) introduced a feature called
user-namespaces (user-ns, CLONE_NEWUSER flag)
in which you can have your own UID 0.
Think of it as a container solution, so you can
set up compartments on a host. A nice thing,
but it has some security implications. In particular
if you mix this feature with CLONE_FS, which means
that the file-system state is shared between the
containers (e.g. processes). You suddenly get this:





The problem here is that parent and child share the
FS info (the chroot in this case), but only the child
has got its own user-ns. Since it has the
capability to do the chroot() in its own user-ns,
it will succeed doing the chroot() syscall but due to
CLONE_FS, it will also affect the parent.
Parent however stays in the init user-ns (the user-ns
that is default upon boot and the namespace where you
want to have root).
Getting a rootshell from inside a user controlled chroot
with help from outside processes is straight forward.

The xSports can be found here.

Update:
A CVE has been assigned (CVE-2013-1858) and a patch was made.






3 comments:

Kees Cook said...

Nice work! :) I had to add uidmapping before this worked on 3.9 for me.

Anonymous said...

Why don't you just chroot into "/" instead of creating a minimal rootfs? (I didn't test it because my kernel is not ready yet).

Unknown said...

Great work!