linux-kernel - Re: capget() overflows buffers.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 May 2008 23:25:57 -0700
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Chris Wright <chrisw@...s-sol.org>
CC:	Dave Jones <davej@...emonkey.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	bojan@...ursive.com, "Serge E. Hallyn" <serue@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Security Modules List 
	<linux-security-module@...r.kernel.org>
Subject: Re: capget() overflows buffers.

-----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-----
--
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/