Date: Wed, 13 Mar 2013 10:50:32 -0700 From: Kees Cook <keescook@...omium.org> To: oss-security@...ts.openwall.com Subject: Re: CLONE_NEWUSER|CLONE_FS root exploit On Wed, Mar 13, 2013 at 04:39:56PM +0100, Sebastian Krahmer wrote: > Seems like CLONE_NEWUSER|CLONE_FS might be a forbidden > combination. > During evaluating the new user namespace thingie, it turned out > that its trivially exploitable to get a (real) uid 0, > as demonstrated here: > > http://stealth.openwall.net/xSports/clown-newuser.c > > The trick is to setup a chroot in your CLONE_NEWUSER, > but also affecting the parent, which is running > in the init_user_ns, but with the chroot shared. > Then its trivial to get a rootshell from that. > > Tested on a openSUSE12.1 with a custom build 3.8.2 (x86_64). > > I hope I didnt make anything wrong, mixing up the UIDs, > or disabled important checks during kernel build on my test > system. ;) Nice. :) The good news is that getting userns on 3.8 looks hard (if you build any of the blacklisted filesystems). The bad news is that this is all fixed on 3.9 so userns is available there easily. Regardless, on 3.9 it seems to need an explicit uid mapping to get set up. Once that was added to your PoC, it worked for me on 3.9 too. Also note that if hardlink restrictions were enabled by default, this exploit would be blocked: [-] link: Operation not permitted I sure hope any distro shipping modern kernels is shipping with these sysctl settings: fs.protected_symlinks=1 fs.protected_hardlinks=1 -Kees -- Kees Cook Chrome OS Security
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.