Re: CVE Request -- logrotate -- nine issues

["Steven M. Christey" <coley () rcf-smtp mitre org>]

On Fri, 4 Mar 2011, Solar Designer wrote:

> Again, as I wrote to Florian, maybe the expectations here are changing 
> over the years.

In general, that's what happens in CVE.  Part of this may be that as the 
more obvious/severe issues get eliminated, less-severe issues are then 
given more attention.  I try to watch out for edge cases that may 
"snowball" into large numbers of CVEs of limited utility - and you brought 
up one such example of a snowball issue with the recognition of 
technically-unsafe-but-commonly-accepted file behaviors of various Unix 
commands.  However, there is no clearly-defined line (software is too 
complex and dynamic for that) and risk tolerance differs widely between 
individuals.  The PHP interpreted gets hit with various issues related to 
sandbox escaping (or an application attacking itself), but in a hosting 
scenario (fairly common these days), it's a concern to some consumers.

As remote code execution vectors dry up (for certain classes of software), 
people look elsewhere.  As obvious remote vuln types get resolved, people 
look for other issues of uncertain exploitability that cause a crash. 
Alexander, you've had a bit of experience in suddenly turning "bugs" into 
"vulnerabilities" ;-)  The target is shifting over time and, by its 
nature, spreading a wider net.  As long as prioritization metrics like 
CVSS follow suit (e.g. more severities of 4 and 5, less 10's), this is a 
reasonable shift.

For CVE, there is no implied requirement for vendors to post advisories 
for evey issue that has a CVE assigned.  Vendors decide which issues are 
severe enough to directly notify their consumers about.  Granted, as the 
scope of CVE widens, this may increase the vendor workload.

Interesting discussion...

- Steve