The Feds Want Us To Move On From C/C++ |
Written by Mike James |
Wednesday, 13 November 2024 |
The clamour for safe programming languages seems to be growing and becoming official. We have known for a while that C and C++ are dangerous languages so why has it become such an issue now and is it even relevant any more? Since Rust stepped into the spotlight as a better way to do lowish-level programming we have been made increasingly aware of the shortcomings of C and C++. Personally, I think that the two languages have very different problems, but let's forget this for the moment as the headline problem is memory safety. Both languages are low-level and don't use a memory manager. They both also offer low-level pointers which, subject to the operating system, allow you to use memory any way you want. This is the reason they are powerful and the reason they are dangerous. It is too easy for a programmer to make a mistake that can result in an exploitable construct. Of course, if you program perfectly there should be no exploitable code, but we are all human. In principle, safe languages like Rust give you the same power but make you jump through hoops to use them. When you can't jump through the hoops and do what you want to, you have to write code that is marked unsafe and then you can do what you like. Is this the way to write safe code? The current opinion seems to be "yes it is" or at least "its better than C/C++". Now the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) have issued a guidence document on the topic of bad practices: "The development of new product lines for use in service of critical infrastructure or national critical functions (NCFs) in a memory-unsafe language (e.g., C or C++) where there are readily available alternative memory-safe languages that could be used is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety." What are we supposed to do about this: "Software manufacturers should build products in a manner that systematically prevents the introduction of memory safety vulnerabilities, such as by using a memory safe language or hardware capabilities that prevent memory safety vulnerabilities. Additionally, software manufacturers should publish a memory safety roadmap by January 1, 2026." The document doesn't mention the Rust language, but you can tell that its in the background. But what about Python or Java? Are they memory safe? They both have memory managers and don't let the average programmer get anywhere near raw memory access, but they are slow. So we really are talking about memory safe languages that can offer the same performance as C or C++. Given that programming is currently in a state of turmoil due to the way AI copilots are threatening to become AI pilots, the whole issue might be moot. At the moment, we can't trust AI to write code that is memory safe, but with some additional training and prompt engineering, I can't see why this couldn't be the case. Treating AI as a sort of safe compiler from prompts to C or C++ seems a reasonable possibility. At that point who cares how safe the target language is. After all, Rust compiles to assembler which is far from memory safe. It could well be that we are currently make a fuss about nothing. The document also highlights other security problems:
More InformationProduct Security Bad Practices Related ArticlesDARPA Wants All C Converted To Rust Rust Twice As Productive As C++ C Is Number One Language Again C Undefined Behavior - Depressing and Terrifying (Updated) To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
Comments
or email your comment to: comments@i-programmer.info <ASIN:B0D6LZZQ8R> |
Last Updated ( Wednesday, 13 November 2024 ) |