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: <20080522233757.GD30402@sequoia.sous-sol.org>
Date:	Thu, 22 May 2008 16:37:57 -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
Subject: Re: capget() overflows buffers.

* Andrew G. Morgan (morgan@...nel.org) wrote:
> Chris Wright wrote:
> | Andrew, I think this should be considered a serious problem.  The
> | interface ABI is stable for old programs, and fine for anything new
> | or old that's using libcap.  But the API has changed subtly (taking a
> | pointer to a blob, to a pointer to an array of blobs), and is easily
> | broken for programs recompiled against new headers not using libcap.
>
> [There is a warning about this issue in the kernel header file.]
>
> The kernel is not crashing, the application is...

It's not about crashing.  It's about app security.  Currently, there is
nothing guaranteeing named has actually dropped privileges.  That's why
I consider this serious.

> If you take this compiled binary, that crashes on 2.6.25, and try to run
> it on 2.6.24 it will fail there too - since the magic its 'forcing' is
> not valid on that kernel. So the compiled 'binary' we're discussing does
> not have an existence proof that it will successfully run anywhere.

Right, that's not the issue.

> In point of fact, the kernel is binary compatible with old binaries. The
> problem is that _LINUX_CAPABILITY_VERSION #define now points to _2
> instead of _1 by default and Squid etc., are not paying attention to the
> value of the new magic cookie but expecting the previous revision of the
> ABI to work.

Yes, as they should.  I don't think we should ever expect an existing
userspace program change just by recompiling against a new kernel header
when using an already existing mechanism.  Their app has been working
fine since 2.2.

  int fd = open("foo", O_FLAGS, mode);

compile once...binary compatible going forward (as is cap{s,g}et).
update kernel, recompile...source API comaptible...still working
(this is broken in cap{s,g}et).

> As such, I don't agree that there is a problem with the ABI, and I don't
> agree with your assertion about things being broken. I maintain there is
> a problem with the application source code.

History bites us...libcap wasn't always there.  As we see, people roll
their own.  You can argue that the interface is opaque, I'd agree.
Also that it's their fault for poking into the guts of the opaque
interface...yeah, I tend to even agree there.  However, it's not practical
to argue that when this app code has worked fine for 10 years.

> One 'solution' is to force everyone to notice at compile time by simply
> removing the definition of _LINUX_CAPABILITY_VERSION and force all new
> source code to be explicit about which ABI it wants to use...

No, the solution there would be to keep _LINUX_CAPABILITY_VERSION as
v1 (otherwise you just broke apps again).  And use another mechanism to
signal the availability of 64bit caps.

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/