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: d...@reliableenergyanalytics.com
Tel: +1 978-696-1788

-----Original Message-----
From: OPSAWG <opsawg-boun...@ietf.org> On Behalf Of Eliot Lear
Sent: Wednesday, April 14, 2021 11:41 AM
To: opsawg <opsawg@ietf.org>
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

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to