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

[Hauke Mehrtens]

On 10/01/2017 02:43 PM, Jo-Philipp Wich wrote:
> 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].

This looks useful and I would like to see this integrated.

> 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"

Can't we just take the version from the PKG_VERSION entry and provide a
way to overwrite it with some other variable in case the CVE database
uses a different version number format?

We could check if this version number is available in the CVE database
and warn the user if this is not the case, but we could probably cover
90% of the packages.

>    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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>