Table of Contents:
A Bridge to Memory Safety: Leveraging Load-time Function Randomization for Immediate Protection and Liability Shift
Addressing Critical Infrastructure Vulnerabilities: Insights and Recommended Actions
Advancing Memory Safety Measures
Mitigating Memory Exploits: The Power of Load-time Function Randomization
Enabling Immediate Memory Safety
Addressing Critical Infrastructure Vulnerabilities: Insights and Recommended Actions
The looming threat China poses in attacking the US Critical Infrastructure – whether in conjunction with a military attack on China or independent of it – raises the question: what can we do to solve the most serious vulnerabilities enabling potential disruptions in service, memory-based vulnerabilities?
The default answer today through NSA Guidance and a call to action by CISA Director Jen Easterly is for industries to employ memory safe languages. However, this rewriting of code will take 10-20 years, billions of dollars, and create a significant disruption – and as such will not be available in time to fend off an attack from China.
To avoid delays in implementing memory safety through the long time frame in which memory safe languages would take to be adopted and to save money by protecting software without rewriting software, the US Government can enable Memory Safety without delay, as follows:
- Incorporate memory safe mitigation methods, such as Load-time Function Randomization, now across all critical infrastructure applications;
- Implement the shift in liability from the operator to the product manufacturer within 3-6 months; and,
- Offer safe harbor to anybody who deploys Load-time Function Randomization along with other Secure by Design / Secure by Default controls
Advancing Memory Safety Measures
With the release of the Office of National Cyber Director’s (ONCD) National Cybersecurity Strategy (NCS) document and the subsequent Cybersecurity and Infrastructure Security’s (CISA) announcement of Secure by Design / Secure by Default (SBD^2), the US Government has taken a very strong step forward to mitigate memory safety issues in software code that adversaries use to exploit software across Critical Infrastructure.
Although SBD^2 principles are sound and proven to help industries move forward with guidance, shifting to memory safe languages today is extremely difficult – and the combination will not yield memory safety immediately. This document summarizes actions that can be taken today to ensure memory safety is viable today.
By incorporating these recommendations into the rollout of Memory Safety programs going forward, the US Government can give industries the ability to shift liability and enable safe harbor immediately.
Mitigating Memory Exploits: The Power of Load-time Function Randomization
- ROP Gadgets, the building blocks for memory-based exploits, cannot be leveraged when Load-time Function Randomization is employed as they can with ASLR employed. Based on a 2023 RunSafe study, return oriented programming gadgets that leverage memory based-vulnerabilities remain effective even when Address Space Layout Randomization (ASLR). Over 40% of all CVEs are memory corruption related, and exploits targeting these vulnerabilities are nearly 100% successful even when Address Space Layout Randomization (ASLR) is present. Protecting the exact same binaries and libraries with RunSafe’s Load-time Function Randomization (LFR) reduces this memory safety exploitation risk to effectively zero (less than 1/245,194).
- Load-time Function Randomization eliminates the exploitation of all related memory CWEs and their CVEs. In a 2022 study by North Carolina State University, binary randomization mitigates over 99% of all exploits targeting memory related CWEs and their associated CVEs.
- Several production deployments of Load-time Function Randomization exist to prove it as a viable solution for industries to employ. Examples include using LFR to protect against exploitation of memory vulnerabilities, including
- Software used on Navy vessels
- Firmware used in computer servers
- Embedded code on engine controllers
- Flight management software on satellites
- Interoperability components of electric vehicle charging stations
- Load-time Function Randomization doesn’t require developers to rewrite software like deploying memory safe languages would require. LFR offers a counter to objections from industry who will object to the labor and time required. Rather than taking 5-10 years to transition memory safe languages that could cost millions if not tens of millions of dollars to rewrite products, LFR can be applied in minutes without rewriting software.
Enabling Immediate Memory Safety
- Memory safe remediation methods employing Load-time Function Randomization offers a bridge to memory safety today.
- This approach as a means of memory safe remediation methods complements SBD^2 controls and could be immediately added to the approach to enable the immediate rollout of the liability shift and safe harbor provisions of the ONCD’s NCS document and CISA’s SBD^2 program.
- The Load-time Function Randomization is proven to be more effective than ASLR and is deployed by industries today.
For people interested in detailed reading on the analysis discussed above, please contact us for these research summaries:
- Memory Safe Methods Prevent Exploitation – NC Study demonstrating methods mitigate against exploitation of memory related CWEs and their CVEs.
- Memory Safe Methods Are Far Superior to ASLR – Unlike ASLR, RunSafe analysis demonstrates information leaks are insufficient to generate complete ROP chains that lead to successful exploits.
Let’s solve Memory Safety now – and let’s be prepared if China attempts to disrupt our critical infrastructure as part of a broader geopolitical conflict.
