[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090915035141.GA24969@openwall.com>
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.
