oss-security - Re: CVE id request: vlc

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Tue, 11 Nov 2008 09:13:33 +0100
From: Rémi Denis-Courmont <rem@...eolan.org>
To: "Steven M. Christey" <coley@...us.mitre.org>
Cc: Nico Golde <oss-security+ml@...lde.de>, oss-security@...ts.openwall.com, 
 coley@...re.org
Subject: Re: CVE id request: vlc

   Hello,

On Mon, 10 Nov 2008 16:27:00 -0500 (EST), "Steven M. Christey"
<coley@...us.mitre.org> wrote:
> The information we had available at the time of request didn't suggest
> different versions being affected.  For example, the upstream advisory
> doesn't mention anything about different versions, and both Tobias Klein
> advisories say "VLC media player < 0.9.6".

CUE: 0.5.0 - 0.9.5 (as per http://www.videolan.org/security/sa0810.html)
RealText: 0.9.0 - 0.9.5

0.9.* is the only supported version from videolan.org anyway.

> So at the time of assignment, Best Available Information (the cornerstone
> of CVE analysis) was that they were the same type of issue affecting the
> same versions.

> This is becoming a big problem for us in CVE - requests to oss-security
> are coming in without the kind of information that we rely on heavily to
> decide when we have one CVE or multiple CVE's.  Compared to last year,
the
> requests are coming in when the information's less mature, *and* public.

CVE.mitre.org says nothing about vendor obtaining a CVE number, only
researchers. And typically, these guys don't do it, when dealing with
videolan.org anyway.

Also consider our project structure: We have a large code base with lots of
legacy, so lots of bugs. We have a large user base, so we're an attractive
target. We have had very few security analysis until recently, so there is
a lot more CVEs to come by any chance. We're almost entirely run by loosely
coordinated volunteers (including myself) so you cannot expect much more
dedication. And we are hardly supported by distributions (basically only
Debian and Gentoo), such that almost nobody will care on vendor-sec.

Now I am happy to adapt our security handling process a bit, if MITRE,
Debian or whatever other involved party wants. But I am still waiting for
clear guidelines.

N.B.: I am not subscribed to this mailing list

-- 
Rémi Denis-Courmont

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.