NSA Deems C++ 'Memory Unsafe' - What's Next?
ฝัง
- เผยแพร่เมื่อ 15 ก.ย. 2024
- After NSA published a paper in which it recommends using memory-safe languages and thus excluding C++, Bjarne Stroustroup and the Direction Group have activated and changed their stance on using static analysis tools as the primary way to prevent memory safety issues in the language.
In this video Alex discusses the possible effects of the NSA paper on the language, and the solutions proposed by the Direction Group.
Relevant links:
* The New Stack article: thenewstack.io...
* The NSA paper: media.defense....
* Initial answer by Bjarne Stroustroup www.open-std.o...
* The Direction Group paper recommending changes in the C++ language: www.open-std.o...
Alex Bolboaca is a programmer, CTO, author, trainer and coach at Mozaic Works.
Mozaic Works provides high quality, customized training, coaching, and advice for companies who want to improve their effectiveness in the market, mainly through the use of modern leadership and technical practices. Check out our offer and ask us questions at mozaicworks.com.
Think. Design. Work Smart.
Yeah - your recommendation nailed the true security issue: C++ is simply too big and too complex. If you really want to use it, then you must be able to define a subset of features.
The DoD should just rewrite everything in Ada. That was the original idea. Problem solved.
That sounds interesting. Are there still Ada programmers? :)
Looking at Ada, it has all the perfect constraints for types. Would love to try it
@@tdws Yes, and there is demand for them.
There is a 5-man special group, part of ISO=C++ that is looking at how to improve the security of C++. Bjarne Stroustrup is one this.
Last week I was at the ACCU conference (UK C++) and I met one of the 5. I asked, "have you got much further in solving the security issues?"
And he said no. There is one thing they have done. ISO C++23 defines spanstream. And what was discovered is it lacked .at() member function which does bounds checking, array access.
So this will be added in ISO C++26.
I also note there has been a paper (PDF file) defining the issues and this has been through 1 revision.
Thank you for the update! We can't imagine it's an easy problem to solve, given the long history and tradition of C++, and the amount of existing code. Hopefully they will have news soon.
LOLs, there's no such thing as memory safety as the same as there's no such thing as safe system at ALL. As long it's digital, nothing you can do with 100% safety on it. It's just a matter of
strategic moves and rewriting if you want to achieve these safety/security temporarily and come back again for another rewrite. My educated guess is GG and MS is targeting Linux systems and wants to dominate server's world too. Why in the world Linux is far more secured compared to MS when it comes server's OS? At the end of the day, every system and application are converted into bits and bytes for the computer to understand the instructions given, so there's no such thing as memory safe programming language at ALL.
This is an interesting view, but that's not what memory safety means in this context. Memory safety is roughly about how many checks a programming language does on memory-related operations. A traditional issue with C++ was pointer arithmetic, which, when misused or exploited, can allow a program to arbitrary access memory. See the wikipedia article for more context on the topic: www.wikiwand.com/en/Memory_safety.
As for the safety of Linux servers, it seems to be due to efforts of engineers: specific design choices, reviews, and many hours on finding and plugging security issues. There are too many differences between OS development and application development to conflate the two, and we were mostly talking about applications.
Interesting point though that GG and MS might want to push for a switch from Linux servers, presumably to their own cloud offerings. It's hard to imagine this happening, but we'll have to wait and see.
@@tdws Thank you, I appreciate that you got some of my pointers. As for the proglang, a strict guidelines should be implemented and must be followed to minimize if not totally eliminate the problems concerning the usage of memory and other resources and no proglang is excepted on this matter. It's like continues support and product patching until the product cycle ends much like what Linux engineers have been doing eversince.
Yes that is true. I mean why not just design the machine instructions in such a way that it is impossible to write any software on that machine that would crash or have security vulnerabilities? Why is it solely the responsibility of the software?
And the answer is, such a machine would no longer be a computer. No longer a general purpose machine. It would be completely safe, but also highly restricted in what it can do.
Low-level languages cannot guarantee safety without losing the expressibillity and flexibility of the language. Safety has to be guaranteed by the way the language is used and the environment in which it is used not the language itself.
Based on what I understand about this huge topic, there seems to be a trade-off between security in programming languages, performance, and functionality. More checks require CPU cycles, and more restrictions disallow specific use cases for system languages. For example, could you write a device driver or a boot loader with all the checks in place? I assume it would be difficult, if not impossible in certain situations. However, the "secure by default" principle should be followed in general purpose programming languages, with the ability to turn off some of the checks. A simple example is immutability: it is a great way to write most programs, and it helps remove a lot of potential bugs, which is why it should be the default in programming languages. But we need to be able to turn it off occasionally, for specific parts of the code, to allow for performance improvements or even implementing features that aren't possible otherwise. Another option would be to separate languages by goals, or maybe have different profiles for system development, application development, server dev etc. What do you think?