Re: CVE Request -- rpcbind -- Insecure (predictable) temporary file use

["Steven M. Christey" <coley () linus mitre org>]

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