Re: [OPSAWG] 2nd try: how many SBOMs do we need to locate and discover?

[Dick Brooks <[e-mail]>]

Hi Eliot,

This information is being provided as justification to support multiple SBOM's that may be required to conduct a comprehensive software supply chain risk assessment. I propose adding a new component level data element, called SBOMURL at the component level  to enable discovery and access to a SBOM object to provider context needed to conduct a more extensive vulnerability search 

I encountered this issue when testing SAG-PM (TM).

Scenario: A new openssl bug is reported and I perform a software risk assessment using an SBOM that I know contains openssl; https://nvd.nist.gov/vuln/detail/CVE-2021-3450 a NIST NVD search of the filenames listed in the SBOM fails to detect the newly reported vulnerability, resulting in a false negative result.

An "extrapolated" SBOM , created by SAG-PM (TM) using the binary installation package,  lists the components that are present in the software package being analyzed, including these two entries for openssl:

It's impossible to know that these two components are part of the openssl package, from the filename information in the installation file. This is where an SBOMURL "tag", associated with each file, could provide the missing context.

FileName: libeay32.dll
SPDXID: SPDXRef-c752fdaa-b140-46ab-a564-2934d73c790d
FileType: BINARY
FileChecksum: SHA1: 731d2a30790eece1f7ef54dd3e7774d65c09a298
LicenseConcluded: NOASSERTION
LicenseInfoInFile: NOASSERTION
FileCopyrightText: NOASSERTION

FileName: ssleay32.dll
SPDXID: SPDXRef-8381311b-8222-4ae7-a2d6-0c7815d92514
FileType: BINARY
FileChecksum: SHA1: 731d2a30790eece1f7ef54dd3e7774d65c09a298
LicenseConcluded: NOASSERTION
LicenseInfoInFile: NOASSERTION
FileCopyrightText: NOASSERTION



A NIST NVD vulnerability scan on the software components listed in the SBOM fails to detect the newly reported openssl CVE; see NVD results below:

----->Searching NISTNVD using: https://services.nvd.nist.gov/rest/json/cves/1.0?keyword=libeay32.dll
---------->Total NIST NVD Vulnerabilities Found:  2
CVE: ID: CVE-2019-12572 CVSS: 7.8  Description:  A vulnerability in the London Trust Media Private Internet Access (PIA) VPN Client 1.0.2 (build 02363) for Windows could allow an authenticated, local attacker to run arbitrary code with elevated privileges. On startup, the PIA Windows service (pia-service.exe) loads the OpenSSL library from %PROGRAMFILES%\Private Internet Access\libeay32.dll. This library attempts to load the C:\etc\ssl\openssl.cnf configuration file which does not exist. By default on Windows systems, authenticated users can create directories under C:\. A low privileged user can create a C:\etc\ssl\openssl.cnf configuration file to load a malicious OpenSSL engine library resulting in arbitrary code execution as SYSTEM when the service starts.
Press Enter to continue vulnerability search, s to skip to next component or q to exit:
CVE: ID: CVE-2019-19741 CVSS: 7.8  Description:  Electronic Arts Origin 10.5.55.33574 is vulnerable to local privilege escalation due to arbitrary directory DACL manipulation, a different issue than CVE-2019-19247 and CVE-2019-19248. When Origin.exe connects to the named pipe OriginClientService, the privileged service verifies the client's executable file instead of its in-memory process (which can be significantly different from the executable file due to, for example, DLL injection). Data transmitted over the pipe is encrypted using a static key. Instead of hooking the pipe communication directly via WriteFileEx(), this can be bypassed by hooking the EVP_EncryptUpdate() function of libeay32.dll. The pipe takes the command CreateDirectory to create a directory and adjust the directory DACL. Calls to this function can be intercepted, the directory and the DACL can be replaced, and the manipulated DACL is written. Arbitrary DACL write is further achieved by creating a hardlink in a user-controlled directory that points to (for example) a service binary. The DACL is then written to this service binary, which results in escalation of privileges.


----->Searching NISTNVD using: https://services.nvd.nist.gov/rest/json/cves/1.0?keyword=ssleay32.dll
---------->Total NIST NVD Vulnerabilities Found:  1
CVE: ID: CVE-2010-5232 CVSS: 6.9  Description:  Untrusted search path vulnerability in DivX Plus Player 8.1.0 allows local users to gain privileges via a Trojan horse ssleay32.dll file in a certain directory.  NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.
Press Enter to continue vulnerability search, s to skip to next component or q to exit:

Thanks,

Dick Brooks

Never trust software, always verify and report! ™
http://www.reliableenergyanalytics.com
Email: [e-mail]
Tel: [phone]

-----Original Message-----
From: OPSAWG <[e-mail]> On Behalf Of Eliot Lear
Sent: Wednesday, April 14, 2021 11:41 AM
To: opsawg <[e-mail]>
Subject: [OPSAWG] 2nd try: how many SBOMs do we need to locate and discover?

It seems that my mail system ate my first attempt at this.

One of the questions I raised in the opsawg meeting was how many SBOMs we would need to be able to retrieve.  I am looking for use cases where there would be more than one.  To me, I think the place to look is around VMs and containers, where the SBOM might be internalized.  But that’s just one model. Another model would be that the container SBOM is hierarchically incorporated into the overall device SBOM.  If that is done by reference, then I guess we get more than one.  And every time we try to define what a device is at the IETF we seem to get burned if the model is not flexible.

Thoughts?

Eliot