Android and memory-safe languages

Updated on 2022-12-22: Memory safety

The US Congress will require the National Cyber Director to study the use of memory safety languages in the federal government, according to a provision included in the Financial Services and General Government Appropriations Act 2023 [PDF, page 19].

Updated on 2022-12-01: Android and safe languages

Google says that Android 13, the latest version of the Android mobile operating system that was released in August this year, is the first Android release where a majority of new code added to the project was written in a memory-safe language, such as Rust, Java, and Kotlin. The OS maker noted that since shifting its focus on using memory-safe languages, the number of memory safety vulnerabilities reported in the Android OS has gone down by more than half. Read more: Memory Safe Languages in Android 13

Updated on 2022-11-14: NSA Urges Use of Memory-Safe Software Languages

The US National Security Agency has published guidance on software memory safety. Noting that “exploitable software vulnerabilities are … frequently based on memory issues,” NSA urges developers to use “memory safe software languages,” such as C#, Go, Java®, Ruby™, Rust®, and Swift®. NSA recommends the use of static and dynamic supplication security testing to harden languages that are not as safe.

Note

• NSA’s report points out “Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks.” This highlights the importance of requiring static and dynamic testing of all procured or custom-built software. A historical note: in 1978 I graduated from college and went to work at NSA. The first edition I read of the internal NSA newsletter Cryptolog had an article on buffer overflow vulnerabilities – in mainframe operating systems. Software has a long history of being soft.
• Memory management is key on multiple levels. I remember writing code that consumed memory as well as other programs which neglected to fully release it when done. Irrespective of your development environment, make sure that you’re running static and dynamic code analysis to make sure you didn’t overlook it.
• Don’t get me wrong; I am critical of our tools and believe that our choice of those tools contributes to the poor quality of our results. However, our choice of tools is rooted in our culture and that is where the real problem lies. The culture prefers cheap, early, general, flexible, and feature rich; it is tolerant of shoddy. Collectively and pervasively, we will not choose safer tools, much less produce quality results, until we change our culture to one that puts quality first. (Incidentally, if one controls for quality ahead of cost and schedule, cost and schedule will take care of themselves. The reason that we do not make cost and schedule is, not because we do not produce enough code per unit of cost and time but because when we finally get around to testing (for quality) the damn thing doesn’t work. Test early, test often, test late, test.)

Read more in

• NSA Releases Guidance on How to Protect Against Software Memory Safety Issues
• National Security Agency | Cybersecurity Information Sheet: Software Memory Safety (PDF)
• NSA urges orgs to use memory-safe programming languages
• NSA Publishes Guidance on Mitigating Software Memory Safety Issues
• NSA to developers: Think about switching from C and C++ to a memory safe programming language

Updated on 2022-11-13

The NSA issued a guidance to help organizations implement proper protections against common software memory safety issues. The agency suggests using memory-safe language. Read more: NSA Publishes Guidance on Mitigating Software Memory Safety Issues

Overview: NSA recommends memory-safe languages

The US National Security Agency issued guidance on Friday, recommending that developers and organizations look into using memory-safe languages when coding new applications as a way to avoid common “poor memory management issues” that could allow threat actors to exploit their software and abuse or steal user data. Examples of memory-safe languages listed in the guidance document include C#, Go, Java, Ruby, Rust, and Swift. Several major tech companies, like Microsoft, Google, and Mozilla, have long promoted the use of Rust as a C and C++ alternative. NVIDIA is also a known case where the company ditched C and C++ for a memory-safe language named SPARK. Read more:

• NSA Releases Guidance on How to Protect Against Software Memory Safety Issues
• NVIDIA Security Team: “What if we just stopped using C?”