This shouldn't have happened: A vulnerability postmortem • Hacker News Board

Re: This shouldn't have happened: A vulnerability postmortem

#431

Post by ksec » Thu, Dec 02, 2021, 1:53 PM UTC

nineteen999 wrote: post #300

titzer wrote: post #275

Earlier quoted context omitted.

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long .

No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

>The answer will be: these people aren't doers - they are talkers.

I think it is the market values more features and performance, with incremental improvement to current technology at small expense of security. Or the cost of features and performance with currently available tools and work force ( C / C++ ) is vastly cheaper than rewriting it in what ever PL that is.

The only reason why we are starting to do it now, is because the total computer market is 10x larger than we had. Tech is also used 10x more and all of a sudden the cost of security may be worth the cost to switch.

It is all a economic model. or Market Interest. Nothing to do with Armchair and Doers.

Re: This shouldn't have happened: A vulnerability postmortem

#432

Post by titzer » Thu, Dec 02, 2021, 1:54 PM UTC

staticassertion wrote: post #422

nineteen999 wrote: post #411

Earlier quoted context omitted.

This comment misses the point so far as to be completely unnecessary.

It pretty much addresses your core thesis and shows it to be based on a fictional retelling of history.

Which in itself was a distraction from my core point that C is a hazardous material. Instead of having that conversation, they wanted to drag it into mudslinging, making it about good (heroic! doer) and bad (lazy! talker) people, and profoundly misunderstood history.

We don't vilify people who invented asbestos. We don't vilify workers who installed asbestos. They didn't know better. When we did start to know better, there was a period of denial and even willful ignorance, but eventually the evidence became overwhelming. But now, we know about asbestos, and we're stuck with the consequences to exactly the extent we don't engage in careful cleanups. With the dangers of profoundly unsafe code, we haven't even gotten everyone on the same page yet. It's a long process.

As far talking, I had hoped we could avoid the immature shouty part, as I explicitly acknowledged the many people who put in a lot of work to make C/C++ do things and run fast.

For the doing, I guess I'll be getting back to that. It's far more rewarding than these discussions, frankly.

Re: This shouldn't have happened: A vulnerability postmortem

#433

Post by titzer » Thu, Dec 02, 2021, 1:57 PM UTC

pjmlp wrote: post #426

adrianN wrote: post #286

Earlier quoted context omitted.

Unfortunately it's too much work to throw away all code written in unsafe languages. So it's valuable to try and improve tools and techniques that make these languages less unsafe.

One reason why we are getting hardware memory tagging to transform modern computers into basically C Machines, is that everyone kind of gave up doing it at sofware level in regards to C and C++.

Just compile it all to Wasm and we'll run it in virtualization.

Give us memory segments back and I think we have a shot of making this a reality.

Re: This shouldn't have happened: A vulnerability postmortem

#434

Post by staticassertion » Thu, Dec 02, 2021, 1:59 PM UTC

titzer wrote: post #432

staticassertion wrote: post #422

Earlier quoted context omitted.

It pretty much addresses your core thesis and shows it to be based on a fictional retelling of history.

Which in itself was a distraction from my core point that C is a hazardous material. Instead of having that conversation, they wanted to drag it into mudslinging, making it about good (heroic! doer) and bad (lazy! talker) people, and profoundly misunderstood history. We don't vilify people who invented asbestos. We don't vilify workers who installed asbestos. They didn't know better. When we did start to know better,…

Frankly it's a bit hard to untangle your point from the way you write. Something to consider.

> and profoundly misunderstood history.

There seems to be a good deal of that.

> They didn't know better.

For what it's worth, we always knew better with C and C++. As I mentioned elsewhere languages were often designed to be safer but as C became more popular the design mistakes of C were pushed on other languages. You can look at FORTRAN, Algol, etc, to see that compiler writers took measures to ensure certain bug classes weren't possible, and those languages were overtaken by those who wanted their code to just compile, correct or not.

Your post definitely comes across as very preachy, so it's odd that you say you were trying to "avoid the immature shouty part" - that's what the parent was basically criticizing you for.

And then to end it on the implication, once again, that some people are "doers" while the rest of us are just posting on HN (the same thing you are doing????) kinda exemplifies it.

Re: This shouldn't have happened: A vulnerability postmortem

#435

Post by vlovich123 » Thu, Dec 02, 2021, 2:08 PM UTC

VWWHFSfQ wrote: post #132

vlovich123 wrote: post #81

Earlier quoted context omitted.

BoringSSL started as a stripped down OpenSSL. That's very different from a ground-up replacement. The closest attempt here is https://github.com/briansmith/ring but even that borrows heavily the cryptographic operations from BoringSSL. Those algorithms themselves are generally considered to be more thoroughly vetted than the pieces like ASN.1 validation.

nss was also generally considered to be thoroughly vetted though

There’s a world of difference between ASN.1 validation and validation of cryptographic primitives. The serialization/deserialization routines for cryptographic data formats or protocols are where you typically get problems. Things like AES and ECDSA itself, less so, especially when you’re talking about the code in BoringSSL. Maybe some more obscure algorithms but I imagine BoringSSL has already stripped them and ring would be unlikely to copy those.

Why? Cryptographic primitives don’t really have a lot of complexity. It a bytes in/bytes out system with little chance for overflows. The bigger issues are things like side channel leaks or incorrect implementations. The former is where validation helps and the latter is validated by round-tripping with one half using a known-working reference implementation. Additionally, the failure mode is typically safe - if you encrypt incorrectly then no one else can read your data (typically). If you decrypt incorrectly, then decryption will just fail. Ciphers that could encrypt in an unsafe way (ie implementation “encrypts” but the encryption can be broken/key recovered) typically implies the cipher design itself is bad and I don’t think such ciphers are around these days. Now of course something like AES-GCM can still be misused by reusing the nonce but that’s nothing to do with the cipher code itself. You can convince yourself by looking for CVEs of cryptographic libraries and where they live. I’m not saying it’s impossible, but cipher and digest implementations from BoringSSL seem like a much less likely place for vulnerabilities to exist (and thus the security/performance tradeoff probably tilts in a different direction unless you can write code that’s both safer while maintaining competitive performance).

Re: This shouldn't have happened: A vulnerability postmortem

#436

Post by staticassertion » Thu, Dec 02, 2021, 2:16 PM UTC

snovv_crash wrote: post #331

sebcat wrote: post #325

Earlier quoted context omitted.

It wouldn't cause the problem in itself perhaps, but I find it a bit reductive to look at the type in isolation like that. Sometime, somewhere, someone will call std::vector ::data on that vector and use the resulting pointer as the src argument to memcpy (or some other function), and someone else will make a change that causes an overflow of the dst buffer. Shit happens and code written in modern C++ also has bugs a…

You're just talking about more C interfaces, not C++. The same thing would happen in Rust if you tried to pass a chunk of memory to C.

> The same thing would happen in Rust if you tried to pass a chunk of memory to C.

In an 'unsafe' block.

Re: This shouldn't have happened: A vulnerability postmortem

#437

Post by staticassertion » Thu, Dec 02, 2021, 2:20 PM UTC

lucb1e wrote: post #69

rfoo wrote: post #65

Earlier quoted context omitted.

What's special here is the bug is a memory corruption, and memory corruption bugs in such libraries are usually instantly security bugs. Otherwise, the same story could be told as a generic software testing joke: "unit-tests are short-sighted and coverage lies", i.e. an "extremely well-maintained codebase, with extensive unittest, >98% test coverage and constantly scanned by all-static-analyzers-you-may-come-up" can…

> What's special here is the bug is a memory corruption, and memory corruption bugs in such libraries are usually instantly security bugs. Is that special? Are there buffer overflow bugs that are not security bugs? It could be just my bubble as a security consultant, since (to me) "buffer overflow" assumes remote code execution is a given. It's not my area of expertise, though, so perhaps indeed not all reachable buf…

Lots of bugs aren't particularly exploitable. As Tavis notes, one of the major problems here is that there's a structure containing function pointers adjacent to the buffer.

If all you have is a stack overflow you may have your work cut out for you.

Further, while this bug may exist, assertions elsewhere could have meant it was unexploitable. So in isolation it's an overflow but in context it's not reachable. That didn't happen here. This happens a lot actually.

Re: This shouldn't have happened: A vulnerability postmortem

#438

Post by l33t2328 » Thu, Dec 02, 2021, 2:30 PM UTC

6chars wrote: post #67

jjoonathan wrote: post #52

Earlier quoted context omitted.

Oh, the fools! If only they'd built it with 6001 hulls! When will they learn?

Thank you! So many hindsight fortune tellers here.

Not using small bounds on your fuzzing size isn’t exactly something you can only know via hindsight.

Re: This shouldn't have happened: A vulnerability postmortem

#439

Post by Chris2048 » Thu, Dec 02, 2021, 2:30 PM UTC

nineteen999 wrote: post #412

Chris2048 wrote: post #406

Earlier quoted context omitted.

Mindshare and buy-in might be an issue of the ecosystem though. Not enough lisp/Haskell devs.

Maybe thats because while those languages solve particular problem, they, or their proponents aren't solving the particular problems at hand.

Perhaps, but that's speculation. If nor corp will invest outside fortran, cobol, C++ or java then there's a limit to how much problem solving a small community can do on its own dime.

The point is, I think speculative characterisations of -dev members as lazy/unproductive is off mark.

Re: This shouldn't have happened: A vulnerability postmortem

#440

Post by shadowgovt » Thu, Dec 02, 2021, 2:34 PM UTC

staticassertion wrote: post #421

nineteen999 wrote: post #300

Earlier quoted context omitted.

No issue with the first sentence of your message at all, but... > No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

I don't think this paints an accurate picture. This sort of presupposes that C/C++ were a first iteration, but that's not true. People chose C and C++ for bad reasons, even with historic context. Languages used to be more correct. Algol2 used to validate array subscribting and not have null etc. It was C programmers who pushed languages to be worse because it made it easier to write code. They very much created this…

I think it probably makes sense that the languages it's easiest to write code in would dominate in an ecosystem where incentives are encouraging software to eat the world.

The asbestos comparison is pretty apt. Possibly also apt would be steel plants. Yes, steel manufacture is extremely hard on the local environment. Doesn't matter. The world's in the middle of an industrial revolution, and we need steel now. Now now now. We don't have time to wait for the technology to catch up with environmentally-minimized-impact manufacturing. Just condemn a couple cities to twilight noon-times and get on with it.

I don't know if things could have been a lot better and we could be having this conversation on a decentralized network of anonymous machines like we are now. We had to conscript a lot of developers to get here, and make very complex software run on a lot of low-power devices. Erlang, as an example of an alternative, wasn't even open-source unil 1998. LISP machines paused for sixty seconds to do a GC cycle in an era contemporary with machines running executables written in C just... Not requiring that.

Given the factors involved (private ownership of language resources, complex runtime putting minimum requirements on hardware, etc.), C and C++ might be the only two paths of least resistance for a critical era of the software industry.