Hello again,
I have kept been pondering on this topic for quite some time and have
after quite some thought come to the conclusion that the mismatch in
the CPE Name Matching actually is due to a wrong interpretion of the
specification on the side of the dependencytrack maintainers and by
extension myself
(see https://github.com/DependencyTrack/dependency-track/issues/2988
for more details). So all-clear on that frontline. Sorry for the fuzz.
However, I still stand by the idea of providing more detailed CPE
information (e.g. target architecture) to avoid false positives, as
well as making openembedded-specific CVE reports possible.
Also, I believe it should be possible to gather the missing pieces of
information in an automated fashion by using a migration script for the
layers by leverage of the NIST CPE API. Using the cpeMatchString
parameter and the information we already have (product name and
version), we can attempt to guess the correct Part and Vendor
parameters:
// This might fail, if there is no CPE for current version (yet).
// However, might provide more accurate results.
if API(cpeMatchString="cpe:2.3:*:*:product_name:product_version:..."):
gather_facts_from_first_result
// If no matching CPE found:
// Reduce the product_name, which might result in less accurate results
else if API(cpeMatchString="cpe:2.3:*:*:product_name:*:..."):
gather_facts_from_first_result
// CVE unknown: Either name mismatch or no entry exists for this
product.
// Manual check required.
else:
CVE_*=unknown
This will reduce manual labor to feasibility checks, rather than
information gathering.
Leveraging the same mechanism, we could also attempt to guess the CPE_*
information when invoking the recipetool for the creation of new
recipes.
This would allow for a quick adoption and flatten out the path for
making these variables required by default, in turn improving reporting
and security for openembedded products.
Cheers, Jasper
On Fri, 2023-08-25 at 09:57 -1000, Steve Sakoman wrote:
> On Fri, Aug 25, 2023 at 9:18 AM Jasper Orschulko via
> lists.openembedded.org
> <Jasper.Orschulko=iris-sensing....@lists.openembedded.org> wrote:
> >
> > Hi Richard,
> > hi all,
> >
> > I want to address a flaw in the current CPE generation
> > functionality in
> > openembedded, which renders the CPEs unusable in regards to the
> > minimal
> > requirements of the NIST CPE Name Matching Specification standard
> > (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf).
> >
> > This makes working with the generated CPEs in thirdparty software
> > close
> > to impossible, as it would require the thirdparty software to
> > implement
> > matching logic beyond the requirements defined in the NIST
> > standard.
> >
> >
> > Status quo:
> >
> > Currently, the CPE is generated from the optional CVE_PRODUCT
> > (optionally including the vendor) and CVE_VERSION variables. If
> > neither
> > are provided, CPE generation will fall back on the BPN and PV of
> > the
> > recipe.
> >
> > As a result, the generated CPE will usually look as follows:
> >
> > cpe:2.3:*:*:${BPN}:${PV}:*:*:*:*:*:*:*:*
> >
> > Or, if the CVE_PRODUCT includes a vendor:
> >
> > cpe:2.3:*:${vendor}:${product}:${PV}:*:*:*:*:*:*:*:*
> >
> >
> >
> > The Issue (The TL;DR):
> >
> > This will return zero¹ matches when doing CPE matching against CVE
> > CPEs
> > in accordance with the minimal requirements of the NIST Name
> > Matching
> > Specification. For reliable matches the components CPE should be as
> > precise as possible, i.e. not containing any "*" (ANY) values for
> > vital
> > attributes, such as: Part, Vendor, Product, Version, Target_HW.
> >
> >
> >
> > The Issue (In detail):
> >
> > To understand the issue in full detail, in depth knowledge of the
> > NIST
> > specification is required. However, I will try to provide a
> > comprehensive summary below:
> >
> > CPE matching is done using a source CPE and target CPE. Due to
> > limitations (see Table 6-2, cases 4 & 11), using the CVE CPE as a
> > source and the component CPE as a target is the only sensible way
> > (otherwise a CVE CPE containing wildcards would lead to undefined
> > behavior).
> >
> > Each attribute of the CVE CPE, will then be matched against the
> > component CPE, setting the relationship of each source attribute to
> > the
> > corresponding target attribute to either superset (⊃), equal (=),
> > subset (⊂) or disjoint (≠) (see Table 6-1, example: Table 6-3).
> >
> > The NIST standard then defines 4 required CPE Name Comparison
> > Relations
> > (see Table 6-4), with two of them relevant for what we would
> > consider a
> > "match" between a CVE CPE and a component CPE:
> >
> > If all attribute relations are EQUAL (=) -> Then CPE name relation
> > is
> > EQUAL (=) -> match
> >
> > If all attribute relations are SUPERSET (⊃) or
> > EQUAL (=) -> Then CPE name relation is SUPERSET (⊃) -> match
> >
> > Let's take a look at this, based on a real-world example:
> >
> > CVE CPE: cpe:2.3:o:linux:linux_kernel:5.15.37:*:*:*:*:*:x86:*:*
> > Component CPE: cpe:2.3:*:*:linux_kernel:5.15.37:*:*:*:*:*:*:*:*
> >
> > In this example the CVE CPE has the attributes "Part" ("o"),
> > "Vendor"
> > ("linux") and "Target_HW" defined, while the Component CPE sets
> > these
> > attributes to "ANY", thus the CVE CPE attributes are subsets of the
> > component CPEs (see Table 6-2, case 13), making the entire CVE CPE
> > a
> > subset of the component CPE, thus causing a false-negative.
> >
> >
> >
> > Proposed solution:
> >
> > Openembedded should, in accordance with the CPE Naming
> > Specification
> > (https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf),
> > provide
> > complete and accurate CPE information (at least: Part, Vendor,
> > Product,
> > Version, Target_HW) for recipes in order to avoid false-negatives
> > during CVE CPE comparison and ensure compatibility with other
> > tools.
> >
> > A component CPE could then look like this (something I came up with
> > in
> > 5 minutes, enjoy with a grain of salt):
> >
> > cpe:2.3:o:linux:linux_kernel:5.15.37:<COMPONENT_SHA_COMMIT_HASH>:*:
> > open
> > embedded:<OPENEMBEDDED_RELEASE>:<TARGET_ARCH>:en_US (is there a
> > bitbake
> > variable for this?):*
> >
> > Setting attributes such as SW_Edition = "openembbeded" and
> > Target_SW =
> > "<OPENEMBEDDED_VERSION>" also has the positive side-effect of
> > allowing
> > for the registration of openembedded-specific CVEs, e.g.
> > vulnerabilities in patches within recipes.
> >
> > Of course, this is easier said than done, as some of the required
> > information, especially "Part" and "Vendor" is missing from
> > existing
> > recipes.
> >
> > I therefore, suggest the following approach:
> >
> > Step 1 (non-intrusive):
> >
> > Introduce a new, optional variable CVE_PART, which is set to "a"
> > (application) by default but may be overridden in a recipe (e.g.
> > for
> > linux_kernel)
> >
> > For consistency: Introduce the new, optional variable CVE_VENDOR as
> > a
> > replacement for the CVE_PRODUCT "double role" (for backwards
> > compatibility, we can evaluate CVE_VENDOR first, then check for a
> > vendor within CVE_PRODUCT).
> >
> > Adding already existing information from the build (e.g. Target_HW)
> > to
> > the CPE.
> >
> > Start filling in CVE_VENDOR for core recipes (openembedded-core).
> >
> > Optional: Step 2 (enforcement):
> >
> > Once a certain threshold of recipes with complete information is
> > reached, we might want to consider enforcing explicit CVE_*
> > variable
> > declaration by default, with an option for disabling this behavior
> > (e.g. introducing a variable CVE_UNKNOWN), similar to the LICENSE
> > variable bahavior.
> >
> >
> > I hope I was able to give some insights on why I believe that
> > improvements to the openembedded CPE generation process, as well as
> > to
> > information provided by the recipes (even though a diligent task)
> > are
> > vital.
> >
> > I am looking forward to your feedback on this.
> >
> > Cheers,
> > Jasper
> >
> >
> > ¹: This is also partly due to my
> > commit
> > https://git.openembedded.org/openembedded-core/commit/?id=e7c1def3c3c3a72249802ef6fb64292277a7a53e
> > which, while technically correct, makes a bad situation even worse.
>
> I suspect that means that I shouldn't take this patch for the stable
> branches?
>
> Steve
>
> > Still, only a handful of recipes which happen to be of type
> > "application" and explicitly set the "vendor" attribute, had the
> > chance
> > to successfully match some (but not all) CVE CPEs. False negatives
> > would still lie at > 99%.
> >
> >
> > --
> > With best regards
> >
> > Jasper Orschulko
> > DevOps Engineer
> >
> > Tel. +49 30 58 58 14 265
> > Fax +49 30 58 58 14 999
> > jasper.orschu...@iris-sensing.com
> >
> > • • • • • • • • • • • • • • • • • • • • • • • • • •
> >
> > iris-GmbH
> > infrared & intelligent sensors
> > Ostendstraße 1-14 | 12459 Berlin
> >
> > https://iris-sensing.com/
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186742):
https://lists.openembedded.org/g/openembedded-core/message/186742
Mute This Topic: https://lists.openembedded.org/mt/100962508/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
