Merging Core and Extras affecting security updates

[Mark J Cox]

> 1. Data acquisition
>   - keep track of vulnerabilities
>     - CVE (a good start but it should not be the only source of data)
>     - vulnerability databases (Bugtraq, OSVDB, Secunia...)
>     - mailing lists (Bugtraq, Full-disclosure, Vendor-sec...)
>     - other distros (they might have caught something we missed)
>     - Oval?
>   - weed out bogus reports (false reports, issues for MS Windows...)
>   - merge duplicate reports
>   - update existing reports when needed (exploit availability...)

That's a good summary of the process the Red Hat security response team 
currently follow -- with the addition that when we discover something by 
tracking that doesn't have a CVE we ensure that it gets a CVE name 
assigned to it.  Therefore the CVE list can be used as a definitive list 
for anything that may affect Red Hat or Fedora (indeed for Fedora tracking 
right now we base it off the CVENEW mails)

(OVAL just provides a way of expressing how to detect the presence of some 
particular CVE named flaw)

> This sounds like a task for CVSS:

I don't believe CVSS really works for open source software (or indeed any 
software that is shipped by multiple vendors).  Even assigning a Base 
score is tricky to do.  Is that flaw in ImageMagick where a buffer 
overflow could be triggered if you open a malicious file you were given 
"remote" or "local"?  The attacker is remote.  If you argue it's "local" 
then how about a flaw in something like xpdf?  is that also local?

NVD say these are "user complicit" and marked as local.  But doesn't it 
depend on if xpdf is associated with pdf files in your web browser?  It's 
no user complicit if all you need to do is visit some malicious website.

How about if the flaw is in some widely used library like libpng; won't 
the local/remote rating depend on exactly what software is using that 
library in what ways?

Then you have to take into account the version of Fedora Core or RHEL as 
each has different security technologies.  Some double-free flaws can lead 
to a complete loss of integrity on some systems, but no loss of integrity 
but partial availability on others.

We do currently assign severities though, but we use a simple 4-level 
scale with defined actions and goals for dealing with each level (for 
example we aim to get a fix out for a critical vulnerability within a day 
of it being public so we have to start paging people).

Thanks, Mark
-- 
Mark J Cox / Red Hat Security Response Team