From: "Andrew G. Morgan" <morgan@kernel.org>
To: Chris Wright <chrisw@sous-sol.org>
Cc: Dave Jones <davej@codemonkey.org.uk>,
Linux Kernel <linux-kernel@vger.kernel.org>,
bojan@rexursive.com, "Serge E. Hallyn" <serue@us.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Security Modules List
<linux-security-module@vger.kernel.org>
Subject: Re: capget() overflows buffers.
Date: Fri, 23 May 2008 23:25:57 -0700 [thread overview]
Message-ID: <4837B4F5.4000100@kernel.org> (raw)
In-Reply-To: <20080523155718.GI30402@sequoia.sous-sol.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris Wright wrote:
| caps is essentially
|
CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SETGID|CAP_DAC_READ_SEARCH|CAP_SYS_RESOURCE
|
| linux_setcaps(cap_t caps) {
| struct __user_cap_header_struct caphead;
| struct __user_cap_data_struct cap; <-- 12 bytes on stack
| memset(&caphead, 0, sizeof(caphead));
| caphead.version = _LINUX_CAPABILITY_VERSION; <-- v2 now
| caphead.pid = 0;
| memset(&cap, 0, sizeof(cap)); <-- start initializing 12 bytes
| cap.effective = caps;
| cap.permitted = caps;
| cap.inheritable = 0; <-- finish initializing 12 bytes
| if (syscall(SYS_capset, &caphead, &cap) < 0) <-- kernel copies in 24
bytes
|
| So it's blindly setting v2. The kernel is sucking in 24 bytes. The
| second set of u32s (the extra 12 bytes) is just garbage from the stack.
So, this syscall will either fail (because the process isn't
sufficiently capable to execute the system-call, and/or the "garbage"
has something like pP < pE, and the resulting attempt violates the pE'
<= pP' rule), or the syscall succeeds...
In the case that it is discovered to fail (on any tested architecture
like in the redhat bug tracked here:
https://bugzilla.redhat.com/show_bug.cgi?id=447518 ), clearly the code
is going to get recompiled to make it work.
| This could include setting CAP_MAC_OVERRIDE or CAP_MAC_ADMIN, percisely
| the kinds of things you _wouldn't_ want set when the goal of the above
| code is to drop privs.
Your concern is for the situation when the garbage happens to correspond
to an apparently meaningful setting for the upper capability bits? The
problem being that this privileged application is more privileged than
intended? I agree that this is not ideal.
In practice, however, this is only a real problem if named (or a
similarly structured program) has a security related bug in it. No?
Is this your concern, or have I missed something?
Cheers
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFIN7T0+bHCR3gb8jsRAu87AJ4+ar3LeRol8/szzwgFvDYidQkFbgCeNEqj
0CfYnVW19WRc3H/gXs2wSVY=
=pQ8d
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-05-24 6:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-22 14:04 capget() overflows buffers Dave Jones
2008-05-22 17:58 ` Chris Wright
2008-05-22 20:53 ` Chris Wright
2008-05-22 22:52 ` Andrew G. Morgan
2008-05-22 23:37 ` Chris Wright
2008-05-23 7:09 ` Andrew G. Morgan
2008-05-23 15:57 ` Chris Wright
2008-05-24 6:25 ` Andrew G. Morgan [this message]
2008-05-24 8:07 ` Chris Wright
2008-05-27 1:17 ` [PATCH] security: was "Re: capget() overflows buffers." Andrew G. Morgan
2008-05-27 21:42 ` Chris Wright
2008-05-28 3:33 ` Andrew Morton
2008-05-23 18:26 ` capget() overflows buffers Chris Wright
2008-05-24 0:02 ` Andrew G. Morgan
2008-05-24 1:09 ` Chris Wright
2008-05-24 4:40 ` Andrew G. Morgan
2008-05-24 8:17 ` Chris Wright
2008-05-23 1:20 ` Bojan Smojver
2008-05-23 2:06 ` Chris Wright
2008-05-23 4:01 ` Bojan Smojver
2008-05-22 21:20 ` Bojan Smojver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4837B4F5.4000100@kernel.org \
--to=morgan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bojan@rexursive.com \
--cc=chrisw@sous-sol.org \
--cc=davej@codemonkey.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serue@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox