New NSA/CISA Report Again Urges the Use of Memory-Safe Programming Language (theregister.com) 38
An anonymous reader shared this report from the tech news site The Register:
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) this week published guidance urging software developers to adopt memory-safe programming languages. "The importance of memory safety cannot be overstated," the inter-agency report says...
The CISA/NSA report revisits the rationale for greater memory safety and the government's calls to adopt memory-safe languages (MSLs) while also acknowledging the reality that not every agency can change horses mid-stream. "A balanced approach acknowledges that MSLs are not a panacea and that transitioning involves significant challenges, particularly for organizations with large existing codebases or mission-critical systems," the report says. "However, several benefits, such as increased reliability, reduced attack surface, and decreased long-term costs, make a strong case for MSL adoption."
The report cites how Google by 2024 managed to reduce memory safety vulnerabilities in Android to 24 percent of the total. It goes on to provide an overview of the various benefits of adopting MSLs and discusses adoption challenges. And it urges the tech industry to promote memory safety by, for example, advertising jobs that require MSL expertise.
It also cites various government projects to accelerate the transition to MSLs, such as the Defense Advanced Research Projects Agency (DARPA) Translating All C to Rust (TRACTOR) program, which aspires to develop an automated method to translate C code to Rust. A recent effort along these lines, dubbed Omniglot, has been proposed by researchers at Princeton, UC Berkeley, and UC San Diego. It provides a safe way for unsafe libraries to communicate with Rust code through a Foreign Function Interface....
"Memory vulnerabilities pose serious risks to national security and critical infrastructure," the report concludes. "MSLs offer the most comprehensive mitigation against this pervasive and dangerous class of vulnerability."
"Adopting memory-safe languages can accelerate modern software development and enhance security by eliminating these vulnerabilities at their root," the report concludes, calling the idea "an investment in a secure software future."
"By defining memory safety roadmaps and leading the adoption of best practices, organizations can significantly improve software resilience and help ensure a safer digital landscape."
The CISA/NSA report revisits the rationale for greater memory safety and the government's calls to adopt memory-safe languages (MSLs) while also acknowledging the reality that not every agency can change horses mid-stream. "A balanced approach acknowledges that MSLs are not a panacea and that transitioning involves significant challenges, particularly for organizations with large existing codebases or mission-critical systems," the report says. "However, several benefits, such as increased reliability, reduced attack surface, and decreased long-term costs, make a strong case for MSL adoption."
The report cites how Google by 2024 managed to reduce memory safety vulnerabilities in Android to 24 percent of the total. It goes on to provide an overview of the various benefits of adopting MSLs and discusses adoption challenges. And it urges the tech industry to promote memory safety by, for example, advertising jobs that require MSL expertise.
It also cites various government projects to accelerate the transition to MSLs, such as the Defense Advanced Research Projects Agency (DARPA) Translating All C to Rust (TRACTOR) program, which aspires to develop an automated method to translate C code to Rust. A recent effort along these lines, dubbed Omniglot, has been proposed by researchers at Princeton, UC Berkeley, and UC San Diego. It provides a safe way for unsafe libraries to communicate with Rust code through a Foreign Function Interface....
"Memory vulnerabilities pose serious risks to national security and critical infrastructure," the report concludes. "MSLs offer the most comprehensive mitigation against this pervasive and dangerous class of vulnerability."
"Adopting memory-safe languages can accelerate modern software development and enhance security by eliminating these vulnerabilities at their root," the report concludes, calling the idea "an investment in a secure software future."
"By defining memory safety roadmaps and leading the adoption of best practices, organizations can significantly improve software resilience and help ensure a safer digital landscape."
How about a Linux distro (Score:2, Interesting)
Re: How about a Linux distro (Score:2)
Yes, it's totally going to work, without any unsafe code.
Re: (Score:2)
call it Rusty Linux
Or LinOxidized?
Re: (Score:2)
Re: (Score:1)
Re: How about a Linux distro (Score:3)
Re:How about a Linux distro (Score:5, Informative)
Rust code and a microkernel approach .... (Score:2)
Well there is Redox which is a Rust based OS.
And making it even better, it's also taking a microkernel based approach. :-)
Re: (Score:3)
There is the Asterinas [github.com] project: a kernel completely written in Rust and with a Linux-compatible ABI -- being able to run Linux binaries.
Unsafe Rust is limited to a small portion of the whole kernel.
Re: (Score:2)
Good luck getting a bunch of hobbyist developers to volunteer their time to re-write their own code.
Re: (Score:2)
Why not create a new kernel written in Fortran?
Now create a C to Fortran translator.
Government trolling (Score:3)
It's like they're doing this just to troll Bjarne Stroustrup, and it's working because he keeps losing his shit every single time they do. Well done!
That reminds me. (Score:2, Insightful)
How is ADA doing nowadays? (Score:3)
I think the Americans with Disabilities Act, got defunded as part of the Big Beautiful Bill.
Re: (Score:2)
Maybe thoughts and prayers will help.
Re: (Score:2)
How is ADA doing nowadays?
I was thinking about this too. True story from the early 90s in my IT career. I worked as a civilian employee of a branch of the US military. I'm not going to say which one because I actually liked and respected the members. One of my co-workers was assigned to a project that involved trying to make a piece of equipment portable. Today, it would be no problem. But 30+ years ago, it was a big ask. The project was done by a military contractor and there was a requirement to use ADA on it. My c
Exemptions from Ada mandate common (Score:2)
Fuck CISA (Score:3)
Fuck CISA and this bullshit.
Those paper-shuffling-middle-management-fucks don't have a clue.
Translating old code to... (Score:2)
...modern memory-safe languages is a great idea in theory.
In practice, it's really hard.
I believe that the problem will eventually be solved, but it will take a lot of work.
Translation is only the first step, verifying correctness under all conditions is harder, and if the old code has bugs, they should be detected and removed in the process. This is even harder.
I wish the researchers luck
Re: (Score:2)
Lets have AI do it for us!
Re: (Score:2)
Rewriting code in a new language might give better static code analysis, but, it doesn't make it safe.
I have a lot of application code I can translate to Rust, but unless I completely rearchitect all of it, it would be terrible Rust code.
I did however just revisit Rust. I wrote a simple CNC milling code generator. I explicitly told it how I want it structured. Copilot handled it nicely. I could maybe see myself vibe coding a useful tool with it. But I HATE abbreviations like pu
What do they know (Score:2)
Re: What do they know (Score:2)
Flip side (Score:3)
Just about the only way we're going to be able to take control of hardware we own and use software we want (rather than gov't/corp approved) is by exploiting security flaws left by, amongst other things, unsafe code.
Maybe urge the use of good coders instead? (Score:1)
That would accomplish someting. This will not.
Re:Maybe urge the use of good coders instead? (Score:4, Insightful)
Except there is plenty of evidence collected over a few years now that using memory safe languages does in fact improve the situation re: bugs caused by silly memory use errors. Even when you have good coders. So how about all those good coders you want also use memory safe languages? That would make things even better.
Re: (Score:2)
I think mandating stricter languages or higher skilled developers won't matter anyway. If it did, Ada would still have been the mandatory language for all (or most) government used software. Or supposed to be.
Rules will be bent at tiny corners for budget reasons, then bent a little more at the next budget meetings, and the next, and soon everything's SNAFU again.
Besides, memory safety is a good thing and I thought support for Rust by Linus showed it was on the right track. Until I read that Rust also has op
Process is no substitute for cognition (Score:1)
It is, at best, a close approximation, some of the time.
"MSLs" are no more a One Weird Trick than anything else is. And they invariably have some other downstream costs.
Java (sort of an early MSL...of sorts) solves dangling pointers and hardware specificity (sort of) but makes dealing with hardware or even non-java numerical datatypes an absolute exercise in pulling teeth.
If you never have to do either...then java (or rust or whatever) is for you. If you need interact with the outside world and software eco
Horses for courses (Score:3)
I can see the benefits of using Rust for system libraries, public APIs, and executables that run with root permission, but beyond that Rust seems like a terrible idea.
I remember seeing a talk by the IT department of a non-tech company. They were re-writing a GUI desktop app that calculates optimal settings for their product. It doesn't have an API and doesn't run as root, but they chose to use Rust because of the hype.
Now they're struggling to find competent Rust developers, and it's running way behind schedule.
How about fixing the hardware (Score:2)
Memory safe languages are NOT new (Score:3)
This from "The Register" piece:
The infamous Heartbleed flaw in the OpenSSL cryptographic library was the result of a memory safety error (an out-of-bounds read) in C code. And there are many other examples, including the mid-June Google Cloud outage, which Google's incident report attributes to a lack of proper error handling for a null pointer.
Within a few years, the tech industry began answering the call for memory-safe languages. In 2022, Microsoft executives began calling for new applications to be written in memory-safe languages like Rust.
General purpose memory safe languages have been around for a long time, for example Ada (1983) or Eiffel (1986). They just haven't been very popular, because they tend to require programmers to think harder. But software development is an industry that has a very short memory, and generally doesn't show much interest in techniques that produce better, as opposed to faster, software development. I guess it only counts if Microsoft or Google recognizes a technology as legitimate.
Onion Peelings (Score:2)
Once programmers wrote machine code and entered it with toggle switches. Then assembly code on cards. Then low level languages on terminals. Then high level languages on their PCs. Then bloated "4th gen" languages under virtual machines. See a pattern here? Just wrap the whole thing into an encrypted container, run it on your phone, and call it all good. Who needs fast code any more? /sarcasm
Memory safety and C (Score:2)
Sure, Rust is safer in this regard, but don't blame the language, blame the developers.