Security

What Is Memory Safety, and What Does It Mean for Federal Agencies?

The Cybersecurity and Infrastructure Security Agency recently issued guidance on how to transition to memory-safe programming languages to reduce software vulnerabilities.

Phil Goldstein

Twitter

Phil Goldstein is a former web editor of the CDW family of tech magazines and a veteran technology journalist. He lives in Washington, D.C., with his wife and their animals: a dog named Brenna, and two cats, Grady and Princess.

Federal agencies face a wide range of cybersecurity threats, including ransomware, insider attacks and phishing attacks. Some of these threats come from relatively new vectors such as Internet of Things devices. Others are much older and elemental, including memory safety.

As far back as 1996, when Phrack magazine published an article by the hacker Aleph One titled “Smashing The Stack For Fun And Profit,” the world has known about memory safety vulnerabilities and how malicious actors can exploit them.

Now, the the Cybersecurity and Infrastructure Security Agency and cybersecurity authorities in Australia, Canada, New Zealand and the United Kingdom — issued guidance on how to mitigate the threat from memory safety vulnerabilities.

As part of its Secure by Design initiative, CISA has started to look at not just individual vulnerabilities but also entire classes of them — coding errors that happen over and over.“We want to ask if there’s something that we can do about those repeat offenders,” says Bob Lord, a senior technical advisor at CISA. “It turns out that memory safety is one of those classes of coding errors that turns out to be a relatively large problem.”

Click the banner to get the expertise you need to strengthen your ransomware protection.

What Is Memory Safety?

Memory safety vulnerabilities are the most prevalent type of disclosed software vulnerability according to CISA, and they affect “how memory can be accessed, written, allocated, or deallocated in unintended ways in programming languages,” the guidance notes.

“Depending on the type of vulnerability, a malicious actor may be able to illicitly access data, corrupt data, or run arbitrary malicious code,” CISA’s guidance says. “For example, a malicious actor may send a carefully crafted payload to an application that corrupts the application’s memory, then causing it to run malware.”

According to Chris Rohlf, a nonresident research fellow at Georgetown University’s Center for Security and Emerging Technology, a program is said to be memory-safe “when it accesses memory only in intended ways that cannot result in security vulnerabilities or other errors.”

Essentially, memory safety protects computers from errors in memory management or the process of allocating and freeing portions of computer memory, says Mark Stockley, cybersecurity evangelist at Malwarebytes.

“In older programming languages, like C, memory safety is the responsibility of the computer programmer using the language,” he says. “This affords programmers a lot of control and flexibility when writing computer programs, but it also comes with significant risks.”As CISA notes, based on analysis by Google’s Project Zero team, 67 percent of zero-day vulnerabilities in 2021 were memory safety vulnerabilities.

Imagine this like a car safety system, where the car can never drift into an adjacent lane by accident.”

David Weston Vice President of Enterprise and OS Security, Microsoft

What Are Memory-Safe Programming Languages?

There are many mitigation measures that agencies and other organizations can take to minimize harm from these kinds of vulnerabilities, CISA notes in the guidance. That includes efforts to reduce the prevalence of vulnerabilities, such as developer training, secure coding guidelines and the use of safer language subsets.

“Memory-safe programming languages are those that provide guarantees on memory access and generally don’t provide a developer with the ability to write code that can result in invalid memory access,” Rohlf says.

Such languages, Stockley notes, “handle memory management automatically instead of letting computer programmers do it, eliminating the root cause of some extremely common security vulnerabilities.” Examples include C#, Go, Java, Python, Rust and Swift.

For instance, with Rust, “memory is guaranteed to never overflow boundaries, which is the core cause of many memory safety issues,” says David Weston, vice president of enterprise and OS security at Microsoft. “Imagine this like a car safety system, where the car can never drift into an adjacent lane by accident.”

The CISA guidance notes that memory-unsafe programming languages are prevalent and run operating systems, resource-constrained systems and applications that require high performance.

DISCOVER: CMMC 2.0 streamlines security requirements for DOD contractors.

Lord says CISA acknowledges that shifting to memory-safe languages, or MSLs, will involve “significant investments and executive attention” and years of careful planning. The guidance recommends that software vendors create and publish memory-safe roadmaps that detail how they will eliminate memory safety vulnerabilities in their products.

Using MSLs will create more reliable code than memory-unsafe languages, lead to fewer interruptions for developers, and increase security for agencies and other software customers, CISA says.

Lord says CISA knows that software manufacturers will not rewrite all their code overnight, but following these recommendations can help get them started. “We suspect that they’re going to find places that are high-value targets for an attacker and focus their initial energies in those areas,” he says.

Why Agencies Should Adopt Memory-Safe Programming

The CISA guidance recommends that software makers consider “how to prioritize migration to MSLs through the development of roadmaps and specific guidance for development and technical teams.” It says that software vendors should pick use-case-appropriate MSLs, noting that “each one has its own set of tradeoffs in terms of architecture, tooling, performance, popularity, cost, and other factors.” Vendors should also consider how they will train and hire developers to work with selected MSLs.

Rohlf notes that CISA’s guidance proposes a multiphase approach that should include processes and techniques for reducing the prevalence of memory safety vulnerabilities in existing code, adopting mitigation technologies found in compilers and modern CPUs, and then developing a plan to adopt and transition to memory-safe languages.

Lord says that both sellers and buyers of software, such as agencies, need to hear this advice.

“We want to encourage folks to have that conversation with their software suppliers and talk about where they are in their journey,” he says.

MSLs provide “deterministic safety against current and future security issues, removing the need to play whack-a-mole with vulnerabilities,” Weston says.

The number of security vulnerabilities reported each year due to memory safety issues is “quite high,” Rohlf says, and “remediating and patching those vulnerabilities is expensive for these organizations.”

“If we can reduce the volume of memory safety security vulnerabilities, we will not just improve security but also lower costs for these organizations and allow their security staff to focus on other areas,” he adds.

Shockley agrees, saying that moving to MSLs will make securing software easier for software makers and their customers.

“The vast number of memory management vulnerabilities discovered each year gives criminals a huge attack surface to target. It forces software vendors to issue a constant output of software updates, and it ties up IT and security staff in a complex and time-consuming merry-go-round of patching,” he says. “Many organizations end up being attacked simply because they cannot keep up with the patching that could have prevented the attack.”

islander11 / Getty Images