NSA Urges Shift to Memory Safe Programming Languages

Useful thoughts also mentioned in detail in current 'Security Now'

In MalwareBytes:  NSA urges shift to Memory Safe Programming Languages

See here: statement from Defense.gov,     Technical

Below Posted: November 12, 2022 by Pieter Arntz

Neal Ziring, a Technical Director at the National Security Agency (NSA), has been dropping some truth bombs:

“Memory management issues have been exploited for decades and are still entirely too common today,”

We wholeheartedly agree. Poor memory management has been the root cause for way too many vulnerabilities, for way too long. And that's before you consider all the non-exploitable errors and crashes that could have been avoided by using memory safe languages (and other protections) when developing software.   So, if it's been true for so long, why are we writing about it now? Because the NSA has published a Cybersecurity Information Sheet that provides guidance on how to protect against software memory safety issues.  The underlying reason is that many popular programming languages, such as C and C++, provide a lot of freedom and flexibility in memory management. That sounds good, but it relies heavily on the programmers writing and maintaining the code to do the right thing and perform the needed checks on memory references.

Trusting programmers to get it right...has not been good for security.

The NSA information sheet advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, to a memory safe language where possible.

Memory issue examples

So, what are these memory issues?

If you ever read our posts describing security vulnerabilities you will see a lot of phrases like "buffer overflow", "failure to release memory", "use after free", "memory corruption", and "memory leak". These are all memory management issues.

We've reproduced a few examples below, from InitialCommit.com (you can see more on the page we've linked to.) In a real program—we hope—these errors would be harder to spot.

Not freeing memory after allocation

In the first example, the variable memory is used to store the output of the C malloc function, which allocates memory. However, the memory allocated to memory the first time it is used is never released.

If memory is continually allocated like this and never freed, an attacker might be able to use it to perform a denial-of-service attack on the software by causing it to run out of memory.  ... '   Continues,  (Technical) ... '