Solving the Memory Safety Problem, Once and for All

In a 1996 paper, “Smashing the Stack for Fun and Profit”, Aleph One laid out the shape of attacks that were well known at the time and have continued to this day. Attackers take advantage of memory unsafety issues (e.g., unchecked bounds on array access) to hijack programs. Despite decades of mitigation techniques, Microsoft and Google, among others, report that memory safety vulnerabilities are at the root of 60-70% of their security vulnerabilities.

With the rising popularity of newer programming languages, like Rust, which can make compile-time guarantees about memory safety, the natural question is whether we can automate the process of rewriting legacy codes, written mostly in C and C++. If we could do this, and do it well, we can imagine a permanent improvement in the security posture of every computer system, everywhere.

Automating this herculean task is far more than just transliterating from one programming language to another, because programs expressed in C and C++ are allowed to do things that are normally (and rightly) forbidden. A good translation must be correct, performant, and idiomatic. Each of these are substantial challenges. Correctness, for example, is remarkably plastic. We want the same behavior for “good” inputs, but the whole point is that we want different behavior for “bad” inputs. Similarly, idiomaticity (i.e., producing code that’s equivalent to what a skilled programmer would write) is fundamentally subjective, and an idiomatic translation might sacrifice some degree of equivalence for better idiomaticity (e.g., replacing ad-hoc implementations in the source program with “equivalent” code from the target’s standard library).

Can we even do code translation, at scale, as a fully automated process? Among the many real-world challenges, traditional code analysis techniques tend to hit a brick wall when program behavior is too convoluted to analyze. AI techniques tend to hit a brick wall when there’s no clear success criteria and error feedback. Furthermore, many traditional codebases don’t include comprehensive test suites or written specifications, so it’s hard to evaluate correctness. Nonetheless, DARPA’s TRACTOR (translating all C to Rust) project, and similar efforts elsewhere, are trying to tackle this problem. This talk will discuss some early results from TRACTOR, and point to challenges and opportunities for future work.

Note: Dan’s talk will also give some background on how DARPA works, including some new mechanisms that future DARPA programs may use to accelerate the contracting process when considering funding decisions.