“Memory-safe Languages”
By Scott Hamilton
Last week I wrote about what I would consider a major security flaw in a majority of web browsers on the market today. Ironically this week I came across an article about a list of programming languages that the White House Office of the National Security Director (ONCD) has declared as safe for use. The recommendation to limit programming language choice to the approved list is what I would consider a feeble attempt to “secure the building blocks of cyberspace.” This is just one component of US President Biden’s Cybersecurity plan.
So what exactly is a “Memory-safe” programming language? In the simplest of terms it is a programming language that has protection technology related to memory access. Among some of the things that make a language unsafe are dangling memory pointers and buffer overflow errors. So I realize I just defined one term, with two more terms that you probably also know nothing about.
The first, a dangling memory pointer, is like a file folder left out of the file cabinet, but it’s a little more complicated than that. In computer memory a pointer is designed to point at a particular memory location, for an example you might relate to the location of a folder in a file cabinet. Let’s say the fourth folder in the second drawer. Memory pointers are supposed to be removed once you are done accessing the folder. A dangling pointer remains pointing at that location. Let’s say you remove the second folder from that same file cabinet drawer and then read the file contents in the fourth folder. You will now be looking at the content in the fifth folder, because the pointer doesn’t move when the folders change. This is exactly the case in a dangling memory pointer.
The second, a buffer overflow, occurs when you try to fit too much information in a given memory location and it flows into the next memory location. You can think of this like a special file cabinet where each folder can only hold ten pages and the next page has to move to the next folder. You have to think about how many pages you want to place in the cabinet and put in the right number of folders first. You think you are only going to file nine pages and so you only add one file folder to the cabinet, but then you put eleven pages in the file. One page overflows into the next file folder in the cabinet. Now when someone reads the next folder they get the last page from your folder. The same thing happens when a programmer uses the wrong size of memory location to store a buffer, or chunk of information. A buffer overflow can cause values from one memory location to spill over into the next.
In both of the examples in the last two paragraphs we create a security flaw in the program, which could allow one user to access information stored by another user. This is a major flaw in the two most popular programming languages, C and C++. Both of these languages allow a programmer to utilize a memory pointer as part of a mathematical function and store the results without checking the size of the location. This can result in memory leaking to neighboring programs as well as allowing hackers to access the unconstrained memory. There are nine programming languages that are considered memory-safe, because they have automatic checks built in to avoid these two major flaws. These languages, in no particular order are Go, Rust, C#, Swit, Java, Ruby, Python, Delphi and Ada.
I argue that even when using these so-called memory-safe languages you can still have major security issues if you do not follow good programming practices. You can also have secure code in the non-memory-safe languages by following good programming practices. For example, you can monitor the size of your memory buffers in C and C++ with very minor changes to the way you write your code, preventing buffer overflow errors. You can also make sure that you release the memory pointers in your C and C++ code consistently.
The main reason the government recommends these memory-safe languages is to prevent lazy programming from creating security flaws in software. They have some pretty solid arguments in their favor considering that almost 70 percent of all security flaws were caused by these memory safety problems in 2019.
The extensive report says, “Experts have identified a few programming languages that both lack traits associated with memory safety and also have high proliferation across critical systems, such as C and C++. Choosing to use memory safe programming languages at the outset, as recommended by the Cybersecurity and Infrastructure Security Agency’s (CISA) Open-Source Software Security Roadmap is one example of developing software in a secure-by-design manner.”
However, if you are not following good software design and development practices, the language you choose to utilize will have little effect on the security of your product. Until next week, stay safe and learn something new.
Scott Hamilton is an Expert in Emerging Technologies at ATOS and can be reached with questions and comments via email to sh*******@te**********.org or through his website at https://www.techshepherd.org.
