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 (#186725): https://lists.openembedded.org/g/openembedded-core/message/186725 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] -=-=-=-=-=-=-=-=-=-=-=-
