[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130313175032.GG12501@outflux.net>
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.
