Ensuring the security of future software: the necessity for memory safety regulations

Throughout the years, weaknesses in memory safety have played a significant role in numerous security breaches in the sector, undermining confidence in technology and incurring billions. Conventional methods, such as code inspection, fuzzing, and exploit defenses – although useful – have not proven to be sufficient in reducing the impact, leading to a progressively higher cost.

Within this blog entry, we advocate for a fundamental transformation: a unified dedication to ultimately eradicate this category of vulnerabilities, centered on secure-by-design methodologies – not solely for us but for future generations.

The transformation we urge is supported by a recent ACM piece advocating for standardizing memory safety that we contributed to in collaboration with educational institutions and industry partners. It demonstrates that the absence of memory safety is no longer an isolated technical issue but a societal one, with repercussions ranging from national security to personal confidentiality.

The possibility for standardization

In the last ten years, a convergence of secure-by-design improvements has evolved to the level of practical, widespread application. This encompasses memory-secure languages, now incorporating efficient ones like Rust, alongside safer language subgroups such as Protected Buffers for C++. 

These utilities are already demonstrating effectiveness. For instance, in Android, the growing acceptance of memory-secure languages like Kotlin and Rust in new code has led to a substantial decrease in vulnerabilities.

Looking ahead, we are also witnessing intriguing and encouraging advancements in hardware. Innovations like ARM’s Memory Tagging Extension (MTE) and the Capability Hardware Enhanced RISC Instructions (CHERI) architecture provide a supplementary defense, particularly for current code.

Despite these advancements being positive, attaining full memory protection throughout the complete software industry necessitates more than solely singular technological advancement: we should establish the appropriate setting and responsibility for their extensive acceptance. Standardizationis crucial in this case. 

For the promotion of standardization, we recommend the establishment of a common structure for defining and objectively evaluating memory safety guarantees. This will establish the groundwork for shaping a market that encourages vendors to invest in memory security. Consumers will be enabled to identify, request, and incentivize safety practices. Such a structure will equip governments and enterprises with the precision to outline memory safety prerequisites, boosting the acquisition of more reliable systems. 

The proposition we advocate would complement current endeavors by specifying precise, quantifiable conditions for attaining various levels of memory safety assurance within the sector. In this manner, policymakers will acquire the technological groundwork to devise effective policy campaigns and incentives that endorse memory security.

A roadmap for a future with memory security

We acknowledge there are multiple methods of addressing this issue, and we are personally invested in several of them. Notably, our strategy for achieving memory protection through standardization concentrates on establishing the intended results as opposed to adhering rigidly to particular technologies.

In order to transform this vision into a functioning standard, we require a structure that will:

Encourage creativity and endorse various methodologies: It is preferable for the standard to concentrate on the security characteristics we aim to attain (such as being free from spatial and temporal safety violations) rather than specifying exact implementation particulars. Thus, the framework should be impartial to technology, enabling suppliers to select the most suitable method for their products and needs. This fosters creativity and enables software and hardware producers to embrace the most effective solutions as they become available.

Customize memory safety prerequisites according to necessity: The framework should set different tiers of safety certainty, resembling SLSA levels, acknowledging that different applications come with varying security requirements and financial constraints. Likewise, distinct guidance is likely needed for crafting new systems and enhancing existing codebases. For example, verifying every single code piece formally may not be necessary. This approach allows for customized security, ensuring suitable levels of memory safety for various contexts. 

Enable objective evaluation: The framework should establish distinct criteria and possibly measures for evaluating memory safety and adherence to a particular level of confidence. The objective is to objectively compare the memory safety assurance of diverse software components or systems, similar to how energy efficiency is assessed today. This will advance us from subjective declarations towards objective and comparable security attributes among products.

Be pragmatic and implementable: In addition to the technology-agnostic framework, we require top practices for current technologies. The framework should offer advice on how to efficiently utilize specific technologies to fulfill the standards. This encompasses addressing queries such as when and to what extent unsafe code can be tolerated within larger software systems and recommendations on organizing such unsafe dependencies to facilitate compositional reasoning about safety.

Google’s dedication

At Google, our advocacy isn’t merely for standardization and a memory-safe future; we are actively endeavoring to construct it.

We are partnering with industry and academic collaborators to devise potential standards, and our collaborative crafting of the recent CACM call-to-action signifies a crucial initial step in this endeavor. Furthermore, as elucidated in our Secure by Design whitepaper and in our memory safety strategy, we are profoundly dedicated to embedding security into the core of our offerings and services.

This dedication is also evident in our internal initiatives. We are prioritizing memory-secure languages, and have already witnessed substantial reductions in vulnerabilities by embracing languages like Rust alongside prevailing usage of Java, Kotlin, and Go where performance constraints allow. We acknowledge that a full transition to those languages will require time. Hence, we are also allocating resources to enhance the safety of our existing C++ codebase proactively, such as implementing hardened libc++.

Let’s construct a future focused on memory safety together

This initiative doesn’t involve selecting champions or imposing mandates. It’s about establishing an equitable landscape, enabling well-informed decision-making, and propelling a positive sequence of security enhancement. It’s about empowering a future where:

• Developers and vendors can securely develop systems with confidence, aware that their actions can be objectively evaluated.

• Businesses can acquire memory-secure products with certainty, reducing their exposure to risk and safeguarding their clientele.

• Governments can effectively secure critical infrastructure and promote the adoption of secure-by-design principles.

• Consumers are empowered to select services and devices they use with assurance – confident in the security assessment based on a shared framework.

The path to memory safety demands a unified dedication to standardization. We must develop a future where memory safety is not secondary but a fundamental tenet, a future where the forthcoming generation inherits a digitally secure environment by design.

Acknowledgments

We extend our gratitude to the co-authors of our CACM article for their exceptional contributions: Robert N. M. Watson, John Baldwin, Tony Chen, David Chisnall, Jessica Clarke, Brooks Davis, Nathaniel Wesley Filardo, Brett Gutstein, Graeme Jenkinson, Christoph Kern, Alfredo Mazzinghi, Simon W. Moore, Peter G. Neumann, Hamed Okhravi, Peter Sewell, Laurence Tratt, Hugo Vincent, and Konrad Witaszczyk, among others.