linux-kernel - [PATCH] security: was "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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 26 May 2008 18:17:15 -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: [PATCH] security: was "Re: capget() overflows buffers."

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Wright wrote:
| * Andrew G. Morgan (morgan@...nel.org) wrote:
|> 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.
|
| Yep, exactly.
|
|> In practice, however, this is only a real problem if named (or a
|> similarly structured program) has a security related bug in it. No?
|
| It's dropped privileges to help mitigate any security related bug it
| may contain.  It's conceivable (albeit remote[1]) that fork/exec plus
| inheritable could leak privs w/out a security related bug.
|
|> Is this your concern, or have I missed something?
|
| That's it.

OK, so by way of summary, the kernel, per se, is *not* broken, but the
kernel include file is problematic for use by user space - ie., having
used it some recompiled programs may be subtly broken... [ Example,
https://bugzilla.redhat.com/show_bug.cgi?id=447518 ]

Basically I agree that we should err on the side of being conservative...

| thanks,
| -chris
|
| [1] Get lucky combo in the garbage bits and have not shed uid 0.
| Much less likely.

So far as I can tell, the two problems (for unprepared applications -
not using libcap etc.) are:

~ 1. what the capget() system call may be writing to data[1] may lead to
unpredictable reliability issues with the security of the running
program (when its only allocated space for data[0]).

~ 2. the garbage that the capset() system call may be setting in pI that
persists post-exec(). The security issue being (in the case that the
system has been configured with filesystem capability support) the leak
of inheritable bits that become effective through the subsequent
invocation of a filesystem-capable (fI != 0) application. The net result
being that this subsequent application gives capabilities to a user that
shouldn't wield them.

How about the attached for a combined patch? Chris, the only change over
last time is basically your suggested code change, with more comments
and a less cautious warning...

Cheers

Andrew

Ref: patch: 0c736c9f0ab16899df1803d5962287985e69a157
and libcap-2.10 supports this change.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFIO2Ea+bHCR3gb8jsRAowdAJ9kMa15tXLyv6t1EfV0pyOsbqk49QCgsjRJ
+SCiUsbN7M5nfdehXBWjzt0=
=Ri1u
-----END PGP SIGNATURE-----

View attachment "remain-source-compatible-with-32-bit-raw-legacy-capa.patch" of type "text/plain" (9735 bytes)