Don’t forget this advice from the NSA on keeping your memory safe

Best listening experience is on Chrome, Firefox or Safari. Subscribe to Federal Drive’s daily audio interviews on Apple Podcasts or PodcastOne.

Memory — that part of computers you never seem to have enough of — is a weak spot for cybersecurity. Attackers have exploited memory since, well, just about forever. Now the National Security Agency has published fresh guidance to help both software developers and users avoid memory exploits. To find out the details, the Federal Drive with Tom Temin spoke with the Technical Director of NSA’s Capabilities Directorate, Neal Ziring.

Interview transcript:

Neal Ziring
So within a computer, while a piece of software any application is running, it’s constantly reading from memory and writing to memory. For software to operate correctly, it has to be reading and writing to the right parts of memory. And an attacker may try to influence a piece of software to write out of bounds to scribble outside the proper part of the page. When that happens, you can have all sorts of bad effects, like the program crashing, or doing improper things, or even facilitating access by an attacker.

        Join us May 6 at 1 p.m. EST for Federal News Network's Industry Exchange Data where we'll explore how you can employ data to modernize your agency. | Register today!

Tom Temin
I can see where a programmer could make a mistake in giving the instructions to a program for where to write memory. And if that happens, then you know, things will stop or they’ll crash or whatever. But how can an exploiter get in when a piece of software is just running using the memory? How can that be altered at that point?

Neal Ziring
Great question. In a typical piece of software that we might be using today written in a traditional language, there’s no safeguards in how the programmer very few safeguards on how the programmer can utilize memory. So the programmer might be expecting certain behavior in a communication channel or interaction with the user. And they write their software depending on those assumptions. If someone breaks those assumptions, like an attacker, there’s no guardrails. The program will then you know right outside the bounds or read memory improperly, and have these bad effects. The report that we published the other day really talks about using technologies, particularly programming languages that help impose those guardrails that shift that mental burden off the programmer and on to the programming language to avoid those kinds of problems.

Tom Temin
In other words, you are putting a governor on the car so that someone can’t drive too fast in the first place.

Neal Ziring
That’s not a bad analogy. But I wouldn’t want to perpetuate the myth that using a memory safe language gives your software poor performance. That hasn’t been true for many years. These languages, these compilers, they’re very performant. And they can write software just as fast as any traditional language.

Tom Temin
Plus memory is so much more abundant. Nowadays, it’s much less of a constraint on programmers that used to be, correct?

Neal Ziring
It is. What I’ve found, at least in my personal experiences, the availability of lots more memory on a typical computer these days, actually, lets programmers sort of write their software in a more loose way, and maybe not even think about memory as much, which sometimes helps lead to these problems, which is kind of all the more reason to shift that burden back to the language system itself, to help out the programmer and take some of that burden off their shoulders.

Tom Temin
We’re speaking with Neal Ziring, he’s technical director of the Cybersecurity Directorate at the National Security Agency. What is the advantage to the hacker to someone that gets into a system of exploiting memory vulnerabilities? What can they get out of it?

Neal Ziring
If a software exploiter an attacker knows of a memory safety vulnerability in a program such as buffer overflow, or a use after free vulnerability, those are just technical terms, they can do many things, they can cause the software to crash, they can cause the software to do something improper in terms of a, you know, writing to the wrong part of the computer or revealing information that it’s not supposed to, or even take over operation of that software, and cause it to run code injected by the attacker. Memory safety vulnerabilities can be very powerful. And that can enable all of these different attack modalities.

        Read more: Cybersecurity

Tom Temin
Interesting here we are 75 years since the advent of memory in one form or another. Now we have terabytes on a couple of chips these days. And it still happens. Why is that? Do you think? I guess I’m asking philosophically. But if this late date in computing relatively, it’s still an open wound there.

Neal Ziring
It is. And that’s one of the reasons we published the article and why other thought leaders across the community have been writing and blogging and speaking in this vein, we have these technologies memory safe languages have existed for decades, and have matured greatly, I’d say in the last five to 10 years, to the point where there’s a wide variety of them. You know, when I was going to school decades ago, I learned languages like C that did not provide those guardrails, all of that mental burden of keeping my program memory safe was on me as the coder who had newer languages such as Go and Rust. And Java has been around for a long time C#, Python and others, you have the advantage that you can just write your code right into your memory. And if you do something wrong, the compiler is going to catch you, the runtime system is going to help you. And I had a personal experience when I was learning Rust a few years back. And at first, I was frustrated learning a new language, that it put all these rules on my behavior that I wasn’t used to. But then when I finally got my program to compile, it just worked. I mean, all that burden that the compiler had taken off of me resulted in a better piece of software sooner in the development cycle than I was used to expecting. So that was a very positive impression I got of that particular memory safe language.

Tom Temin
Now a lot of agencies, I should say programmers, but a lot of people in agencies are turning to so called low code platforms, where they attempt to draw the logic, if you will, of a system to modernize or create a new system. So low code means the program that you’re using the platform does the coding and not the user doing the coding? So there’s a low amount of coding, do we know if the output of these low code platforms are memory safe?

Neal Ziring
That’s a great question. And I’m familiar with a few of those platforms, I’m not really a deep expert in that area, the ones that I am familiar with, do exactly that. Right? You sketch out the logic that you want your software to perform. And then it generates code in one of these memory safe languages or for a runtime system that is written in one of these memory safe languages. So you get those benefits, at least in the systems I’m familiar with. When you use a low code, no code kind of platform.

Tom Temin
That would be something to ask your vendor, then by the way, the output of this is memory safe?

Neal Ziring
Yeah, that’s a great question to ask.

Tom Temin
And is there a little bit of historical irony here, because in the very early languages, say assembler later on COBOL, Fortran, memory was such a precious commodity, that that was half of what programmers worried about was sufficient memory to execute. And therefore we didn’t have these memory issues that came with the advent of C and cheap memory?

        Sign up for our daily newsletter so you never miss a beat on all things federal

Neal Ziring
Yeah, that’s an interesting way to look at it. You know, when I was learning to program as a college student, we were still somewhat in that era. And in my view, what happened was the fact that memory was scarce, encouraged language designers to build in features where you could get cute with memory, and use it in what today, we would call improper ways, you know, to try to eke out that last little bit of space in the limited memory you had. But what we found with modern language technologies, is that you can have both you can have memory safety, and you can have efficient use of memory, because our understanding of compiler technologies and optimization have all gotten better. So it’s not a matter of giving up space efficiency or memory efficiency, which still matters for small systems, small embedded systems, memory is still scarce, you can have your cake and eat it too. Here, you can have your guardrails, you can have those benefits of eliminating a bunch of these vulnerabilities and have efficiency, too.

Tom Temin
And I guess before we let you go, you should give us the general summary once again, of what the NSA advisory is telling people to do here.

Neal Ziring
So we’re really trying to encourage people to do is to leverage these memory safe language platforms and runtimes. As they move into new projects, or as they add code to existing systems, don’t just go with it older non memory safe languages, out of habit or out of inertia, make the effort to go to these new technologies because they have real benefits, right? You can eliminate depending on the type of system and the type of code and half, even over two thirds of your potential vulnerabilities. And this based on some studies done by Google and others, you can eliminate a large chunk of potential vulnerabilities just by shifting to these newer language technologies. And that’s what we’re trying to encourage folks to do. And that helps cybersecurity because now we’re going to have software systems that have a smaller exploitable attack surface for malicious actors to go after.

Tom Temin
So as agencies modernize, and that means redoing legacy applications. It’s probably worth taking the effort to rerender your logic with these new languages as a way to get better cybersecurity.

Neal Ziring
Yes, exactly.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.