[LEDE-DEV] [RFC] adding CPE IDs to package Makefiles

Jo-Philipp Wich jo at mein.io
Sun Oct 1 05:43:03 PDT 2017


I'd like to propose adding structured CPE information to package
Makefiles in order to simplify mapping of discovered vulnerabilities to
affected LEDE software components.

The Common Platform Enumeration (CPE) specification provides a
standardized way to name software packages and versions, which allows
for automated processes to match security advisories containing CPE IDs
with affected software. You can read up on CPE at [1].


The proposed format for adding CPE IDs to Makefiles would be a new
variable called "PKG_CPE" which is set to the corresponding ID of the
package. Multiple ids may be specified, separated by space.

For example the busybox package Makefile at
package/utils/busybox/Makefile would contain an entry like:



The main intended use case for the PKG_CPE entries is automated
vulnerability surveys by periodic jobs. A given CPE ID can be used to
look up past and current security advisories affecting a specific
component, making it easy to relate CVEs to Makefiles.

Considering the busybox example above, we can use the value of PKG_CPE
to obtain a list of advisories [2] and match them against our packages.


Initially some effort is required to properly map important packages and
their respective Makefiles accordingly, afterwards PKG_CPE variables can
be added on a case-by-case basis, e.g. whenever a vulnerability for a
not-yet tagged package is being handled.

We may also encourage contributors to already provide suitable PKG_CPE
entries in new package submissions.


While the CPE IDs allow us to relate a given Makefile to a list of past
and current CVEs, they provide no means to decide whether a given CVE
already has been addressed by the LEDE developers and package maintainers.

In order to track the vulnerability status of CVEs I propose to:

 - Define a cut-off date and develop the survey scripts to ignore any
   CVEs prior to that

 - For any security fixes made to a package after the cut-off date
   require developers to mention the fixed CVEs in either the commit
   subject or the commit message, for example:

     busybox: update to 1.24.0

     This updates the busybox package to version 1.24.0 and fixes an
     access restriction bypass in modprobe (CVE-2014-9645).

     Signed-off-by: Package Developer <dev at example.org>

Additional steps that can be taken to improve vulnerability tracking:

 - Add version vector to CPE entries, e.g.
   "cpe:/a:busybox:busybox:1.23.0" instead of "cpe:/a:busybox:busybox"

   Downside here is that it is easy to miss updates to the ID when
   bumping the package version.

 - Provide an additional out-of-band facility to mark CVEs as fixed,
   e.g. a "security.txt" file next to the package Makefile.

   Such a file would allow enumerating addressed advisories when a CVE
   ID was missed or misspelled in a commit. Structure and scope are yet
   to be defined.

 - Develop vulnerability survey scripts to take PKG_VERSION and
   PKG_REVSION fields into account when looking up CVEs to avoid false
   (past) positives.


Given a consensus on a final proposal I am willing to implement the
initial pieces of such a CVE mapping infrastructure, mainly:

 - Take care of adding the appropriate PKG_ID entries to core packages

 - Write CVE mapping and vulnerability reporting scripts

 - Implement an automatic advisory report and status tracking web page


Please let me know what you think about this approach and feel free to
drop some comments.



1: http://cpe.mitre.org/

More information about the Lede-dev mailing list