While security is a legitimate concern this article leaves an impression of paid for piece to scare us into paying more money to security consultants and / or bend over to big vendors.
Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
41–50 of 100 posts
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#42Leave it to politicians to pit bull a language. Model checked C/C++ is memory safe. Had they reached out to a wider set of people for guidance, they'd have a more balanced report.
I will agree that software safety -- not just memory safety -- is critical. Trying to attack this at the language level instead of the development process and assurance level is daft. FIPS certification and aerospace certification both require auditing already. It's not much of a stretch to require an audit of critical infrastructure to verify that safety processes are in place.
Simply adopting a different language won't make software safe. It will make it safer, perhaps, but we can do better. Model checked code -- be it written in Rust, C, or C++ -- is on the same level. Tools exist for each. That is what CISA should focus on, not trying to force organizations to migrate their code bases to some new and shiny language.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#43There's go to be billions of loc of critical C/C++ software left. By 2026? Doesn't sound realistic.
The title is wrong. The guidance only says they should have roadmaps by 2026 unless the end of support date is before 2030, then they can tell customers to get bent and deal with C/C++ until support runs out. Roadmaps are easy to produce, so compliance will be easy. Follow through will be more interesting to see. And, again, the guidance is that they should have roadmaps. They aren't mandating anything.
Thanks.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#44Earlier quoted context omitted.
I think that argument had more merit back when C++ was a much simpler language. I've been programming in C++ since 1991, and the language / standard library are now so complex that it's hard to be 100% confident that I understand the meaning of any non-trivial code.
I have to massively disagree here. I'm far more confident about code written in the modern style of C++ than I am in old school C++. Modern C++ with RAII, smart pointers, constexpr, concepts, and heavy instrumentation is so much easier to reason about. It's actually close to Alexander Stepanov's idealised C++.
I can only partially agree. The new stuff often breaks in much nastier ways when it does eventually break. The worst of that old school C with objects code (and the toolchains that built it) can be dissected using simple tools and a lot of single stepping. Even when things miscompiled, you had a reasonable shot of figuring out the boundary conditions so you could avoid it in the future.
A lot of the modern stuff isn't like that. There's a thousand different rules governing ten thousand different constructs that interact in fun and dangerous ways.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#45Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#46C++ is only "memory-unsafe" if you are hiring bottom of the barrel talent. Likely the same kind of folks for which we had to change car manuals from including schematics and repair instructions to including warnings about not drinking the coolant...
> C++ is only "memory-unsafe" if you are hiring bottom of the barrel talent.
Stated differently-- a bad hiring process can never raise the risk of memory corruption when you use a memory-safe language.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#47Leave it to politicians to pit bull a language. Model checked C/C++ is memory safe. Had they reached out to a wider set of people for guidance, they'd have a more balanced report. I will agree that software safety -- not just memory safety -- is critical. Trying to attack this at the language level instead of the development process and assurance level is daft. FIPS certification and aerospace certification both requ…
I'm a little familiar with TLA+ but it can't verify the actual code you want to run, only a restatement of your intended algorithm. Are there published model checkers that can check real C++? How would they catch double-free or use-after-free or double-throw?
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#48“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.” Now that's a strong statement.…
I wonder if this is a real solution. "Memory safety" has sure been pushed hard the last few years, but this feels more like a "we need to do something, this is something, we should do this" kind of response than anything that will really address the issue. If security-through-virtualization had been the fad lately, would that have been proposed instead?
It is not a real solution. The people delivering memory-safe code today do not think their systems are secure against individual, lone attackers, let alone fully-funded state actors. The overwhelming majority of them, all software developers, and software security professionals probably think it is literally impossible to design and develop usable systems secure against such threats, i.e. can achieve the desired requirements.
Let us do this thing that literally every practitioner thinks can not achieve the requirements and maybe we will accidentally meet the requirements in spite of it is a bona-fide insane strategy. It only makes sense if those are not "requirements", just nice-to-haves; which, to be fair, is the state of software security incentives today.
If you actually want to be secure against state actors, you need to start from things that work, or at least things that people believe could, in principle, work and then work down. Historically, there were systems certified according to the TCSEC Orange Book that, ostensibly, the DoD at the time, 80s to 90s, believed were secure against state actors. A slightly more modern example would be the Common Criteria SKPP which required NSA evaluation that any certified system reached such requirements.
But if you think they overestimated the security of such systems, so there are no actual examples of working solutions, then it still makes no sense to go with things that people know certainly do not work. You still need to at least start from things that people believe could be secure against state actors otherwise you have already failed before you even started.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#49that means you have to use rust for system level programming then? there is really no other alternative at system programming as far as memory safe is concerned, that uses no GC or VM.
No, you can still use C++ for the foreseeable future for applications that require it. They are saying don’t use C++ in contexts that clearly don’t need it.
There are some important applications in US DoD where Rust is not a viable replacement for C++. You’d need to broadly disable memory-safety and the performance is still worse. C++ isn’t going anywhere for those applications because it offers material advantages over Rust. And to be frank, this kind of software rarely has memory safety issues generally; the kinds of things that lead to memory unsafety are the kinds of things that also produce poor code on unrelated metrics.
Re: Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
#50Leave it to politicians to pit bull a language. Model checked C/C++ is memory safe. Had they reached out to a wider set of people for guidance, they'd have a more balanced report. I will agree that software safety -- not just memory safety -- is critical. Trying to attack this at the language level instead of the development process and assurance level is daft. FIPS certification and aerospace certification both requ…
I'm a little familiar with TLA+ but it can't verify the actual code you want to run, only a restatement of your intended algorithm. Are there published model checkers that can check real C++? How would they catch double-free or use-after-free or double-throw?
Yep. ESBMC and PolySpace both work for C++.
I use CBMC for C.
They run an abstract machine model through an SMT solver. Among other things, this abstract machine model tracks memory usage, UAF, aliasing, etc. With custom assertions, it can also cover issues like casting safety, serialization issues, logic errors, etc. More or less, you can build up any proof obligations you need and run them through the model checker. It will provide counter-examples if it detects a failure.