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

41–50 of 499 posts

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

#41

Post by rfoo »

varajelle wrote: post #12
rfoo wrote: post #7

Earlier quoted context omitted.

Genuine question: How to switch codes written in 2003 to Rust?

Maybe this is not so much about switching individual existing projects to Rust, but about switching the "industry". Some new projects are still written in C.

Yeah, this makes sense. I'm optimistic and would like to say we're already half-way there. From my PoV very few new projects were written in C in recent years, except those inherently-C (their purpose was to call some other libraries written in C, or libc) and/or embedded (code size and portability requirements).

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

#42

Post by er4hn »

thrdbndndn wrote: post #35

Kinda tangent, but when I was browsing NSS' repo ( https://hg.mozilla.org/projects/nss or mirror: https://github.com/nss-dev/nss/commits/master ) I found that the latest commit has a much older date (7 weeks ago) than the following ones. Why is that? (Sorry I don't know much about git other than push/pull.)

The date of the commit is metadata which can be pushed later than it was made or even altered.

If you look around you can find cute tools to alter your repo history and have the github commit history graph act as a pixelated billboard.

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

#43

Post by foobiekr »

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…

To provide some context for my answer, I’ve seen, first hand, plenty of insecure code written in python, JavaScript and ruby, and a metric ton - measured in low vulnerabilities/M LoC - of secure code written in C for code dating from the 80s to 2021.

I personally don’t like the mental burden of dealing with C any more and I did it for 20+ years, but the real problem with vulnerabilities in code once the low hanging fruit is gone is the developer quality, and that problem is not going away with language selection (and in some cases, the pool of developers attached to some languages averages much worse).

Would I ever use C again? No, of course not. I’d use Go or Rust for exactly the reason you give. But to be real about it, that’s solving just the bottom most layer.

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

#44

Post by oxfeed65261 »

I don’t understand why the “lessons learned” doesn’t recommend always* passing the destination buffer size (using memcpy_s or your own wrapper). It has been a long time since I wrote C++, but when I did this would have been instantly rejected in code review.

*…with, I suppose, potential exceptions in performance-critical code when you control and trust the input; I don’t believe that this code qualifies on either count.

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

#45

Post by spullara »

oleganza wrote: post #33

Usually people say "oh, it's just another typical failure of writing in memory-unsafe C", but here's a slightly different angle: why is this common error is not happening under a single abstraction like "data structure that knows it size"? If C was allowing for such things, then 100000 programs would be using same 5-10 standard structures where the copy-and-overflow bug would be fixed already. Languages like Rust, of…

But performance! Rust and other languages with bounds checking go out of their way to not do it once it is proven that they don't need to. It would be hard to do that as a data structure.

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

#47

Post by slownews45 »

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.

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.

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

#48

Post by jandrese »

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.

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.

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

#49

Post by rfoo »

masklinn wrote: post #37
rfoo wrote: post #7

Earlier quoted context omitted.

Genuine question: How to switch codes written in 2003 to Rust?

librsvg 1.0 was in 2001. Federico Mena-Quintero started switching it to Rust in 2017 (well technically October 2016), the rewrite of the core was finished early 2019, though the test suite was only finished converting (aside from the C API tests) late 2020. So... carefully and slowly.

Thanks, that's exactly what I'm seeking for.

Before that I've never heard of projects which successfully did C to Rust transition, keeping its C API intact and could be used as a drop-in replacement. Glad to hear that there are already some success stories.

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

#50

Post by foobiekr »

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.

Idiomatic go would have you using bounded readers though.
Post reply on HN