Care For Memory Safety Yet?

Quite recently, Prossimo, a project by the Internet Security Research Group (ISRG), informed the public that it is rewriting two core Unix-like command line tools, sudo and su, in the memory-safe programming language Rust. The short description for this initiative reads: "Let's make the utilities that mediate privileges safer." And that is but one of its initiatives. Some of the others are writing an alternative to OpenSSL and Linux kernel drivers in Rust. Also recently, Microsoft has been rewriting Windows libraries in that language. Why, essentially? Basically, the people behind these projects understand the critical severity and exploitability of memory-related security issues detected in software and are therefore pushing for a switch to writing new source code in memory-safe languages.

The change is also supported by one of the best practices mentioned in a recent publication authored by the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), the Federal Bureau of Investigation (FBI) and the cybersecurity authorities of Australia, the United Kingdom, Canada, Germany, the Netherlands and New Zealand. We're talking about their guide to develop Secure-by-Design and -Default products, which we summarized in a previous post.

Memory-safety weaknesses are very common. In a 2019 study, the Microsoft Security Response Center (MSRC) informed that around 70% of the CVEs Microsoft has addressed in over a decade have been of this kind. Similarly, in 2019, 76% of Android 10 vulnerabilities were of this kind. And that same year it was reported that 71.5% of MacOS 10.14 vulnerabilities and 66.3% of iOS 12 vulnerabilities were of this kind.

These vulnerabilities can be detected through security testing, ideally before they reach the notice of malicious threat actors. In order to detect improperly implemented or configured memory protection mechanisms, it might be necessary to perform manual penetration testing. Ethical hackers can simulate "real-world" cyberattacks, proceeding like malicious hackers would to try and make the target software behave in unexpected ways, but doing so with the permission of the organizations that own the products. Moreover, a measure to reduce the chances of having these weaknesses is considering the programming language in use.

The issues mentioned above can be prevented to a significant extent by using memory safe programming languages. They manage memory automatically (i.e., do not rely on the developers adding memory protections). Some memory-safe languages are Go, Java, JavaScript, Kotlin, Python and Rust. Whereas C, C++ and assembly are among the languages that lack memory safety. When using the latter languages, the security measures that need to be taken increase code size and negatively affect memory and performance. These measures include "additional sandboxing, sanitizers, runtime mitigations and hardware protections."

The relationship between programming language and memory-safety issues is what is motivating many to make the shift. For its part, Google has been progressively integrating new code written in memory-safe languages into the Android operating system. In fact, Android 13, released in 2022, is the first one where the majority of new code is in those languages. Remarkably, their switch from C and C++ has coincided with a reduction of memory-safety vulnerabilities. Specifically, from 2019 to 2022, memory-safety issues went from 76% to 35% of the total detected issues. Moreover, this reduction has meant fewer critical severity vulnerabilities, remotely exploitable vulnerabilities and vulnerabilities exploited in the wild, as most security issues with these traits are related to memory management. Currently, Google is one of the founders of Prossimo's initiatives and is scaling up its own use of Rust.

The development of Rust began in 2010, and its 1.0 version was released in 2015. Its adoption is growing and, as it's now plain to see, the language is used in major tech companies. Why is it so popular? At least for Google, apart from what we mentioned above, it satisfies the need to have memory safety in the lower layers of the OS, since neither Java nor Kotlin are eligible for this. And, for the community in general, it has been pointed out that Rust can reduce memory usage dramatically (an analytics startup reported a 92% decrease in their product's).

To conclude, let's mention a couple of challenges related to the switch to Rust. The first one is that the learning curve has been a discouraging factor to begin using the language. And indeed the Rust Lang Team shares that onboarding time is around three to six months. They say, however, that they "will identify and eliminate many of those patterns and idiosyncrasies [sic] that one must learn to use Rust."

The second challenge we wanted to mention is that ransomware-as-a-service gangs (e.g., Agenda, BlackCat, Hive) are now writing in Rust. Since this programming language handles memory quite efficiently, it helps ransomware remain functional. Also, ransomware may evade static analysis due to how new the language is. And as it is quite complex, it is harder to reverse engineer, which in turn makes generating decryptors more difficult.

Malicious attackers are exploiting weaknesses constantly, and that is why having a preventive and proactive security stance is key. Want us to check your software for vulnerabilities while you develop? Implement Continuous Hacking today. You can also start your free trial, which covers automated security testing.