[VIM] 267 Missing CVE in Jan, 2013 - please assign

Kurt Seifried kseifried at redhat.com
Wed Mar 20 15:49:14 CDT 2013

Hash: SHA1

On 03/20/2013 02:39 PM, Brian Martin wrote:
> On Wed, 20 Mar 2013, Kurt Seifried wrote:
> : > Neither do we. We already spend a *lot* of time trying to get :
> > timely CVE information added to our entries. So I asked CVE to
> deal : > with these assignments, not you, or OSS-Sec, or any other
> CNA. : : Ah ok, I generally handle Open Source stuff so I assumed I
> was wanted : =). I also want to go through that list and make sure
> everything that : affects Red Hat is covered (cause that's what I
> get paid to do =).
> As such, I'd imagine you are slowly working through that Debian
> list for Red Hat's benefit, if not as a CNA?

At some point I might, but like I said I already work more then 40
hours a week (plus other time commitments like sleep and family) so
giving more time to CVE is hard, I try to maximize the work I put in.
oss-sec is relatively good because these are people that care enough
to make requests and I can poke them back to fix their requests by
hitting the reply button, going through a debian/osvdb list takes a
huge amount of time in comparision, if I find an issue I then need to
figure out how to contact the reporter, who by definition doesn't care
about CVE or they would have already asked for it, so that turns into
a huge time sink. As you no doubt know =).

> Quite a few of our entries that do not have CVE (historical, not
> just Jan 2013) are actually from vendor sources. Changelogs, bug
> trackers, etc. So yes, many of them are aware of the issue, just
> that they don't know the value of getting a CVE or simply don't
> care.

Yeah and those take forever to assign because the things I need to
assign a CVE are usually missing (by definition anyone doing really
good security reporting for their project/etc. will also be getting
CVEs usually).

> Right now, it is taking me a good 15+ minutes per entry to create
> an ID on our side. The time is spent reading the bug report (when
> possible), looking for upstream vendor URL, changelog, etc. One of
> our biggest 'problems' when a Linux distro reports/fixes a bug, is
> that the solution is specific to that distro. We have to then check
> upstream to see if the vendor fixed it or not, and mangle
> accordingly. I don't think that the Linux distro is responsible for
> doing that, don't get me wrong. Just how we operate as we create
> entries based on the 'root cause' as much as possible.

Yup. I did that for 9.5 years at iSIGHT/iDefense, one of the reasons I
left (I was going insane).

> WordPress and Drupal, by way of their 92384 extensions, and soon to
> be Ruby by way of their 92384 gems, should each have 1 person doing
> CVE assignments. That would make all of our lives a lot easier.

Yah. I'm engaging with the ruby community, they seem receptive at the
higher levels (e.g. the people who run rubygems.org), engaging with
the end devs is pointless, there are simply to many (50k gems times 1+
dev/owner per gem, not all speak english, or care, or are alive,
etc.). We need solutions that scale, what they are, I'm not sure.

> Brian

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.13 (GNU/Linux)


More information about the VIM mailing list