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

231–240 of 499 posts

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

#231

Post by steveklabnik »

avar wrote: post #224
jcranmer wrote: post #169

Earlier quoted context omitted.

> In Rust every non-trivial library pulls in 10s or even 100s of dependencies. You're exaggerating here. The most recent project I've been working on pulls in 6 dependencies. The anyhow crate has no dependencies, regex 3 (recursively!), clap and csv each 8. Only handlebars and palette pull in 10s of dependencies, and I can trim a fair few dependencies of palette by opting out of named color support (dropping the phf…

It's typical for very large C projects to have perhaps 2-5 dependencies that aren't libc, often something very basic such as zlib, curl or openssl. A rust CSV parser has 8 dependencies?

The CSV crate has five of them: https://crates.io/crates/csv/1.1.6/dependencies

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

#232

Post by baby »

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.

Perl generated assembly. Hehh…

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

#233

Post by baby »

zacmps wrote: post #179
vlovich123 wrote: post #81

Earlier quoted context omitted.

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.

Ring would be cool if not for https://github.com/briansmith/ring#versioning--stability

Or rust-crypto

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

#234

Post by ajxs »

hedora wrote: post #217
staticassertion wrote: post #196

Earlier quoted context omitted.

> Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concern for your mental well-being, than by incredulity or skepticism. Why? I don't get it. Maintenance of NSS has to be seriously expensive.

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.

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

#235

Post by Barrin92 »

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 wondered this when I recently saw that flatpak is written in C. In particular for newer projects that don't have any insane performance constraints I wonder why people still stick to non memory-managed languages.

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

#236

Post by alophawen »

hedora wrote: post #217
staticassertion wrote: post #196

Earlier quoted context omitted.

> Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concern for your mental well-being, than by incredulity or skepticism. Why? I don't get it. Maintenance of NSS has to be seriously expensive.

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.

Sorry for sounding like a broken record, but source please?

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

#237

Post by chii »

fleventynine wrote: post #85
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 c…

> My language selection checklist:

1. What are the people going to implement this an expert in?

Choose that. Nothing else matters.

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

#238

Post by FpUser »

josephg wrote: post #202
jmull wrote: post #190

Earlier quoted context omitted.

It's more of whether Rust fits into every workflow, project, team, build chain, executable environment, etc., that C does. Does rust run everywhere C runs? Does rust build everywhere C builds? Can rust fit into every workflow C does? Are there rust programmers with all the same domain expertise as for C programmers? (Not to mention, the question here isn't whether to write in rust or write in C. It's whether to leave…

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…

>"1kloc / day is a reasonable ballpark figure, landing us at about one person-year to port boringssl to rust."

Porting 1k lines a day, testing and catching and fixing errors to language with incompatible memory model and doing it for a year is insanity. Programmers who propose this kind of productivity most likely have no idea about real world.

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

#239

Post by staticassertion »

Kalium wrote: post #227
josephg wrote: post #194

Earlier quoted context omitted.

> Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concern for your mental well-being, than by incredulity or skepticism. In my experience, porting code more or less directly from one language to another is faster and easier than people assume. Its certainly way faster than I assumed. I hand ported chipmunk2d to javascript a few years ago. Its ~30k LOC and it took me about a month to get…

> In my experience, porting code more or less directly from one language to another is faster and easier than people assume. That's often true right up to the point where you have to be keenly aware of and exceptionally careful with details such as underlying memory management functionality or how comparisons are performed. With this in mind, cryptographic code is likely a pathological case for porting. It would be v…

> for example, that something intentionally reads from uninitialized memory.

Sounds terrible. This should never happen in any program, so any behavior relying on it is already broken.

I'm way more concerned by memory safety issues than cryptographic issues. Frankly, history has shown that cryptographic bugs are far easier to shake out and manage than memory safety bugs.

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

#240

Post by benjaminjackman »

Kalium wrote: post #227
josephg wrote: post #194

Earlier quoted context omitted.

> Suggesting a tabula rasa rewrite of NSS would more likely be met with genuine concern for your mental well-being, than by incredulity or skepticism. In my experience, porting code more or less directly from one language to another is faster and easier than people assume. Its certainly way faster than I assumed. I hand ported chipmunk2d to javascript a few years ago. Its ~30k LOC and it took me about a month to get…

> In my experience, porting code more or less directly from one language to another is faster and easier than people assume. That's often true right up to the point where you have to be keenly aware of and exceptionally careful with details such as underlying memory management functionality or how comparisons are performed. With this in mind, cryptographic code is likely a pathological case for porting. It would be v…

Genuinely curious what the use case(s) of reading from uninitialized are. Performance?
Post reply on HN