[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 7 Jun 2010 17:20:36 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: oss-security@...ts.openwall.com
cc: Guillem Jover <guillem@...ian.org>,
Aníbal Monsalve Salazar <anibal@...ian.org>,
"Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE Request -- rpcbind -- Insecure (predictable)
temporary file use
On Mon, 7 Jun 2010, Josh Bressers wrote:
>> On Fri, 4 Jun 2010, Josh Bressers wrote:
>>
>>> Please use CVE-2010-2061 for this.
>>
>> My read of Guillem's report at
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583435#5 suggests that
>> we might have two distinct issues here:
>>
>> - "*any* user can craft those two files before the daemon has started for
>> the first time, which the daemon will parse." Nothing to do with
>> symlinks.
>>
>> - symlinks are followed on creation of those files
>>
>
> I'd not thought of these problems like this. You're probably right as CVE
> assignments are for cause, not fix. I was thinking more along the lines of
> the fix (store the files somewhere users can't write to) than the problems
> (which there are certainly two of).
This is the way CVE has evolved over time, to have a preference for the
core issue (and maybe we're going overboard the more we learn about how to
identify root causes).
A good counter-example for the notion of counting by fix would be: a web
application is vulnerable to both XSS and SQL injection on the same input,
but with a single patch it makes sure that the input is actually numeric.
The fix sometimes comes into play when the core problem/attack is not
necessarily known.
Neither approach is better per se, it's just that for CVE we want to be
reasonably consistent with CVE.
Generally, one guideline I use is: "if the developer fixes X, then could Y
still be a security problem?" If so, then they are treated as distinct
issues.
> Steve, I'll let you make the call, but I'm currently leaning toward two
> IDs.
Me too, I'd suggest assigning an ID from your pool.
- Steve
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.
