[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130313175729.GH12501@outflux.net>
Date: Wed, 13 Mar 2013 10:57:29 -0700
From: Kees Cook <keescook@...omium.org>
To: ebiederm@...ssion.com
Cc: Sebastian Krahmer <krahmer@...e.de>, linux-kernel@...r.kernel.org
Subject: CLONE_NEWUSER|CLONE_FS root exploit
Hi,
It seem like we should block (at least) this combination. On 3.9, this
exploit works once uidmapping is added.
http://www.openwall.com/lists/oss-security/2013/03/13/10
-Kees
----- Forwarded message from Sebastian Krahmer <krahmer@...e.de> -----
Date: Wed, 13 Mar 2013 16:39:56 +0100
From: Sebastian Krahmer <krahmer@...e.de>
To: oss-security@...ts.openwall.com
Subject: [oss-security] CLONE_NEWUSER|CLONE_FS root exploit
Envelope-To: kees@...flux.net
Hi,
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. ;)
regards,
Sebastian
--
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer@...e.de - SuSE Security Team
----- End forwarded message -----
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists