Re: CVE Requests for FFmpeg 0.9.1

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

Michael, this is a well-organized request, thank you!


> I tried to sort the issues a little according to type to make this huge
> list a bit less ugly. Also feel free to skip things considered too minor, 
> iam not sure where the threshold of "too minor" is.

A couple thoughts on this one, I hope this makes sense.

My VERY limited understanding of ffmpeg is that it is single-user, and it 
can only process a single file from a single source, without multiple 
"sessions" or "actions" using data from different sources.  If that is the 
case, then crashers like NULL dereferences and divide-by-zero might not 
qualify for inclusion in CVE.  With products like web browsers and 
document editors, a crash from one single window or tab could cause a 
denial of service by closing *other* independent windows or tabs that the 
user may care about; with things like kernels or servers, a crash affects 
many sessions and users.  So if ffmpeg only processes one file at a time, 
a basic crasher probably doesn't get a CVE.

If the crash is strongly associated with data integrity, e.g. memory 
corruption or invalid free's, then it would get a CVE - since we make a 
conservative assumption that a code-execution exploit *might* be found by 
someone, and the consequence might be more than DoS.  I've been somewhat 
agnostic about out-of-range reads.

However, such crashes that appear in the *libraries* provided by ffmpeg 
would qualify, since those libraries might be used in an independent 
product for which a crash is a security issue (for example, a product 
might use a library function to convert the audio for a large number of 
files that have been uploaded from many users, and a single crash prevents 
other users' files from being converted.  In this way, shared libraries 
are treated more conservatively.)

- Steve