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]

Message-ID: <20080524010923.GT30402@sequoia.sous-sol.org>
Date:	Fri, 23 May 2008 18:09:23 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	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.

* Andrew G. Morgan (morgan@...nel.org) wrote:
> Chris Wright wrote:
> | I'm sure you're painfully aware, but this will need some change
> | to libcap as well (to let it handle 64bit caps again).
>
> Not really.
>
> libcap2 (the one with 64-bit capability support) continues to work fine
> (it ships with its own copy of a compatible linux/capability.h, and when
> I update that, I'll make the corresponding change) but the effect should
> be transparent to its users:

Doh, I missed the leading portion of the pathname (cscope -p3 didn't
show anything more than include/sys/capability.h), thanks.

> | That's what I meant earlier by "And use another mechanism to
> | signal the availability of 64bit caps."
>
> There is and has always been a method:
>
> ~   head.version = 0;
> ~   getcap(&head, NULL);
> ~   switch (head.version) {
> ~   case _LINUX_...:
> ~      ...
> ~      break;
> ~   case _,,,,:
> ~      etc...
> ~      break;
> ~   default:
> ~      abort("no idea what to do");
> ~   }

Hmm, it would be kind of nice to have a formalized way get the size,
perhaps it would help with KaiGai's request for caps printed out.
Something that tells us either the number of u32s, or the max bit
supported?

> | All looks good.  I think we need to issue some warnings, because
> | at least Fedora 9 and openSUSE 11 are/will be 2.6.25 based.
>
> Do any of the above answers help? (FWIW I attached the patch to the
> redhat bug.)

Yes, thanks.  But I still think we need to print a warning (unfortunately
we can't distinguish libcap from non-libcap app), because apps that
aren't using libcap should really be updated (either pull new update
from vendor or recompiled by end user).

thanks,
-chris
--
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/