Use Rust or C#, abandon C++: Five Eyes agencies warn about memory safety in programming...

[Alfonso Maruccia]

In context: Common memory safety bugs can lead to dangerous security vulnerabilities such as buffer overflows, uninitialized memory, type confusion, and use-after-free conditions. Attackers can exploit these bugs to compromise entire operating systems, steal users' data, or run malicious code on the vulnerable systems. Most importantly, these type of bugs are the most prevalent in shipping software today.

The issues with memory safety have become a serious concern for the world's most important intelligence and cyber-security agencies commonly known as the Five Eyes. A new paper jointly released by the US Cybersecurity and Infrastructure Security Agency (CISA), NSA, FBI, and other security agencies from Australia, Canada, UK, and New Zealand, is calling for a massive switch to new and effective memory safety coding standards.

These vulnerabilities represent a major problem for the software industry, CISA states, as they force manufacturers to release non-stop security updates customers will have to apply to their software. MSLs that are "safe by design" would eliminate memory safety vulnerabilities, therefore software manufacturers should move away from C, C++ and other "vulnerable" languages to quickly adopt Rust, C#, Go, Java, and other modern coding platforms.

Microsoft acknowledged that memory safety bugs account for 70% of the CVE-listed security vulnerabilities fixed in Windows since 2006, and Google provided a similar figure (67%) for zero-day vulnerabilities discovered in the Chromium project in 2021 alone.

Aptly called The Case for Memory Safe Roadmaps, the new document is intended to promote memory safety programming among C-Suite executives and technical experts. Software companies must hasten their transition to memory safety programming languages (MSLs) to eliminate memory safety flaws, CISA and Five Eyes agencies say, establishing their own memory safety roadmaps to inform customers and the public about the ongoing transition.

Memory safety vulnerabilities are the most prevalent type of disclosed software bugs, CISA says. They are a class of well-known and common coding errors that both malicious actors and adversarial intelligence agents routinely exploit.

Rust is gaining popularity among software companies, and industry giants like Microsoft, the Linux community, and Google are converting many parts of their massive codebases to the new security-focused language. CISA and the other agencies are now urging "senior executives" at every software company to reduce risks for customers, prioritizing design and development practices that will effectively implement MSLs for both new and existing codebases.

In recent years, technology leaders like Mark Russinovich have already pushed for a mass migration from C and C++ to Rust, but not everyone agrees. Bjarne Stroustrup, who created C++, said that proper programming practices can provide type and memory safety in "classic" languages, too. Stroustrup also noted that even Rust code can be written unsafely.

Permalink to story.

https://www.techspot.com/news/101102-us-cyber-defense-five-eyes-agencies-promote-transition.html

 

[Theinsanegamer]

If the Five Eyes agencies want us to move to something they call "secure"., that just guarantees they are not, in fact, secure. or likely their new tools dont work on C++ and thus they want us all to move to something newer.

 

[enemys]

If the Five Eyes agencies want us to move to something they call "secure"., that just guarantees they are not, in fact, secure. or likely their new tools dont work on C++ and thus they want us all to move to something newer.

But basically everyone wants to move from C and C++ to something safer where possible. Just because Five Eyes agrees with the rest of the industry doesn't poison the idea.

 

[user556]

I think Rust is the only one that doesn't require a virtual machine nor garbage collection, so is the only one that can have a chance of properly replacing either C or C++.

 

[i like foxes]

I love C/C++ . Pursuing the speed of code is exciting . The more challenging the code is the more thrilling it is . Improving the code is a passion like love . Pointers are power you enjoy and seek and pointers are a pleasant task to tackle .

 

[mbk34]

I love C/C++ . Pursuing the speed of code is exciting . The more challenging the code is the more thrilling it is .

The problem is that not everyone is good at achieving those results and it's often easy to make mistakes in convoluted code. It also takes longer to write such code. Inheriting someone else's "performance tuned" code is also a nightmare. I use Java for my side projects and I honestly don't think that's a solution either.

 

[gamerk2]

The problem is that not everyone is good at achieving those results and it's often easy to make mistakes in convoluted code. It also takes longer to write such code. Inheriting someone else's "performance tuned" code is also a nightmare. I use Java for my side projects and I honestly don't think that's a solution either.

Using "performance tuned" code is relatively rare; it's not like the old days where you needed to manually tune code execution because the optimizer was hot garbage.

Most of the memory-related exploits in C/C++s are due to users who aren't using modern C++ coding standards; td::shared_ptr and std::unique_ptr (and yes, std::weak_ptr) by themselves fix the majority of the memory exploits users can run into, and the vast majority of the others are fixed by not using exploitable C library functions.

Really, just avoid using C concepts in C++ programs and the vast majority of problems go away.

And the reason C/C++ aren't going anywhere is because memory safety bleeds performance. At the end of the day, C/C++ (especially the former) are about as close as you can get to raw memory operations for a high-level language, and thus will always outperform other languages. There's a reason why HW drivers are ALWAYS straight C.

The *real* problem is that would-be programmers aren't taught correctly what *not* to do; at best they get one or two C courses coming out of college, which only teach them the basics (usually mixed C/C++ without teaching the distinction between the two) and never really teach things like "memory safety", let along modern design practices.

 

[LetTheWookieWin]

Using "performance tuned" code is relatively rare; it's not like the old days where you needed to manually tune code execution because the optimizer was hot garbage.

Most of the memory-related exploits in C/C++s are due to users who aren't using modern C++ coding standards; td::shared_ptr and std::unique_ptr (and yes, std::weak_ptr) by themselves fix the majority of the memory exploits users can run into, and the vast majority of the others are fixed by not using exploitable C library functions.

Really, just avoid using C concepts in C++ programs and the vast majority of problems go away.

And the reason C/C++ aren't going anywhere is because memory safety bleeds performance. At the end of the day, C/C++ (especially the former) are about as close as you can get to raw memory operations for a high-level language, and thus will always outperform other languages. There's a reason why HW drivers are ALWAYS straight C.

The *real* problem is that would-be programmers aren't taught correctly what *not* to do; at best they get one or two C courses coming out of college, which only teach them the basics (usually mixed C/C++ without teaching the distinction between the two) and never really teach things like "memory safety", let along modern design practices.

Just to add to your excellent points, many safety-critical embedded devices continue to use C/C++ because of the need for deterministic behavior in hard real-time use cases. Having a non-deterministic garbage collector unexpectedly stealing cycles is a dealbreaker in those scenarios.

 

[gamerk2]

Just to add to your excellent points, many safety-critical embedded devices continue to use C/C++ because of the need for deterministic behavior in hard real-time use cases. Having a non-deterministic garbage collector unexpectedly stealing cycles is a dealbreaker in those scenarios.

Also true, especially on older systems and ones that are realtime (meaning the "worst case" execution times fall within some known bounds).