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 <d...@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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
