5 ms·
Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk
- gnabgib 2y agoCISA guidance: https://news.ycombinator.com/item?id=41863640 https://news.ycombinator.com/item?id=41863640
- lisper 2y agoJust wait five days and this will all go away.
- UltraSane 2y agoNope, 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 2y agoYou can't just hand wave the entirety of the C/C++ ecosystem away. There is no second option for many applications or hardware
- overstay8930 2y agoBoth admins want this to happen, one will just grant more exemptions than the other.
- Jtsummers 2y agoDOD 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.
- gigel82 2y agoC++ 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...
- sunshowers 2y agoCan we please be responsible professionals and move past this. This was settled many years ago.
- bagels 2y agoYou must have had incredible luck to never have made a mistake, even ones you didn't realize you made.
- CoastalCoder 2y agoI 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 2y agoI 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++.
- AlotOfReading 2y agoI 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.
- Animats 2y 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.
- UltraSane 2y agoI shudder to think just how badly the US, Russia, and China have hacked each other by this point.
- generalizations 2y agoI 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?
- Veserv 2y agoIt 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.
- 3eb7988a1663 2y agoSurely 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 2y agoI 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 2y agoWhy does that not apply to router firmware for example? The primary role of a domestic router is to be exposed to the internet.
- jerlam 2y agoOn 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.
- synergy20 2y agothat 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 2y agoThat sounds great. I love Rust.
- omeid2 2y agoThere is a few options, for example Ocaml, Swift, Erlang, and so on. http://ocamlverse.net/content/systems_programming.html http://ocamlverse.net/content/systems_programming.html https://www.swift.org/blog/embedded-swift-examples/ https://www.swift.org/blog/embedded-swift-examples/ https://www.erlang.org/doc/system/embedded.html https://www.erlang.org/doc/system/embedded.html
- candiddevmike 2y agoGC or VM may be perfectly fine for system level programming. Microsoft's project singularity had everything including the kernel using GC iirc
- tdeck 2y agoPerhaps Ada?
- synergy20 2y agoalso MISRA c and c++
- hgs3 2y agoYou 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.
- akira2501 2y agoI 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 2y agoHow would any software be FIPS compliant? Is there a "memory-safe" implementation of TLS that is also FIPS certified?
- est31 2y agorustls 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-back-end-and-fips/ https://www.memorysafety.org/blog/rustls-with-aws-crypto-bac...
- Veserv 2y agoCool. 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?
- deleted 2y ago[deleted]
- Sevii 2y agoDo 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.
- Veserv 2y agoThere are plenty with good security track records, formal specifications, formal proofs of various security properties, and decades of deployments. SCOMP, GEMSOS, INTEGRITY-178, seL4.
- ArtixFox 2y agogod seL4 everywhere would be awesome.
- kyleee 2y agoDon’t forget Temple OS
- burnt-resistor 2y ago> Eschew flamebait. Avoid generic tangents. Omit internet tropes. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- burnt-resistor 2y agoseL4 is far more rigorous that the others. The problem today is a widespread lack of understanding of software engineering approaches and tools for formal verification of source model verification, compiler toolchains, and binaries, and also a lack of diligence and effort in implementing rigorous practices.
- cryptonector 2y agoThere's go to be billions of loc of critical C/C++ software left. By 2026? Doesn't sound realistic.
- Jtsummers 2y agoThe 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.
- cryptonector 2y agoThanks.
- tetnis 2y agoCISA is stupid. Logic bugs don't go away with Rust.
- tetnis 2y agoPeople 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.
- sunshowers 2y agoI regularly solve logic bugs using affine typing and shared xor mutability, so clearly some subset of logic bugs is solved with Rust, no?
- tetnis 2y agoOk, I didn't really define logic bugs. I think of things like race conditions as memory bugs because its improper access to the same variable. So I suppose All Bugs Are Logic Bugs. But I really meant that many software software vuln aren't even that fancy. Sure if you have something like an iPhone which has whole companies trying to hack it, then eventually the bugs you have left are fancy heap overflows. But lots of products have logic errors, like mischecking creds etc. I will also pick on CISA for recommending a language that requires something like cargo. Why is it a good idea for critical infrastructure to require internet access to compile its code? CISA is supposed to be concerned about the fact that critical infra. is privately held and they should encourage secure practices. So suggest a language that in practice requires internet access? this is absurd to me.
- sunshowers 2y agoCargo does not require internet access to compile. You need it just to download packages once (which you obviously do in any ecosystem). Cargo also cryptographically verifies that downloaded packages haven't been tampered with. Affine types also help with credential checking! Newtype wrappers synergize really well with them. I wrote a post about some of this a few years ago: https://sunshowers.io/posts/types/ https://sunshowers.io/posts/types/
- exabrial 2y agoSo... F35?
- pizlonator 2y agoThis 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/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/delug...
- caseysoftware 2y 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 2y agoWhile 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.
- nanolith 2y agoLeave 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_seaberg 2y agoI'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?
- nanolith 2y agoYep. 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.
- erik_seaberg 2y agoI'm definitely digging into this, thank you! I'm a little concerned about ESBMC's "simulating a finite prefix of the program execution with all possible inputs" when important software like operating systems are intended to run indefinitely. Would they start with a valid state (filesystem, process list) and prove no invalid state is reachable within n syscalls or interrupts? Maybe I was hoping for proving invariants.
- aithrowawaycomm 2y agoThis 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-for-Memory-Safe-Roadmaps-508c.pdf https://www.cisa.gov/sites/default/files/2023-12/The-Case-fo...
- erik_seaberg 2y agoRust'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.
- ArtixFox 2y agoYAY!!! are we gonna have more formal verification???? woohoo!! oh its about memory safety.
- burnt-resistor 2y agoFOSS, 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.