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

221–230 of 499 posts

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

#221

Post by jmull »

twodayslate wrote: post #173
jmull wrote: post #155

To me, PORT_Memcpy is one problem here. There are two buffers and one size -- the amount of memory to copy. There should be PORT_Memcpy2(pDest, destSize, pSource, numBytesToCopy) (or whatever you want to call it) which at least prompts the programmer to account for the size destination buffer. Then flag all calls to PORT_Memcpy and at least make a dev look at it. (Same for the various similar functions like strcpy, e…

Of course it would just end up being PORT_Memcpy2(cx->u.buffer, sigLen, sig->data, sigLen);

Someone could do that, but the point of having the dest buffer size is to at least give the programmer a chance to try to get it right.

I also wonder if a linter could notice that the dest buffer size passed isn’t the actual size of the buffer. (That leads the the next problem in the code, if you look at the definition of that buffer, so that’s good.)

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

#222

Post by fleventynine »

eyelidlessness wrote: post #219
fleventynine wrote: post #186

Earlier quoted context omitted.

I'm not super familiar with Swift, but I don't see how it could be memory-safe in a multi-threaded context without some sort of borrow checker or gc. So I think it is rejected by question #2.

Swift uses automatic reference counting. From some cursory reading, the major difference from Rust in this regard is that Swift references are always tracked atomically, whereas in Rust they may not be atomic in a single-owner context. To my mind (again, with admittedly limited familiarity), I would think: - Atomic operations in general don’t necessarily provide deterministic timing, but I'm assuming (maybe wrongly?)…

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-atomic-reference-counted pointers (Rc) that the type system prevents from being shared between threads.

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

#223

Post by throwaway894345 »

whimsicalism wrote: post #178
throwaway894345 wrote: post #158

Earlier quoted context omitted.

If your "deterministic amount of time" can tolerate single-digit microsecond pauses, then Go's GC is just fine. If you're building hard real time systems then you probably want to steer clear of GCs. Also, "developer velocity" is an important criteria for a lot of shops, and in my opinion that rules out Rust, C, C++, and every dynamically typed language I've ever used (of course, this is all relative, but in my exper…

My impression was Go's GC was a heck of a lot slower than "single-digit microsecond pauses." I would love a source on your claim

I had seen some benchmarks several years ago around the time when the significant GC optimizations had been made, and I could've sworn they were on the order of single-digit microseconds; however, I can't find any of those benchmarks today and indeed any benchmarks are hard to come by except for some pathological cases with enormous heaps. Maybe that single-digit  µs values was a misremembering on my part. Even if it's sub-millisecond that's plenty for a high 60Hz video game.

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

#224

Post by avar »

jcranmer wrote: post #169
dmz73 wrote: post #143

Earlier quoted context omitted.

I don't think the exact URL is the problem, it is the fact that it is so easy to include dependencies from external repository that is the problem. In Rust every non-trivial library pulls in 10s or even 100s of dependencies. I don't think anyone can expect that all of these libraries are of good quality but how would one even try to verify that? And you have to verify it every time you update your project. Then there…

> 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?

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

#225

Post by throwaway894345 »

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?

A Go program wouldn't even need curl, zlib, or openssl as it has equivalent implementations in its stdlib.

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

#226

Post by asdfasgasdgasdg »

cjbprime wrote: post #122
slownews45 wrote: post #47

Earlier quoted context omitted.

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 is sometimes considered memory unsafe because of the presence of data races. (This is a controversial semantics.)

Even in the case of data races, you could not develop an exploit like the one discussed in this blog post, right? It's kinda a non-sequitur in this context?

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

#227

Post by Kalium »

josephg wrote: post #194
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…

> 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 very easy to accidentally introduce an exploitable bug by missing, for example, that something intentionally reads from uninitialized memory.

On top of the re-audit being expensive.

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

#228

Post by steveklabnik »

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…

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.

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

#229

Post by steveklabnik »

lucb1e wrote: post #100
throwaway894345 wrote: post #61

Earlier quoted context omitted.

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.

Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is j…

To be clear, Cargo doesn’t pull code from GitHub.

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

#230

Post by steveklabnik »

throwaway894345 wrote: post #113
lucb1e wrote: post #100

Earlier quoted context omitted.

Honestly I don't like the build process of most go/rust/javascript software any better than C++. It's harder to find the dependencies for building the latter, but the former has its own version of dependency hell. I have real trouble building both types of projects, though admittedly (especially when the building instructions don't work when followed to the letter) C++ a bit more than the strategy of "everything is j…

> everything is just pulled from github I hear this a lot, but I can't divine any substance from it. Why is GitHub a less-secure repository medium than SourceForge + random website downloads + various Linux package managers? Maybe this is a red herring and your real complaint is that the Rust ecosystem is less secure than the C/++ ecosystem? > you only have to make sure you've got gigabytes of free space in ~/.cache/…

Rust programs can in fact run arbitrary code at build time, unlike Go. Pros and cons to both approaches.
Post reply on HN