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

81–90 of 499 posts

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

#81

Post by vlovich123 »

fulafel wrote: post #68
hwbehrens wrote: post #28

Earlier quoted context omitted.

> It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine. I think this is an understatement, considering that it's a core cryptographic library. It appears to have gone through at least five audits (though none since 2010), and includes integration with hardware cryptographic accelerators. Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concer…

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.

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

#82

Post by asdfasgasdgasdg »

slownews45 wrote: post #79
asdfasgasdgasdg wrote: post #58

Earlier quoted context omitted.

Is it idiomatic go to memcpy into a struct? I would think that this whole paradigm would be impossible in safe golang code.

That's what I'm trying to understand. Let's ignore idiomatic code, people do crazy stuff all the time. What's the go example that gets you from for example an overflow to exploit? That's what I'm trying to follow (not being an expert).

I am skeptical that you could do it without either using the assembler or the unsafe package, but we will see what Julian says.

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

#83

Post by lucb1e »

jandrese wrote: post #48
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.

Are they checking every possible overflow up to the max? Like no overflow at 7377 bytes, lets try 7378... While I can see targeting near natural boundaries (1025 bytes for example), you should be able to skip over most of the search space and verify that it doesn't blow up on enormous values like 16777216 bytes.

It's not that simple though. Single-variable integer overflows can be checked like that, but when the critical byte in a buffer might be at positions 1 through {bufferlength}, you have to do a shotgun approach and see if anything sticks, and at some point the number of possible combinations grows too big even for that.

I'm not an expert on fuzzing myself, but generally I do see the point of having a limit here. Why, then, that limit was not chosen to be the max size for each of the length-checked inputs, I don't know. That does seem a bit more obvious, but also I just read this article so I can't prove that I wouldn't have made the same mistake.

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

#84

Post by UncleMeat »

a-priori wrote: post #36
jandrese wrote: post #20

Earlier quoted context omitted.

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

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.

Coverage-guided fuzzing dramatically mitigates the exponential nature of the search space. It used to be that searching for magic bits was impossible with fuzzing but now it is nearly trivial.

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

#85

Post by fleventynine »

slownews45 wrote: post #13

Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…

My language selection checklist:

1. Does the program need to be fast or complicated? If so, don't use a scripting language like Python, Bash, or Javascript.

2. Does the program handle untrusted input data? If so, don't use a memory-unsafe language like C or C++.

3. Does the program need to accomplish a task in a deterministic amount of time or with tight memory requirements? If so, don't use anything with a garbage collector, like Go or Java.

4. Is there anything left besides Rust?

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

#86

Post by steveklabnik »

jtchang wrote: post #75
slownews45 wrote: post #13

Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…

I'd like to write go or rust but embedded constraints are tough. I tried and the binaries are just too big!

The smallest binary rustc has produced is 138 bytes.

It is true that it’s not something you just get for free, you have to avoid certain techniques, etc. But rust can fit just fine.

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

#87

Post by zelon88 »

ziddoap wrote: post #60
zelon88 wrote: post #40

Earlier quoted context omitted.

Don't think for a minute this wasn't on purpose. Project Zero exists for the sole purpose of trashing and defacing Google competition. In the absence of actual process failure to report on they just resort to a disparagingly memorable title.

> This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. Yep, definitely sounds like Project Zero is trashing Mozilla in this blog post.

They checked for process failure didn't they?

Nobody will remember that line. Everyone is going to remember the title.

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

#89

Post by [deleted] »

ziddoap wrote: post #60
zelon88 wrote: post #40

Earlier quoted context omitted.

Don't think for a minute this wasn't on purpose. Project Zero exists for the sole purpose of trashing and defacing Google competition. In the absence of actual process failure to report on they just resort to a disparagingly memorable title.

> This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. Yep, definitely sounds like Project Zero is trashing Mozilla in this blog post.

[deleted]

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

#90

Post by jschwartzi »

throwaway894345 wrote: post #61
_wldu wrote: post #46

The sooner we can rewrite our programs in Go and Rust, the more secure we will be. Our shells, coreutils, mail readers and web browsers have to be written in safer languages.

Also, far, far easier to build than all of these C programs with their own bespoke build systems and implicit dependency management. The more of the software stack that can be built by mere mortals, the better.

Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case. At least with autotools its supported by default unless the library authors did something egregious like hard coding the sysroot or toolchain paths.
Post reply on HN