Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

thenewstack.io

Post reply on HN
Print view View original

61–70 of 100 posts

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

#61

Post by EasyMark »

generalizations wrote: post #33
Animats wrote: post #5

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

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

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

#62

Post by kyleee »

Veserv wrote: post #51
Sevii wrote: post #39

Earlier quoted context omitted.

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.

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.

Don’t forget Temple OS

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

#63

Post by CoastalCoder »

CuriousCosmic wrote: post #17
CoastalCoder wrote: post #10

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

Maybe we're talking about different subsets of C++.

IIUC, you're referring to codebases which limit themselves to what's often called "modern C++".

I'm working with codebases that draw from a gnarly combination of older and newer parts of the current language spec.

So in my experience, very few C++ programmers are familiar with every part of the current language spec that has relevance to these codebases.

I.e., their code isn't obviously correct regarding many aspects of correctness, including memory safety.

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

#64

Post by rich_sasha »

nanolith wrote: post #50
erik_seaberg wrote: post #47

Earlier quoted context omitted.

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…

How very interesting.

Does that detect issues at runtime, or prove statically that the code is "safe" (whatever the remit of that definition is here)?

If the former, I guess you're still at the mercy of test coverage and all the pitfalls it entails.

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

#65

Post by pointlessone »

EasyMark wrote: post #61
generalizations wrote: post #33

Earlier quoted context omitted.

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?

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

50-70% defect reduction is significant, though.

It is true that black hats are going to focus on the remainder pretty much by definition because there’s no other choice. The rest is a problem and it needs a solution. But the fact that it exists is not a sound argument against choosing a memory-safe language.

Current solutions are not ideal but they still eliminate a huge portion of defects. Today we can avoid all the memory issues and we also can focus on the next biggest category of defects. If we’ll keep halving possible defects it won’t take long before software is near defect-free.

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

#66

Post by Animats »

Veserv wrote: post #48
generalizations wrote: post #33

Earlier quoted context omitted.

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 requ…

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

Right. I was around for that era and worked on some of those systems.

NSA's first approach to operating system certification used the same approach they used for validating locks and filing cabinets. They had teams try to break in. If they succeeded, the vendor was told of the vulnerabilities and got a second try. If a NSA team could break in on the second try, the product was rejected.

Vendors screamed. There were a few early successes. A few very limited operating systems for specific military needs. Something for Prime minicomputers. Nothing mainstream.

The Common Criteria approach allows third-party labs to do the testing, and vendors can try over and over until success is achieved. That is extremely expensive.

There are some current successes. [1][2] These are both real-time embedded operating systems.

[1] https://www.acsac.org/2009/program/case/ccsc-Kleidermacher.p...

[2] https://provenrun.com/provencore/

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

#67

Post by burnt-resistor »

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.

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

#68

Post by SleepyMyroslav »

Animats wrote: post #5

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

>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". :)

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

#69

Post by burnt-resistor »

Veserv wrote: post #51
Sevii wrote: post #39

Earlier quoted context omitted.

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.

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.

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

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

#70

Post by burnt-resistor »

kyleee wrote: post #62
Veserv wrote: post #51

Earlier quoted context omitted.

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.

Don’t forget Temple OS

> Eschew flamebait. Avoid generic tangents. Omit internet tropes.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN