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

51–60 of 499 posts

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

#51

Post by zionic »

kwertyoowiyop wrote: post #27
zionic wrote: post #22

Earlier quoted context omitted.

C/C++ don’t really have “benefits”, they have inertia. In a hypothetical world where both came into being at the same time as modern languages no one would use them. Sadly, I’m to the point that I think a lot of people are going to have to die off before C/C++ are fully replaced if ever. It’s just too ingrained in the current status quo, and we all have to suffer for it.

C/C++ will be around for at least a hundred years. Our descendants will be writing C/C++ code on Mars.

I don’t know about that, I can see Rust having a certain aesthetic appeal to martians.

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

#52

Post by jjoonathan »

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.

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

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

#53

Post by JulianMorrison »

slownews45 wrote: post #47
JulianMorrison wrote: post #32

Earlier quoted context omitted.

FWIW, Go absolutely would not stop you writing unbounded data into a bounded struct. Idiomatic Go would be to use byte slices which auto-resize, unlike idiomatic C, but you still have to do it.

What's the exploit path assuming no use of unsafe? I can see situations where I could probably get go to crash, but not sure how I get go to act badly. Note: Not a go / Haskell / C# expert so understanding is light here.

Go has no "unsafe" keyword and several parts of the language are unsafe, you're thinking of Rust which has much tighter guarantees.

Go idioms, like accepting data into buffers that are resized by "append", work around the unsafe parts of the language.

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

#55

Post by JulianMorrison »

foobiekr wrote: post #50
JulianMorrison wrote: post #32

Earlier quoted context omitted.

FWIW, Go absolutely would not stop you writing unbounded data into a bounded struct. Idiomatic Go would be to use byte slices which auto-resize, unlike idiomatic C, but you still have to do it.

Idiomatic go would have you using bounded readers though.

Either you read data into a fixed byte[] and stop at its capacity, or you read data into an unbounded byte[] by using append, and Go looks after the capacity, either way, you can't go off the end.

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

#56

Post by jerf »

JulianMorrison wrote: post #32
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…

FWIW, Go absolutely would not stop you writing unbounded data into a bounded struct. Idiomatic Go would be to use byte slices which auto-resize, unlike idiomatic C, but you still have to do it.

Go would stop this from being exploitable. You might be able to make a slice larger than it is "supposed" to be, but it won't overwrite anything else because Go will be allocating new memory for your bigger slice.

But this is hardly a big claim for Go. The reality is that of all current languages in use, only C and C++ will let this mistake happen and have the consequence of overwriting whatever happens to be in the way. Everything else is too memory safe for this to happen.

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

#58

Post by asdfasgasdgasdg »

JulianMorrison wrote: post #32
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…

FWIW, Go absolutely would not stop you writing unbounded data into a bounded struct. Idiomatic Go would be to use byte slices which auto-resize, unlike idiomatic C, but you still have to do it.

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

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

#59

Post by xiphias2 »

slownews45 wrote: post #39
jandrese wrote: post #17

Earlier quoted context omitted.

It's hard to fault a project written in 2003 for not using Go, Rust, Haskell, etc... It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine.

What's somewhat interesting is memory safety is not a totally new concept. I wonder if memory safety had mattered more, whether other languages might have caught on a bit more, developed more etc. Rust is the new kid, but memory safety in a language is not a totally new concept. The iphone has gone down the memory unsafe path including for high sensitivity services like messaging (2007+). They have enough $ to re-wri…

Memory safe language that can compete with C/C++ in performance and resource usage is a new concept.

AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead.

Rust is really something new.

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

#60

Post by ziddoap »

zelon88 wrote: post #40
yjftsjthsd-h wrote: post #2

Ah; the title means "this shouldn't have happened [because the vender was in fact doing everything right]", not "this shouldn't have happened [because it's so stupid]".

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.

Post reply on HN