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

This shouldn't have happened: A vulnerability postmortem

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

291–300 of 499 posts

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

#291

Post by astrange »

ajxs wrote: post #234
hedora wrote: post #217

Earlier quoted context omitted.

The NSA was caught intentionally complicating that spec. The idea was to ensure it was impossible to implement correctly, and therefore be a bottomless well of zero days for them to exploit. Gotta love the US government’s war against crypto.

Can you provide more information on this? I'd be interested to read about this topic.

He's confused it with Dual_EC_DRBG, a backdoored random number generator in a different non-international standard.

SSL is complicated because we didn't understand how to design secure protocols in the 90s. Didn't need help.

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

#292

Post by Ar-Curunir »

steveklabnik wrote: post #228
josephg wrote: post #202

Earlier quoted context omitted.

Rust does not run everywhere C runs. At least not yet - there's a couple efforts to allow rust to compile to all platforms GCC supports[1]. But we don't need rust to work everywhere C works to get value out of a native rust port of OpenSSL. Firefox and Chrome (as far as I know) only support platforms which have rust support already. As I said in another comment, in my experience, porting code directly between two C-l…

Most fuzzers I’m aware of work with Rust. You can use the same sanitizers as well. Static analysis means a wide range of things, and so some do and some don’t work with Rust. I would be very interested to learn about C static analysis that somehow wouldn’t work with Rust at all; it should be easier to do so in rust because there’s generally so much more information available already thanks to the language semantics.

Eg: the borrow checker is a kind of static analysis that's quite difficult to do soundly for C/C++ (and most other languages)

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

#293

Post by bee_rider »

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…

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.

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

#294

Post by Ar-Curunir »

criddell wrote: post #145
sophacles wrote: post #119

Earlier quoted context omitted.

I don't understand your argument. In 1982 C was a decade old and still very niche. In 1992 C++ was a decade old and still very niche. In 2002 Python were both about a decade old and very niche. In 2005 Javascript was a decade old and still very niche (only used on some webpages, the web was usable without javascript for the most part). I think it's safe to say that all of them went on to enjoy quite a bit of success/…

Languages take off broadly because there's something compelling about them (and it isn't necessarily a technical reason). One of most compelling reasons for adopting Rust is memory safety and that may not be terribly compelling. The comment about it being over a decade old was mostly that it wasn't some new thing that people are unsure about where it can be used. It's mature and has been successful in some niches (an…

How is memory safety not a compelling argument when we're literally in a thread about memory unsafety leading to security exploits?

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

#295

Post by astrange »

muricula wrote: post #182
senderista wrote: post #140

Earlier quoted context omitted.

> We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. Sorry, that just isn’t the case. It is simple to design an allocator that can detect any double-free (by maintaining allocation metadata and checking it on free), and prevent any use-after-free (by just zeroing out the freed memory). (Doing so efficiently is another matter.) It’s not a language o…

Zeroing out freed memory in no way prevents UAFs. Consider what happens if the memory which was freed was recycled for a new allocation? Maybe an example will help make it clearer? This is in pseudo-C++. struct AttackerChosenColor { size_t foreground_color; size_t background_color; }; struct Array { size_t length; size_t *items; }; int main() { // A program creates an array, uses it, frees it, but accidentally forget…

> Zeroing out freed memory in no way prevents UAFs.

Maybe they meant it zeroes out all the references on free? This is possible if you have a precise GC, although not sure if it's useful.

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

#296

Post by astrange »

eyelidlessness wrote: post #261
fleventynine wrote: post #222

Earlier quoted context omitted.

Incrementing an atomic counter every time a reference is copied is a significant amount of overhead, which is why most runtimes prefer garbage collection to reference counting (that, and the inability of referencing counting to handle cycles elegantly). Rust doesn't rely on reference counting unless explicitly used by the program, and even then you can choose between atomically-reference-counted pointers (Arc) vs non…

I promise I’m not trying to be obtuse or argumentative, but I think apart from cycles your response restates exactly what I took from my reading on the subject and tried to articulate. So I’m not sure if what I should take away is: - ARC is generally avoided by GC languages, which puts Swift in a peculiar position for a language without manual memory management (without any consideration of Swift per se for the case…

Swift has a similar memory model to Rust, except that where Rust forbids things Swift automatically copies them to make it work.

People using other languages appear terrified of reference count slowness for some reason, but it usually works well, and atomics are fast on ARM anyway.

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

#297

Post by astrange »

josephg wrote: post #207
senderista wrote: post #146

Earlier quoted context omitted.

Then Java is also unsafe by the same standard.

Yes. Java and C# are unsafe by the same standard. Last I checked, they both allow multiple threads to nonatomically modify a raw variable - which can lead to data races and data corruption. I haven't heard of anyone getting RCE out of this class of bug in C# or java though.

It's common to exploit JavaScript engines with this kind of bug, and JS engines probably have better security teams at this point, so I expect you could get an RCE if you really tried.

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

#298

Post by fulafel »

vlovich123 wrote: post #81
fulafel wrote: post #68

Earlier quoted context omitted.

The article says Chromium replaced this in 2015 in their codebase. (With another memory-unsafe component, granted...)

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.

The Ring readme doesn't really cover its functionality but sounds like it may be a lower level crypto lib than NSS? And it also seems to be partly written in C.

Anyway, NSS wouldn't necessarily need to be replaced with a Rust component, it could well be an existing lib written in another (possibly GCd) safeish language, or some metaprogramming system or translator that generated safe C or Rust, etc. There might be something to use in Go or .net lands for example.

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

#299

Post by moring »

Lhiw wrote: post #73
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…

Unit tests aren't really for bug catching, they're to ensure you haven't changed behavior when you don't expect to. They enable refactoring code in ways not possible without them.

FWIW, this does not match my experience. I have caught lots of bugs with unit tests, especially in code that is fundamentally complex (because it does complex things, not because it needs polishing). OTOH, refactorings often span units because real simplification comes from changing the ways units interact, or even which units exist, so the tests have to be changed anyway.

Granted, even tests that have to be changed have some value in securing a refactoring.

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

#300

Post by nineteen999 »

titzer wrote: post #275
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…

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 over 50 years to write this kind of software, organize standards bodies for their languages and platforms, get their software packaged as part of mainstream operating systems and out into the world, deal with patches from users, and help millions of other people make a living, enable the internet to happen, etc.

We will wonder why with all the millions of lines of C/C++ reference code available to be perused and then rewritten in Rust, Pascal, C#, Zig or Nim, and the vociferousness of their advocates, why that didn't happen in a reasonable timeframe.

We will wonder why all the Lisp and Haskell programmers who sneer down their nose at working C/C++ programmers in forums like this on a daily basis, didn't get off their asses with their One True Language (TM) and come to the worlds rescue.

The answer will be: these people aren't doers - they are talkers. It's one thing to get a toy proof of concept OS in your favourite language of choice that supports like 5 drivers. It's another thing to contribute to and build an ecosystem depended on by millions of developers daily. C/C++ people may not always be the sharpest tools in the shed, and they may be a dime a dozen. But they know how to organize themselves in loose groups of more than just a few developers, and work with other people.

We may have issues with the quality of what they ship on a frequent basis, but at least they ship instead of posting endless comments on internet forums about how it's all the others peoples fault.

Post reply on HN