New NSA/CISA Report Again Urges the Use of Memory-Safe Programming Language (theregister.com) 60
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: How about a Linux distro (Score:2)
Rust doesn't prevent unsafe code, it only makes you flag it.
AFAICT nothing precludes entirely unsafe rust code...
Re: (Score:2)
call it Rusty Linux
Or LinOxidized?
Re: (Score:2)
Re: How about a Linux distro (Score:2)
People didn't apparently learn anything from any of python's other failings as it is full used everywhere, why learn from that one?
Re: (Score:1)
Re: How about a Linux distro (Score:3)
Why do you hate capitalism? (Score:2)
are willing to work for significantly lower wages.
Get the pitchforks boys, we found the socialist.
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: How about a Linux distro (Score:2)
Good luck with that. Even Linux itself doesn't have a Linux-compatible ABI.
Re: (Score:3)
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.
Re: (Score:2)
A system written in rust would not be a distro - that by definition uses the Linux kernel and GNU apps, all written in C; it would be a new OS.
Take a look at Redox OS (https://www.redox-os.org/). It's a POSIX-compliant operating system written in Rust with Rust implementations of the apps. So it looks and feels like Unix, much as Linux does. Last time I looked, it was a lot slower than Linux - I'm guessing tuning for performance comes a lot lower than implementing sufficient function in the developers'
Government trolling (Score:5, Funny)
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)
When that actually happens, and I think it will. I'll buy my Mom some spray paint to graffiti any places that don't have handicap accessible ramps or bathrooms.
Maybe vandalism isn't very nice, but if changing the deal on the ADA is allowed then why not renegotiate everything else?
I say, toss the social contract out the window if it doesn't work for you anymore.
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:1)
Re: (Score:2)
Re: (Score:2)
Interesting. Back in the early 1990's I worked for a British company building military equipment. One project I worked on was a hand held communication device, connected to Clansman pack pack radios, to provide encrypted messaging. It was all done in ADA.
Fuck CISA (Score:2, Informative)
Fuck CISA and this bullshit.
Those paper-shuffling-middle-management-fucks don't have a clue.
Re: (Score:1)
I wondered how long before some clueless trump-inspired sycophant would come here and start spouting nonsense. If you want to see clueless in action just look at all the former Fox hosts playing agency directors.
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:3)
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
Re: (Score:2)
Well,
modern C/C++ is full with int8 - int64 or the uint equivalents.
Sometimes I write a typedef. Then my finger is lingering over the return key when I have finished typing "make" ... assuming the computer will explode when the compiler runs over the typedef. Once I woke up at night, from a nightmare assuming typedef got removed from the language(s) ...
So I ran to my computer and check again: it is still there!!
So when I see this ...
std::vector<std::string> args;
I think, o
What do they know (Score:3)
Re: What do they know (Score:2)
Re: (Score:2)
What do they know with their well-reasoned conclusions based on years of research people who have formed identities around being memory management wizards that have huge egos and refuse to believe that human fallibility is a real factor in large complex systems rather than a matter of personal accountability deeply feel otherwise.
It would be foolish for anyone who designs a large complex system to not factor in "human fallibility".
The issue of "human fallibility" however is infinitely expansive. It doesn't necessarily follow language selection must be dominated by a single consideration such as "memory safety".
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:2, Insightful)
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:1, Troll)
Nope, there is not. There are fake claims to that effect, but they are only claims. They have no scientifically sound basis and they are generally easily identifiable as misinterpretation of the data.
People that make "silly memopry use errors" are incompetent. They remain incompetent when using other languages. Of how do you think all those PHP or JavaScript security problems come into being?
Re: (Score:2)
Ah, yes, speak truth, get modded troll. No idea how some fuckups get mod-points time and again.
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
Re: (Score:2)
Ada is a niche language.
And most people never used it, so even the kind of admirers mistake it for a silver bullet, e.g. Ada lacks:
- garbage collections (you need more modern add on's/variations of it)
- object oriented programming got added in Ada95
It's strengths were/is multitasking and precise description of data structures and in that context "bit fiddling".
Of course encapsulation with its package system etc.
It is a "verbose" language. With modern IDEs that should not be a problem, though.
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.
Re: (Score:2)
A random office grunt wanting to crunch some numbers that's a bit more than Excel can handle, isn't going to want to learn a complicated programming language. Let alone the intricacies and pitfalls to avoid. They just want the numbers to get processed so they can move on to their next task for the day. As such, the code they wind up writing tends to be poor quality. Just barely getting the job done. Rust's memory management take
Re: (Score:1)
Re: (Score:2)
Running as root or not is nothing to do with anything here.
Of course choosing a language you and your team(s) are not prepared to learn is the problem here. If you have no team and can't find people to use the language you want you are on to a loser no matter what language.
None of that makes Rust a terrible idea as a language.
Re: (Score:2)
It would not be any difference if they had used C.
On the other hand if they picked Rust "because of hype", they probably had neglected other languages "because of hate" (or some idiotic flame).
For me personally writing a GUI app - regardless of OS - the first choice would be Java and - yes - Swing. .Netish language and the modern portable .Net GUI framework. Qt I know a little bit, the .Net GUI FW I don't know ...
Second choice would have been to be determined between Qt/C++ and some
How about fixing the hardware (Score:3)
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.
Re: (Score:2)
General purpose memory safe languages have been around for a long time, for example Ada (1983) or Eiffel (1986).
C can be one of them with a good compiler and standard library. There's even versions of C that forbid dynamic memory management outright. So there's very little chance, if any, of a memory error. To say nothing of syntax checkers, leak catchers, etc....
They just haven't been very popular, because they tend to require programmers to think harder
It's not the thinking that's the problem. (Most career programmers tend to like thinking through difficult problems.) The issue has always been the cost to management. Management doesn't want to pay the programmer for the extra time required to solve those
Re: (Score:2)
No, C cannot be a memory safe language with any compiler or standard libraries. It can only do so by doing (or not doing) something that the C standard specifies. That is to say it is no longer C.
Onion Peelings (Score:3)
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.
Re: (Score:2)
I don't blame the developers. Developers are only human (I hope still) and humans make mistakes. Competent developers are aware of their fallibility and take steps to detect and correct errors. Often lengthy, manual, tedious steps: reviewing, testing , debugging etc, etc. A memory safe language is a great way to automate away a big junk of that at compile time. What is not to like about such a win, win situation?
As of those non-human developers. I feel much better about AI generated code in Rust than say C
Re: (Score:2)
So, one makes a mistake, and you want to blame him?
A pretty low human attitude in my opinion.
You have two different languages and two different compilers, why not pick the one which makes it impossible to make certain kinds of mistakes and pretty hard to make other mistakes?
Then ... only then: it is still the developers fault. But still no reason to blame him.
Brought to you by GAGME (Score:2)
Stop Blaming the Tool! (Score:2)