Date: Tue, 15 Sep 2009 07:51:41 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Cc: "Steven M. Christey" <coley@...us.mitre.org> Subject: Re: CVE-2009-1883 kernel: missing capability check in z90crypt On Tue, Sep 15, 2009 at 09:56:44AM +0800, Eugene Teo wrote: > Eugene Teo wrote: > >There is a missing capability check in the z90crypt driver in the Linux > >kernel. This missing check could allow a local, unprivileged user to > >bypass intended capability restrictions. Thanks to Solar Designer for > >reporting this issue to us. > > > >Note that this does not affect upstream anymore. > > Reference: > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-1883 Thanks. This problem is so minor that I am surprised you want to fix it for older kernels. The "report" you are referring to was a comment in a "pseudo patch" I submitted a long while ago. Some of those comments were merely pointing out things that were better corrected upstream, but that did not matter for typical uses of the code. Anyhow, I think it is OK to keep the CVE id assignment, but I suggest that the description be re-worded to say "root user" or "euid 0 user" in place of "unprivileged user". Indeed, on most systems this user would in fact be privileged, making this a non-issue. In practice, I imagine that there could exist service processes that would possess uid 0 at a given moment, yet not possess root's typical capabilities. If those processes are not chrooted, then, when under control of an attacker, they would typically be able to take over the system via replacing a critical system file (due to its ownership). If chrooted to a tree with no suitable file that could be replaced, then minor kernel bugs like this could actually matter, but perhaps not this one because to access an ioctl one needs to open the device file first (and that device file would likely not exist in a chroot tree). Then, these bugs could matter for an implementation of containers, but the implementation's proper control of access to device files (e.g., OpenVZ's) should take care of that in case of ioctl's on "obscure" devices that are normally not meant to be available in a container. Yet this "containers concern" was my primary reason to look for and mark this kind of bugs at the time (the "pseudo patch" I mentioned was initially against an OpenVZ kernel tree). Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.