Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

https://thenewstack.io/feds-critical-software-must-drop-c-c-by-2026-or-face-risk/

by afdbcreid • 2 years ago

50 97 2 years ago

thenewstack.io

gnabgib• 2 years ago

CISA guidance: https://news.ycombinator.com/item?id=41863640

lisper• 2 years ago

Just wait five days and this will all go away.

UltraSane2• 2 years ago

Nope, the US government seems to be deadly serious about this, and with good reason. Software security is a absolutely a critical national security issue at this point.

mu53• 2 years ago

You can't just hand wave the entirety of the C/C++ ecosystem away.

There is no second option for many applications or hardware

overstay8930• 2 years ago

Both admins want this to happen, one will just grant more exemptions than the other.

Jtsummers2• 2 years ago

DOD mandated that all systems be written in Ada, that lasted about 5 minutes. DOD also fails to properly fund programs and properly manage them so there are critical systems literally still depending on DOS.

gigel822• 2 years ago

C++ 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...

sunshowers4• 2 years ago

Can we please be responsible professionals and move past this. This was settled many years ago.

bagels• 2 years ago

You must have had incredible luck to never have made a mistake, even ones you didn't realize you made.

CoastalCoder2• 2 years ago

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.

CuriousCosmic• 2 years ago

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++.

johnnyanmac• 2 years ago

Even if I took your word for it: are you surprised a government would hire as cheaply as possible?

andrewflnr• 2 years ago

Having worked in government: Well, yes. Defense contractors aren't cheap, and they could probably hire cheaper talent if they were motivated/willing to clear away some red tape. That said, not everyone at a defense contractor is exactly top talent.

jancsika• 2 years ago

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.

gigel822• 2 years ago

Hate that all you want, but you know it's true if you've been in the industry for more than a couple of years.

It's a mistake to cater to the lowest common denominator. We'll all be coding in Scratch in a decade if we keep down this path.

Animats4• 2 years ago

“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.

But it's real. There are so many state actors doing cyberattacks now that everything needs to be much tougher. Otherwise, someday soon much of the world stops working.

UltraSane2• 2 years ago

I shudder to think just how badly the US, Russia, and China have hacked each other by this point.

generalizations• 2 years ago

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?

Veserv3• 2 years ago

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.

EasyMark3• 2 years ago

While these types of failures are the 50-70% problem, 30% left seems like a big problem too and the black-hats will just concentrate more on those if the low hanging fruit are removed with rust, C#, python, whatever

cryptonector7• 2 years ago

It's a 90% solution, not a 100% solution. We don't have a 100% solution, not at any affordable cost.

jandrewrogers2• 2 years ago

I think it is important to recognize that this will only apply to generic normal software, which is already mostly written in memory-safe languages for government e.g. Java. Data infrastructure with state-of-the-art scale, performance, and workload requirements will continue to be written in C++ for the foreseeable future, largely because there is no alternative. Maybe Zig some day?

A pattern I’ve seen (and used myself) is that the heavy core engines are written in C++ for performance and maintainability but skinned with a Rust API wrapper. Rust is closer to a “better Java” than a C++ replacement for extreme systems software.

jrpelkonen• 2 years ago

Calling Rust a "better Java" and not a credible alternative for C++ for "extreme systems software" without further detail is an opinion that I find hard to take seriously. So I'd like to understand your viewpoint better. Could you elaborate on what aspects in C++ specifically make it so much better suited for these tasks from performance and maintainability perspective?

SleepyMyroslav• 2 years ago

everything needs to be much tougher

I think you are being charitable to it. Less charitable version can be "Nobody ever will get fired for buying IBM". :)

3eb7988a1663• 2 years ago

Surely there is going to be an enormous list of exemptions submitted and approved immediately.

My quick skim did not make this clear: is this for software only or would hardware appliances also count? Routers, modems, PLCs used in gas centrifuges, etc. are just as attractive for exploitation.

adgjlsfhk1• 2 years ago

I think the really big difference with software is that software is much more likely to be used in unexpected ways where vulnerabilities that weren't important at time of original design end up exposed on the internet for exploitation by everyone.

danparsonson• 2 years ago

Why does that not apply to router firmware for example? The primary role of a domestic router is to be exposed to the internet.

jerlam• 2 years ago

On the other end of the "hardware appliance" spectrum, there is the F-35 Joint Strike Fighter whose software is written mostly in C and C++, heavily networked, and will be part of any future "loyal wingman" drone program. Each plane costs over 80 million US dollars.

synergy202• 2 years ago

that 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.

sys64739• 2 years ago

That sounds great. I love Rust.

omeid2• 2 years ago

There is a few options, for example Ocaml, Swift, Erlang, and so on.

http://ocamlverse.net/content/systems_programming.html

https://www.swift.org/blog/embedded-swift-examples/

https://www.erlang.org/doc/system/embedded.html

candiddevmike• 2 years ago

GC or VM may be perfectly fine for system level programming. Microsoft's project singularity had everything including the kernel using GC iirc

tdeck• 2 years ago

Perhaps Ada?

synergy202• 2 years ago

also MISRA c and c++

hgs3• 2 years ago

You can have a systems programming language with garbage collection. Most concerns regarding GC are around unpredictable pauses, but you can absolutely design a predictable GC suitable for real-time applications.

Rust is not the only option. The Ada programming language was developed in the early 1980s, primarily for the U.S. Department of Defense (DoD). Ada was designed for safety-critical embedded systems and real-time applications, especially in areas like avionics and military systems. In 1991 the DoD mandated Ada, but then reversed the decision in 1997. As I read the linked article and the governments "strong stance" I'm wondering if history will repeat itself.

anonymousiam• 2 years ago

I was going to post that the same sort of mandate had applied to Ada, and was eventually abandoned. I remember Ada the mandate, but I recall obtaining waivers from the mandate (on specific DoD programs) before 1991. I predict that this mandate will suffer the same fate as the previous one.

A quick search confirms my memory:

The DoD Ada language mandate, which required the use of the Ada programming language for most Department of Defense software projects, was established on March 30, 1987 through Department of Defense Directive 3405.2.

https://dl.acm.org/doi/10.1145/255471.255599

jandrewrogers2• 2 years ago

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.

akira2501• 2 years ago

I mean.. the last three critical nation wide software failures had nothing to do with memory safety.. but okay. Shouldn't we base recommendations on actual experience?

All the memory safety in the world can't save you from a dumb vendor just screwing millions of computers at once.

sidewndr46• 2 years ago

How would any software be FIPS compliant? Is there a "memory-safe" implementation of TLS that is also FIPS certified?

est31• 2 years ago

rustls together with aws-lc-rs (and its FIPS mode) can do FIPS-compatible cryptography together with memory-safe TLS processing around it. The FIPS-compatible cryptography is provided in C, but low-level crypto routines is usually not where memory safety issues hide.

https://www.memorysafety.org/blog/rustls-with-aws-crypto-bac...

Veserv3• 2 years ago

Cool. Is this going to require phasing out systems written in C/C++ with horrible security track records like Linux and Windows? Or are they going to get a "too critical to be improved" exemption?

Sevii• 2 years ago

Do you have an OS written in a memory safe language with a good security track record we can switch to? If we start building now we might have a prototype by 2030.

Veserv3• 2 years ago

There are plenty with good security track records, formal specifications, formal proofs of various security properties, and decades of deployments.

SCOMP, GEMSOS, INTEGRITY-178, seL4.

multimoon• 2 years ago

This is the most HN comment I’ve seen in recent memory.

cryptonector7• 2 years ago

There's go to be billions of loc of critical C/C++ software left. By 2026? Doesn't sound realistic.

Jtsummers2• 2 years ago

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.

cryptonector7• 2 years ago

Thanks.

tetnis3• 2 years ago

CISA is stupid. Logic bugs don't go away with Rust.

tetnis3• 2 years ago

People can downvote all they want. But CISA needs a talking point, and "Rust solves it" is one they won't ever let go. Go talk to those freaks and remember I told you so.

sunshowers4• 2 years ago

I regularly solve logic bugs using affine typing and shared xor mutability, so clearly some subset of logic bugs is solved with Rust, no?

exabrial• 2 years ago

So... F35?

pizlonator• 2 years ago

This misses the point. C/C++ are unsafe because that’s how implementations happen to work today.

C/C++ can be memory safe. Fil-C/C++ is a good example. It’s not a new language, just a different way of implementing it.

Here’s more info about Fil-C: https://github.com/pizlonator/llvm-project-deluge/blob/delug...

caseysoftware• 2 years ago

"Companies have until January 1, 2026, to create memory safety roadmaps."

This doesn't bode well for open source software not backed by a "company" that can write these roadmaps and deliver on them.

aka Sounds like Microsoft, Oracle, and other's lobbying has been effective.

FpUser• 2 years ago

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.

nanolith9• 2 years ago

Leave 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.

erik_seaberg3• 2 years ago

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?

nanolith9• 2 years ago

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.

timClicks• 2 years ago

That's the intent of the document - to reach people for guidance. The document under discussion is requesting comment from industry.

nanolith9• 2 years ago

Yep. I'm writing up a response letter based on my own work with model checked C. It's not the language but the process and the tooling that matters. It is definitely true that the industry has been quite lax with memory safety, but the solution isn't to rewrite everything in yet another language. The solution is to tighten development processes and put forward a plan to make existing code safer.

aithrowawaycomm2• 2 years ago

This seems somewhat incoherent and is too focused on shallow claims about languages instead of trying to understand why the memory bugs happened in the first place.

Are unsafe code blocks in Rust or C# okay? Presumably yes if there are good reasons to do so, sometimes it is necessary. But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are substantive differences from a developer's perspective. But just as a stressed or cynical C++ developer might give up on solving the Valgrind error, a similar Rust developer might give up fighting the borrow checker and add "unsafe" to their buggy code. A federal impetus to switch from C++ to Rust would seem to incentivize this laziness further.

To be clear this isn't a criticism of Rust's design or implementation - demarcated blocks of unsafe code is pragmatic and sensible. The problem is how humans build software. In this sense I don't think we've really settled whether "rewrite the code in Rust" is actually safer than "redo our technical management to include automated memcheck testing and paired code reviews." At the very least, I don't think the latter is insufficient, and the feds are being too heavy-handed by making this about language recommendations.

[If it were up to me I would rewrite it in Rust! Saying "the feds made me" is an excellent excuse :) But I don't like the feds making such strong recommendations/demands when I feel the facts are still quite murky. There simply haven't been enough case studies.]

I also think the feds here (along with techies in general) are undervaluing formal specifications and underestimating the risk of undefined behavior.[1] Rust is very stable but it's not formally specified and until recently had known bugs in its very design, not merely in the rustc implementation. (I think those bugs finally got fixed this year.) Considering how cutting-edge Rust is I am sure there are other "theory bugs" somewhere. The point is that critical software also needs stability, and it is unwise to chase memory safety without considering the risks of being tied to an old version of a compiler, especially with unsafe code.

Again: not saying that Rust is automatically bad because it isn't formally specified. But these issues should at least get lip service.

[1] E.g. this fairly detailed document doesn't discuss this at all: https://www.cisa.gov/sites/default/files/2023-12/The-Case-fo...

erik_seaberg3• 2 years ago

Rust's borrow checker proves some invariants that the code always upholds. Valgrind only checks that this run hasn't triggered some undefined behavior so far, it's always possible that (ab)using it further or another run with different input might.

aithrowawaycomm2• 2 years ago

But then as a matter of policy, why is Rust meaningfully different than something like using Valgrind with C++? Of course there are substantive differences from a developer's perspective.

I did not say they were the same or even equivalent, though I was sloppy with synecdoche and didn't specifically mean Valgrind. My point is that unsafe Rust without Valgrind is more dangerous than C++ with Valgrind, and the feds are not adequately considering this when thinking about how large organizations might rewrite their C++ applications.

"We will rewrite it in 100% safe Rust" is guaranteed way to eliminate virtually all C++ memory errors. It does not follow that "we will rewrite it in 95% safe Rust, except for the tricky bits" will eliminate 95% of C++ memory errors.

sunshowers4• 2 years ago

To be clear this isn't a criticism of Rust's design or implementation - demarcated blocks of unsafe code is pragmatic and sensible. The problem is how humans build software. In this sense I don't think we've really settled whether "rewrite the code in Rust" is actually safer than "redo our technical management to include automated memcheck testing and paired code reviews." At the very least, I don't think the latter is insufficient

I think the latter is woefully insufficient, having seen critical C++ memory safety bugs that got past every sanitizer. For me the debate was settled once our team at Meta shipped a large, high-performance Rust service, built over many years, that simply did not have memory safety bugs -- and its success became a crucial part of why Rust is now a first-class language at Meta.

ArtixFox2• 2 years ago

YAY!!! are we gonna have more formal verification???? woohoo!!

oh its about memory safety.

burnt-resistor3• 2 years ago

FOSS, en mass, probably doesn't do MISRA or consistent testing, relies on random people, may not sign code or artifacts, and could take a hobby/complacency attitude. For software deemed "critical", the feds are free to donate money and assistance to help critical projects formalize and improve themselves rather than proclaiming unfunded mandates on volunteers.

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk

Related Stories