Bug 809296 - (CVE-2013-1858) VUL-1: CVE-2013-1858: kernel: local privilege escalation using CLONE_NEWUSER
(CVE-2013-1858)
VUL-1: CVE-2013-1858: kernel: local privilege escalation using CLONE_NEWUSER
Status: RESOLVED UPSTREAM
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P5 - None : Normal
: ---
Assigned To: Security Team bot
Security Team bot
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-14 07:02 UTC by Marcus Meissner
Modified: 2013-07-17 13:00 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2013-03-14 07:02:06 UTC
is public, via Sebastian Krahmer

CVE-2013-1858


From: Sebastian Krahmer <krahmer@suse.de>
Date: Wed, 13 Mar 2013 16:39:56 +0100
Subject: [oss-security] CLONE_NEWUSER|CLONE_FS root exploit

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
Comment 1 Marcus Meissner 2013-03-14 07:03:27 UTC
fixed by upstream commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71

author	Eric W. Biederman <ebiederm@xmission.com>	2013-03-13 18:51:49 (GMT)
committer	Linus Torvalds <torvalds@linux-foundation.org>	2013-03-13 22:00:20 (GMT)
commit	e66eded8309ebf679d3d3c1f5820d1f2ca332c71 (patch)
tree	768e1d799f6d6a4a7f85f48d9e9fc431dc8d017c
parent	6c23cbbd5056b155401b0a2b5567d530e6c750c4 (diff)
download	linux-e66eded8309ebf679d3d3c1f5820d1f2ca332c71.tar.gz
userns: Don't allow CLONE_NEWUSER | CLONE_FS
Don't allowing sharing the root directory with processes in a different user namespace. There doesn't seem to be any point, and to allow it would require the overhead of putting a user namespace reference in fs_struct (for permission checks) and incrementing that reference count on practically every call to fork. So just perform the inexpensive test of forbidding sharing fs_struct acrosss processes in different user namespaces. We already disallow other forms of threading when unsharing a user namespace so this should be no real burden in practice. This updates setns, clone, and unshare to disallow multiple user namespaces sharing an fs_struct.
Comment 2 Marcus Meissner 2013-03-14 07:04:39 UTC
Note that this only affects Linux Kernel 3.8, older versipns are not affected.

So no SUSE Linux Enterprise or openSUSE product was affected by this issue.