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

[Kurt Seifried]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/20/2013 02:11 PM, Brian Martin wrote:
> The current system makes that time-consuming and 'cost' prohibitive
> to us.

Understandable.


> The list isn't "incorrect", we simply missed one (likely a few) CVE
>  assignments, again because of the varied places they can pop up
> for initial disclosure. While we follow OSS-Sec almost daily,
> sometimes the delays in assigning via that list (e.g. when there is
> discussion leading up to the assignment) is substantial as well.

Yup. I have tried to narrow that by teaching people to make better
requests so I don't have to reply back and forth with their requests.

> 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 =).

> Honestly, no, and it shouldn't be our job to do that. If a CNA is 
> releasing security fix information themselves, and not assigning a
> CVE promptly, AND including it in the public source we got the
> information from, then their CNA status should be revoked. They
> completely miss the

Agreed. I actually meant more along the lines of "has anyone notified
them at all?" in addition to the CVE messy bits. Not all vendors
actually bother to read oss-sec/full disclosure/etc on the off chance
they get mentioned.

> I understand that CVE is strained under the pressure of assignments
>  lately, and the last year of board meetings have made it clear
> that they simply can't keep up. Knowing that, I think CVE should
> focus on streamlining the process to assist the community, rather
> than keep doing the same thing. Just like CVSS is on v2, with v3 in
> the works, CVE needs to evolve every couple of years to handle the
> work load.
> 
> Also note that my mail requesting these CVEs was half in jest.
> Sure, I would love to see a CVE assigned for every known issue, but
> they have made

Me too. It makes everyone's life easier. And I think it's an
attainable goal, but probably not with our current setup/processes.

> it clear that can't happen most likely. Hell, even you have told
> Debian "no" when they gave you a concise list of security issues
> and asked for CVE identifiers. Rather than work through the list,
> you said they had to

Cause I'm lazy and already assigning buttloads of CVEs (and again,
mostly quality issues, if that list was 100% correct and guarenteed
than I could do all the cves in 4 minutes). But most of these lists
often need investigation for which I don't have time (5 minutes per
requests times 100-200 and boom my week is gone).

> post to OSS-Sec to request them. I understand your decision to do
> so, but it also speaks to the problem of volume.
> 
> Earlier last year I suggested that CVE utilize more CNAs to handle
> this. I still advocate that, but I must ammend my suggestion to
> include "responsible CNAs", as most operating these days are not so
> helpful.

Yeah. One thing i have been thinking about is having specifical people
take specific projects and handle the CVE requests/make sure they are
good and then I can assign them way faster. For example WordPress (not
to pick on them, it's just a widely used package) for which the vendor
isn't doing CVE requests/etc. and people want them to have CVEs
someone could step up and handle that. Get a few dozen people and
suddenly we have much better coverage of popular software. So they
wouldn't be a CNA, but maybe some sort of semi official
"CVE-Requestor" and so for Wordpress I only take requests from that
person, and point reporters at them. This way most of the grunt work
gets farmed out and done and the CVE assignment no longer need
research since it's already been done. Steven: thoughts/comments? If
it were quasi official that would probably help.

> 
> Brian
> 


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

iQIcBAEBAgAGBQJRShuVAAoJEBYNRVNeJnmTalcQAKwjPfJTl3dAKpK1DklCGQgr
kZzuOt32PASMh1dEFMQxjrH11CiBzWOK0B1gqdGvsGg5LBJWhSmw8wwO8dd8BWe/
0r1F3Zdkc3Ib9S0CdmBFFmTNCqA2Oj66Rv56Td2JLMvCoFLn9zR/Suq+iYx5yQg4
635MhiPhPQ1hfDlk6ZWEm4kVxcJdfyqVZnzNzvXNr41e8N0lIKtbRK3hs9RvXeHs
5K+bq3KG8BIwkQqVtwSYPV2Yaddt5jhwHJbMc11L7pHIersqZIYqFdn/SyfYBx8x
Tc97Uv/oxMqlRpKtthAe5KshohcGCBJA1v/I3MpKZbV7SYZoANmFspoL/9E4RWtc
7bxBd2ZR/1sn7pkvO3lMAwiky+Mc/a5Knsp9dai+cxAKV4bBaCqTQZYYp15wFIbN
dX7zQc96Ts6U/htzZrFRoFj6S5o63kkQt+mSCu0v6p74BMpCCefPQsENSMXU9P1P
6RX+MaFFNjBYfQ7je62lJFJdeIY+l9NrzKY9hVx7H0Nj1m2so6K9ZEVu2muPeLgd
b/4L5cHbrCG3dmtsmAp9gfkL17kJJqDHsZuJGM+t3ptEXFe9Ak1CH7R8iwDW8P0O
OKqSOBe8tDNA95PNPeuUuQQjT0AHnR7CSX+g/nQ3cbwEAU+DokX5durXlABp3zFX
tgqgfgrb0MQRV7WXpOl9
=G7gC
-----END PGP SIGNATURE-----