Memory Safe Languages: Does Just Bossing around Developers Work (From a Security Perspective?)

There are a few people on the internet whose publications I read everything. lcamtuf is one of them. Here, in a post, he talks about the recent focus on memory-safe languages, and the idea of rewriting innumerable lines of code to make the resulting programs memory-safe.

...after all these years fighting for memory safety, I’m disagreeing with the proposal to end it once and for all. For one, I think that security professionals are too keen to collect paychecks for bossing people around and having others do all the hard work. This proposal — demanding that developers re-learn their craft — certainly fits that mold. - https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-safety

This sentence is worth repeating:

"I think that security professionals are too keen to collect paychecks for bossing people around and having others do all the hard work."

I'm as bad in this area as anyone in that I love the idea of removing all memory safety issues from code--it certainly sounds like a great thing to do. But to, you know, just rewrite everything in memory-safe languages--someone has to do all the work. Guess who? Developers, that's who. So there are a couple of problems here, 1) we can't rewrite all the code and 2) the work goes onto developers shoulders.

Back to the Building Blocks

The catalyst to lcamtuf's post is the recently released "Back to the Building Blocks: A Path Toward Secure and Measurable Software."

https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf

This Whitehouse report discusses the fact that if we could write software in memory safe programs, we could eliminate a whole class of common vulnerabilities. This is because many of the existing "building blocks" are programming languages that are "memory unsafe".

...even if every known vulnerability were to be fixed, the prevalence of undiscovered
vulnerabilities across the software ecosystem would still present additional risk. A proactive approach that focuses on eliminating entire classes of vulnerabilities reduces the potential attack surface and results in more reliable code, less downtime, and more predictable systems. Ultimately, this approach enables the United States to foster economic growth, accelerate technical innovation, and protect national security. Leaving these risks unmitigated comes with a costly price tag and may allow America’s adversaries to attempt to take advantage of the circumstances. - Back to the Building Blocks

This report is in-line with many recent US government pronouncements around memory safety. Below is another example post.

For over half a century, software engineers have known malicious actors could exploit a class of software defect called “memory safety vulnerabilities” to compromise applications and systems. During that time, experts have repeatedly warned of the problems associated with memory safety vulnerabilities. Memory unsafe code even led to a major internet outage in 1988. Just how big a problem is memory unsafety? In a blog post, Microsoft reported that “~70% of the vulnerabilities Microsoft assigns a CVE [Common Vulnerability and Exposure] each year continue to be memory safety issues.” Google likewise reported that “the Chromium project finds that around 70% of our serious security bugs are memory safety problems.” Mozilla reports that in an analysis of security vulnerabilities, that “of the 34 critical/high bugs, 32 were memory-related.” - https://www.cisa.gov/news-events/news/urgent-need-memory-safety-software-products

What are programs made of? Code of course. 😄

Since many cybersecurity issues start with a line of code, one of the most effective ways to address those issues is by examining the programming language itself. Ensuring that a programming language includes certain properties, such as memory or type safety, means software built upon that foundation automatically inherits the security those features provide. - Back to the Building Blocks

But...who writes the code? Developers.

Shift Left

One criticism I have of the "shift left" movement is not in the original concept itself, rather that what usually happens is that we simply shift more of the work to developers. In my experience, what we seem to be "shifting left" is work, not information or some kind of helpfulness. Yes, building security into programs at an early stage is something we have been working on for decades, and the idea of shift-left is a good one, if not a great one, but it seems that in many, if not most, cases we are simply placing more work on developers, and it some cases its piling up.

We need to keep moving to the left, but the exact way we do it could be improved, and we should find ways to reduce the burden on developers. Perhaps simply requiring the use of memory-safe languages is one way to do this, but lcamtuf suggests that this would require many developers to completely "re-learn their craft".

Memory Safety OS Features

Despite how it can feel sometimes, computer security has come a long way. One area that we often "forget to remember" is the amazing memory security features we have built into our operating systems over the last few decades.

...thanks to the decades of work on low-overhead exploit mitigations — notably including address space randomization and branch tracking — successful exploitation of memory safety issues has gotten quite challenging and accounts only for a tiny sliver of the overall volume of security incidents. Although memory corruption bugs are favored by some government actors, virtually all large-scale breaches trace back to other issues: outdated or misconfigured software, phishing, and so on. - https://lcamtuf.substack.com/p/a-reactionary-take-on-memory-safety

Some example memory protection features that have been added over the years, a non-exhaustive list:

• NX Bit & DEP (Data Execution Prevention) - A security feature that marks memory pages as either executable or non-executable. It helps prevent buffer overflow and other types of attacks by preventing code execution in certain memory regions reserved for data.
• PIE (Position Independent Executables) - An executable binary format designed to be loaded at any memory address, making it harder for attackers to predict the location of code in memory and exploit vulnerabilities.
• ASLR (Address Space Layout Randomization) - A security technique that randomizes the memory addresses of executable code and data in a process's address space. This makes it more difficult for attackers to predict the location of specific functions or data and exploit memory-related vulnerabilities.
• KASLR (Kernel Address Space Layout Randomization) - A variation of ASLR applied to the kernel space, where the memory layout of the kernel is randomized at boot time. It aims to increase the difficulty of code reuse attacks by making it harder for attackers to find and exploit kernel memory vulnerabilities.
• Control Flow Integrity (CFI) - CFI verifies that the control flow of a program follows a predefined set of rules, making it difficult for attackers to hijack the program's control flow.

There has certainly been work done in this area to make it harder to attack memory.

Rust

Likely much of this recent discourse has been prompted by the invention and recent popularity growth of the Rust programming language. (Aside: One thing I love about computers is the number of programming languages available. Think of the diversity in programming. We don't have that kind of diversity elsewhere in computers. I suppose it may be a function of our use of general purpose CPUs.)

Most programming languages are considered memory-safe—except for C, C++, and assembly. “Until the last few years, almost all systems software was written in C or C++, which are notoriously not memory-safe,” says Dan Grossman, a professor and vice director of the Paul G. Allen School of Computer Science & Engineering at the University of Washington. - https://spectrum.ieee.org/memory-safe-programming-languages

With Rust, we have a language that we can use to replace C and similar languages, which are typically used in deep in the guts of operations systems, in a practical way.

You will actually have Windows booting with Rust in the kernel in probably the next several weeks or months, which is really cool," he said. "The basic goal here was to convert some of these internal C++ data types into their Rust equivalents." Microsoft showed interest in Rust several years ago as a way to catch and squash memory safety bugs before the code lands in the hands of users; these kinds of bugs were at the heart of about 70 percent of the CVE-listed security vulnerabilities patched by the Windows maker in its own products since 2006. - https://www.theregister.com/2023/04/27/microsoft_windows_rust/

As we continue to explore computing in general as a species, we are sure to see many more Rust programs, especially those that are core components of operating systems.

A Real Jar of Pickles

This is a real dilemma. We're in a bit of a pickle, so to speak. We need more computer security. We know that, and the US government knows it too, and is now putting a more emphasis on it, here specifically taking the point how we should use memory safe languages. And yet, I think we can read into what lcamtuf is saying, in that simply dumping this responsibility on a single class of IT worker, i.e. developers, probably won't achieve the desired level of success.

On the one hand, we'll see more adoption of memory-safe languages, simply because we have more of them now, but on the other, it's not fair to expect all our old code, the trillions of lines of it, to be rewritten by a single group of people. Maybe that's not the aim of the "Back to the Building Blocks" paper, I'm not sure. But I can't help thinking about what lcamtuf said about bossing devs around, and what that means from a practical perspective. Who else can help here, and how? Should we just have more developers, or is there anyone that can be some kind of force-multiplier? There's no easy answer.

Thanks for reading and have a great week!