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

[Jo-Philipp Wich]

Hi,

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].


FORMAT

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:

  PKG_CPE:=cpe:/a:busybox:busybox


USAGE

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.


IMPLEMENTATION

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.


CONSIDERATIONS

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.


RESPONSIBILITY

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.

Thanks,
Jo

--

1: http://cpe.mitre.org/
2:
https://nvd.nist.gov/vuln/search/results?adv_search=true&cves=on&cpe_version=cpe:/a:busybox:busybox