Initial Guidance on Linux Issues

["Mann, Dave" <damann@mitre.org>]

Folks,

In our other active thread, we've been discussing how to handle provisioning CVE ids for Linux issues.  There is broad agreement that the following Linux sources are critically important to track: Debian, Red Hat, Attachmate: SUSE, Ubuntu (Linux).

These sources are incredibly problematic for us.  Ensuring that there is full coverage for all issues disclosed from these sources while also ensuring that the descriptive information in our CVE entries are of the same quality as traditional CVE entries is simply out of reach.   There are 2 thorny issues and the team is working on some proposals.  Hopefully this note will help frame the discussion


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).  This is very different from traditional operating system vendors where there is a clearer distinction between the OS and 3rd party applications.  For other traditional platforms, we don't (and can't) provision CVE ids for all possible 3rd party applications that can be installed. 

We believe it is necessary for CVE ids to be provided for all packages that would be commonly associated with a Linux installation but we are struggling with a way to define this.   We know it's more than just the kernel.  We know it can't be all packages.  The question is, how do we define the set of things which we'll ensure that CVE ids are issued for on Linux systems.


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.  Currently, the Linux kernel development community uses non-published CVE ids to coordinate with each other prior to the release of vulnerability information and patches. The problem comes when the CVE ids are made public in the release notes.  There's generally not enough information contained in them for us create well formed CVE definitions.  It is also difficult and time consuming to try to disambiguate the "affected versions" information (sometimes impossible).   As a practical result, there is a significantly large and growing set of CVE ids being used in the wild that are not documented on the official CVE list beyond "reserved". 


Again, we're working on some proposals to address these issues, but a) we wanted to more clearly define what the issues are so you can begin thinking about them and b) we hope you can offer some creative solutions. 



-Dave
==================================================================
David Mann | Principal Infosec Scientist | The MITRE Corporation
------------------------------------------------------------------
e-mail:damann@mitre.org | cell:781.424.6003
==================================================================