[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.51.0909220154470.16381@faron.mitre.org>
Date: Tue, 22 Sep 2009 01:58:52 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: oss-security@...ts.openwall.com
cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request: kernel: issue with O_EXCL creates
on NFSv4
On Mon, 21 Sep 2009, Eugene Teo wrote:
> Upstream commits:
> http://git.kernel.org/linus/af85852d (fixed in v2.6.19-rc6)
> http://git.kernel.org/linus/81ac95c5 (fixed in v2.6.19-rc6)
> http://git.kernel.org/linus/79fb54ab (fixed in v2.6.30-rc1)
I can't see any clear relationship between these commits and the Red Hat
bugzilla entry. The implication that there were two fixes, one in 2.6.19
and one in 2.6.30, is also confusing because if a fix in 2.6.19 didn't
work, we'd normally assign a new CVE for the fix in 2.6.30.
CVE-2009-3286 is below, anchored on what's said in Bugzilla 524520. Since
81ac95c also mentions do_open_permission, I used that as a reference.
This suggests the problem was fixed in 2006, but this issue doesn't have a
CVE identifier because security implications weren't spelled out until
Eugene's post (as far as I can tell.)
- Steve
======================================================
Name: CVE-2009-3286
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3286
Acknowledged: yes bug-report
Announced: 20090909
Flaw: other
Reference: MLIST:[oss-security] 20090921 CVE request: kernel: issue with O_EXCL creates on NFSv4
Reference: URL:http://www.openwall.com/lists/oss-security/2009/09/21/2
Reference: CONFIRM:http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=81ac95c5
Reference: CONFIRM:https://bugzilla.redhat.com/show_bug.cgi?id=524520
NFSv4 in the Linux kernel 2.6.18, and possibly other versions, does
not properly clean up an inode when an O_EXCL create fails, which
causes files to be created with insecure settings such as setuid bits,
and possibly allows local users to gain privileges, related to the
execution of the do_open_permission function even when a create fails.
That also explains why we don't see this problem with root...the
permission check is always passing there (provided we're not root
squashing).
Analysis:
ACCURACY/ACKNOWLEDGEMENT: bug 524520 says "What's happening here is
that the inital create is occurring, but then the permission check for
the open fails. This short-circuits the rest of the process, causes
the open to return an error and leaves the inode in this funky state."
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.
