[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initial Guidance on Linux Issues

> DEFAULT INSTALATION & COMMON PACKAGES - These vulnerability information 
> sources include vulnerabilities in (pretty much) all packages that get 
> installed via their package management capability (e.g. rpm).

To put some numbers to it; a Red Hat Enterprise Linux 6 distribution ships 
with ~2100 packages (counting source packages to better map to 
'projects').  The actual packages you get installed on your system depend 
on which variant you install, as well as what options you select when 
installing.  For example, a totally default installation of Red Hat 
Enterprise Linux 6 Server would get you ~760 packages.

I'm sure most customers of that product end up with more than packages 
from 760 source rpms on their system, although on a machine by machine 
basis it could vary anywhere from a few hundred, to 2100.

All 2100 packages get full support for addressing security issues (i.e. 
our security response team track issues in every one of those upstream 
projects and will fix issues that are found and produce security updates. 
We treat all packages equally and speed and quality of fix are not 
determined by the package being default or otherwise).

Each of the security issues fixed gets a public bug where there should be 
sufficient technical details to be able to allow CVE to create well formed 
definitions.  (We're often told by security research firms that they use 
the Red Hat bugzilla to find out more about CVEs).

And all the main Linux distros are CVE candidate naming authorities 
anyway.

I don't think commercial supported distributions are the problem for CVE, 
it's probably more of a problem for things like Fedora (Fedora 16 by 
comparison has ~11000 packages) where the number of security issues 
multiplies significantly.  We've been trying to minimise this problem by 
asking for more information before giving out CVEs on oss-security list 
for example.

I'd solve this by having a minimum threshold required to get a CVE name; 
and apply the same requirements to each CNA, only allowing them to 
allocate names for OSS issues that will have a mimium defined set of 
information, such as:

- fixed version [required]
- pointer to patch or affected code segment [required]
- flaw type (CWE or text) [required]
- affected versions or first vulnerable version [nice to have]
and so on.

> KERNEL ISSUES - We are committed to working to ensure that Linux kernel 
> issues have CVE ids but on practical basis, this poses tremendous 
> problems due to the way the Linux kernel is developed.

Prior to the kernel.org compromise we kept a git tree with details of all 
the kernel issues that got CVE names along with affected versions, links 
to upstream and so on.  This got lost, but we're going to restart it.  For 
the subset of issues that affect Red Hat our bugzilla should contain all 
the info necessary for a good CVE definition.

Mark
Page Last Updated or Reviewed: November 06, 2012