Buildroot:Security Vulnerability Management
There are many different vulnerability databases (open/paid). This section documents the use of the National Vulnerability Database(NVD) provided by the National Institute of Standards and Technology (NIST).
The http://autobuild.buildroot.net/stats/ includes a holistic view of all packages CVEs. This information should match the individual reports sent out to the package maintainers but double check the timestamp at the bottom of the page as the pkgstats and maintainer reports don't occur at the same time.
Package Maintainer Reporting
Each week the package maintainers listed in the DEVELOPERS file are emailed with all CVE entries applicable to the current version of the packages they maintain. In some cases these reports may list patched CVEs and a maintainer could sent in updates to the <pkg>_IGNORE_CVES list under the respective package. On the following week the report will reflect the additional CVE being filtered out. For more information on the ignoring CVEs, see https://buildroot.org/downloads/manual/manual.html under the "generic-package reference" section.
CPE stands for Common Platform Enumeration and is "a standardized method of describing and identifying classes of applications, operating systems, and hardware devices". A single product would have a set of CPE representing the configuration. A CPE dictionary is published by the US Government's NIST organization. The CPE represents the item's name, vendor, version and applicable CVE mappings.
CVE stands for Common Vulnerabilities and Exposures and is "a feed of vulnerability information that may not completely have CPE matches for all entries".
If an update is required, the direction taken, depends on where the information is incorrectly represented.
Updating CVE dictionary entries
The NIST organization manages the dictionary we use to identify CVE against packages. To make an update, navigate to https://cveform.mitre.org/ and fill out the form in a similar manner to this example fix-up of the libnids version issue. The important detail is to provide enough argument to make the change and examples of what change you'd propose. If the CPE assignment is incorrect, the next section on `Managing CPE Entries` must also be followed (as such was the case for this libnids example).
- "Select a request type" as "Request and update to an existing CVE Entry"
- "Type of update requested" is suggested to select "Other" and then provide the details in the description field.
- "CVE ID to be updated" as 2010-0751
- "Description" as "We've found that the v1.24 fixes the CVE and all prior versions contain the bug. The CVE currently lists that 1.24 is still vulnerable. This can be proved by checking the CHANGES file within the source archive(https://sourceforge.net/projects/libnids/files/libnids/1.24/libnids-1.24.tar.gz/download) that outlines this ("fixed another remotely triggerable NULL dereference in ip_fragment.c") comment. Also within that archive the source code src/ip_fragment on line 378 has the fix (https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=576281;filename=CVE-2010-1144.patch;msg=5) (NOTE 2010-1144 is a rejected CVE which was split to include 2010-0751)."
Managing CPE entries
To submit a new entry or updated entry to NIST, create a request email to the firstname.lastname@example.org recipient and if possible, attach an individual xml file per package being added/updated. It is OK to have multiple version updates in a single file as long as they are all for the same package. For reference the guidance can be found on the NIST CPE site (https://nvd.nist.gov/products/cpe). (TBD, pending patchsets to try to automate creating this xml http://patchwork.ozlabs.org/project/buildroot/list/?series=183798&archive=both&state=*)
For the example of libnids, an email was sent to email@example.com explaining the CVE description update and providing the same supporting information for making the `1.24 or before` version change.