Software Bill of Materials (SBOM) are gaining momentum within the industry, largely due to the enactment of the “Executive Order on Improving the Nation’s Cybersecurity”[1]. This act will lay the foundations for formally publishing an “ingredient list” for software based products. This ingredient list is intended to provide transparency to the software ecosystem, and aid with the ongoing process of vulnerability and software lifecycle management.
Memory safety, we know accounts for a huge proportion of these vulnerabilities that need managing. The NSA guidance on NSA safety [2] clearly outlines the nature scale of the problem. This publication refers to both Google [3] and Microsoft [4] research indicating that up to 70 percent of their vulnerabilities were due to memory safety issues.
The NSA guidance provides recommendations on how to mitigate some of these memory vulnerabilities, covering defensive programming techniques that can be used in long established programming languages (C/C++) through to recommendations on memory safe languages to adopt in new projects.
Another approach, is the use of fundamentally novel micro processor architectures that provide optimised defence capability built at the silicon level. These techniques are an active area of research for University of Cambridge [5], which have been embodied by ARM on prototype hardware, Morello [6]. Google, Microsoft and HP are also participants in this UK sponsored research activity [7]
So the practical question to be asked: how do these initiatives tie up? Can some benefit be derived by conjoining some of the activities?
The simple answer we think is yes. Let’s look at the issues through two different lenses.
Lens 1: SBOM perspective
SBOM seeks to describe a software based system through a series of components. The vulnerability surface of that system should be approximated by aggregating the vulnerability surface of each component.
Where each component is described by a CPE https://nvd.nist.gov/products/cpe
And each (most) vulnerabilities reported (CVEs – https://nvd.nist.gov/vuln) have a mapping to a CPE
Then it follows that we can estimate the vulnerability surface of a system by iterating through the components and their attached vulnerabilities.
This is very much how SBOMs are supposed to work, with regard to vulnerability management. And the theory is sound. However in the real world this method tends to produce an excess of reported vulnerabilities, including a host of false positives. To counter this problem the concept of a VEX [8] (Vulnerability Exploitability eXchange) has been introduced.
A VEX is
- VEX stands for Vulnerability Exploitability eXchange. It is what NTIA describes as a “companion artifact” to an SBOM and is the idea that product manufacturers and software suppliers can discover (using tools like FACT) vulnerabilities within third-party dependencies of their products and preemptively assess the exploitability of these vulnerabilities. This is important because not all vulnerabilities merit panic. In many cases, a vulnerability may exist in a component, but for the specific product in question, it is inaccessible to attackers or missing entirely. For example, the famous HeartBleed vulnerability in OpenSSL required specific features to be activated in a product in order to make the vulnerability exploitable in ICS products like firewalls. [8]
Here I think we have our first major interaction with CHERI based systems. If we take a CHERI platform running a PureCap package surely we have a strong method to “preemptively assess the exploitability of these vulnerabilities.” Very specifically, the entire premise of a PureCap component is that it will explicitly remove the exploitability of entire classes of vulnerabilities. Our hypothesis is, a CHERI aware and enabled system has potential direct interactions both with the SBOM descriptors and the VEX companion document. This information directly enhances the usability of the SBOM furnished material to actively manage software vulnerabilities.
Lens 2: CHERI perspective
Now lets change perspective and look at the problem from another direction. CHERIfication of a system (indeed any memory safety intervention), comes at a cost. To justify this investment, and even when justified, to plan and prioritise the activity we need evidence. This evidence needs to be data based and help guide us where we achieve the most bang for our buck.
If we have a system, with a known (or estimated) vulnerability surface, by projecting the anticipated vulnerability surface after an intervention, then presumably we have a solid empirical framework on which we can project the optimal impact of our interventions. A system which is described in terms of SBOMs, with good CPE to CVE mappings and with good characterization of CVEs (to help us determine which interventions will neutralise it), provides us just such a framework.
This analytical approach has particular value for CHERI. To achieve market impact, silicon manufactures and their customers (device OEMS) need to be persuaded of the value of the technology, in order to make the significant systemwide investments required to bring a new ISA architecture to market. The approach outlined above, provides the basis of the method of estimating this security impact. This approach can be tuned to be device specific, adopting the appropriate SBOM for the analysis. This allows “customers” to analyse impacts market by market.
Planned activities
This brief note attempts to tie together two important industry trends: SBOM and the description of software based systems as components and the issue of memory vulnerabilities and the memory safety interventions that can be used to reduce this risk.
Very specifically we try to highlight:
- How CHERI like systems can be integrated into the existing SBOM and VEX operational tool chain, and the value they add to that system.
- How SBOM oriented analysis can be used to develop the evidence base for CHERI like interventions, and help guide and prioritise such activities.
These subjects are active areas of research we are pursuing under the ManySecured community and we welcome active contributions and comment from interested parties.
[2] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
[3] Microsoft® (2019), “Trends, challenges, and strategic shifts in the software vulnerability mitigation landscape”. https://github.com/Microsoft/MSRC-SecurityResearch/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20- %20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20miti gation.pdf
[4] Google (2021), “An update on Memory Safety in Chrome”. https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html
[5] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[6] https://www.arm.com/architecture/cpu/morello
[7] https://www.dsbd.tech/whos-involved/
[8] https://blog.adolus.com/what-is-vex-and-what-does-it-have-to-do-with-sboms
