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.
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.