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

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

#321

Post by kovac » Thu, Dec 02, 2021, 6:36 AM 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…

I like this man. I think the only thing we'll look back on is, considering how those who came before us delivered so much with so little (compute power, parallism, safety, tooling), how we fell so far from grace and fuck things right into the ground with slow, unsafe, useless piles of garbage that don't even perform their primary duties well other than collect data.

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

#322

Post by baby » Thu, Dec 02, 2021, 6:44 AM UTC

jandrese wrote: post #20

lucb1e wrote: post #8

A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…

> - "There is an arbitrary limit of 10000 bytes placed on fuzzed input. There is no such limit within NSS; many structures can exceed this size. This vulnerability demonstrates that errors happen at extremes" This is the one that seemed short sighted to me. It's a completely arbitrary (and small!) limit that blinded the fuzzer to this very modest sized buffer overflow.

If you increase the limit you lose in coverage as you can only do so many exec/s

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

#323

Post by baby » Thu, Dec 02, 2021, 6:46 AM UTC

moring wrote: post #302

a-priori wrote: post #36

Earlier quoted context omitted.

The problem is that the search space grows (exponentially?) as you increase the fuzzer’s limit. So there’s a cost, and likely diminishing returns, to raising that limit.

Is it possible to feed a fuzzer with information from static analysis to limit the search space? Such as, if you have a check like "someParameter > 0" in the code, have the fuzzer generate a positive, negative, and zero value for someParameter, but not thousands of them -- at least not based on this check alone -- because they will all behave the same.

There's whitebox fuzzing that's starting to become a thing, when your fuzzer gets stuck you give the non-giving corpus to an SMT solver and it'll try to see if there exists an input that could uncover a new path. I'm really excited about these but haven't really followed the advances.

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

#324

Post by hn_go_brrrrr » Thu, Dec 02, 2021, 6:49 AM UTC

Godel_unicode wrote: post #283

tptacek wrote: post #153

Earlier quoted context omitted.

I don't know anybody who thought OpenSSL was well-maintained in and before the Heartbleed era (it's a fork of SSLeay, which was Eric Young's personal project). Post-Heartbleed --- a decade ago, longer than the time lapse between SSLay and OpenSSL --- maintenance of OpenSSL has improved dramatically.

I think you and a sibling comment might be too close to the problem. When heartbleed dropped my Twitter feed had a few crypto engineers saying "I mean, eventually this was going to happen" and a ton of developers whose main language starts with a "p" going "how?? OpenSSL is core plumbing of the internet, it can't be this bad can it???". Edit: to be clear, not maligning the "p" language developers, I was one myself. S…

Yeah, those Perl hackers are really out of touch :-)

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

#325

Post by sebcat » Thu, Dec 02, 2021, 7:05 AM UTC

lenkite wrote: post #309

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 .

Is it OK to remove modern C++ from your statement ? Using a `std::vector ` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.

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 and some of those bugs have security implications.

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

#326

Post by wolf550e » Thu, Dec 02, 2021, 7:12 AM UTC

tannhaeuser wrote: post #315

bee_rider wrote: post #293

Earlier quoted context omitted.

To be fair, it was unreasonable to expect Prolog coders to keep up with crypto advancements, I mean the language pre-dates SSL by decades.

Care to expand on what Prolog coders have to do with OpenSSL? Not getting the context here.

A joke about "developers whose main language starts with a "p"", meaning presumably perl, php and python. I guess in this context, ruby and JavaScript are also languages starting with "p".

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

#327

Post by rurban » Thu, Dec 02, 2021, 7:14 AM UTC

ndesaulniers wrote: post #258

rurban wrote: post #147

Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires the size of dest to be defined. The applause goes to the glibc maintainers, who still think they are above that.

Doesn't memcpy_s not take into account the sources size though? You could still read past the end of an object with it, right?

nope, it checks both. How could you call it secure without checking both sizes? memcpy_s(dest,dmax,src,slen)

and my implementation safeclib even at compile-time, similar to glibc's FORTIFY.

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

#328

Post by afiori » Thu, Dec 02, 2021, 7:14 AM UTC

masklinn wrote: post #301

speed_spread wrote: post #282

Earlier quoted context omitted.

At least Asbestos is inert once in place.

Isn’t asbestos always inert unless you matchmake it to a ridiculously strong oxidiser? In my recollection it dealt purely physical damage, and its inability to react with much of anything is what leads to its accumulation in dwellings.

I believe they mean inert as it relate to health, not chemically.

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

#329

Post by Animats » Thu, Dec 02, 2021, 7:19 AM UTC

sebcat wrote: post #325

lenkite wrote: post #309

Earlier quoted context omitted.

Is it OK to remove modern C++ from your statement ? Using a `std::vector ` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.

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…

Sometime, somewhere, someone will call ...

I call this the mold seeping through the wallpaper. C++ tries to paper over C's terrible array model by using collection class templates, but those constructs leak. Too many things need raw pointers.

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

#330

Post by rurban » Thu, Dec 02, 2021, 7:19 AM UTC

loeg wrote: post #284

rurban wrote: post #147

Now take a deep look at the POSIX C standard, Annex K. The bounds checked extensions. Using these would have definitely avoided the problem. memcpy_s requires the size of dest to be defined. The applause goes to the glibc maintainers, who still think they are above that.

Annex K is pretty awful[1]. There are plenty of fine solutions here in hindsight, but glibc adopting Annex K isn’t one of them. NSS has a plethora of build targets, including Windows - which does not implement Annex K either (despite inspiring it). [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

Wrong. First it's good, not awful. Awful are only the ones not using it.

Second, Windows implements Annex K as only major provider. The others are some minor embedded targets, plus Android Bionic recently.

Implementations, such as safeclib, are cross platform. you can use it everywhere. Security and crypto people per se don't use it (incompetence or not invented here), but security aware people, such as on embedded or in the industry.