This shouldn't have happened: A vulnerability postmortem • Hacker News Board

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

#171

Post by oleganza » Wed, Dec 01, 2021, 10:54 PM UTC

spullara wrote: post #45

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.

Well, here comes the type system, so your fancy data structure has zero cost. Rust recently got more support for const generics, so you could encode size bounds right in the types and skip unnecessary checks.

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

#172

Post by fleventynine » Wed, Dec 01, 2021, 10:56 PM UTC

throwaway894345 wrote: post #158

fleventynine wrote: post #85

Earlier quoted context omitted.

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…

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…

If it can really guarantee single-digit microsecond pauses in my realtime thread no matter what happens in other threads of my application, that is indeed a game changer. But I'll believe it when I see it with my own eyes. I've never even used a garbage collector that can guarantee single-digit millisecond pauses.

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

#173

Post by twodayslate » Wed, Dec 01, 2021, 10:57 PM UTC

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);

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

#174

Post by Gigachad » Wed, Dec 01, 2021, 10:57 PM UTC

criddell wrote: post #31

DantesKite wrote: post #6

This sounds like a very good argument for switching over to Rust.

Rust has been around for more than a decade now and is still very niche. Evidently, it isn't a good enough argument.

A decade seems like an appropriate amount of time for a language to mature and take off. Ruby was very niche for 10 years until rails came out. Rust now seems to be spreading pretty steadily and smaller companies are trying it out.

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

#175

Post by varajelle » Wed, Dec 01, 2021, 10:58 PM UTC

criddell wrote: post #148

Arnavion wrote: post #129

Earlier quoted context omitted.

Mozilla's relevance hasn't mattered to Rust for a while.

So if Mozilla decided to step back from Rust it wouldn't be a major blow to Rust? I was under the impression that they were still important.

They already stepped back a year ago. They fired most of the rust team. https://blog.mozilla.org/en/mozilla/changing-world-changing-...

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

#176

Post by throwaway984393 » Wed, Dec 01, 2021, 10:59 PM UTC

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

A century ago, buildings were quite dangerous, and likely to kill you in all sorts of situations. Wood burns, and concrete and brick don't. Clearly wood is an "unsafe material". But just changing the material didn't result in safer buildings. Buildings made of brick and concrete still killed people.

It turns out that there are a lot of factors that go into building safety. The material is one vulnerability, sure. But there's also the connection method and strength, the calculated loads, shear forces, wind, earthquakes, egress, and a billion other considerations.

What resulted in better building safety was the development of building codes. Even using flammable building materials, people adapted the way they built so that the end result was much safer than before. If you told a builder you'd never buy a wooden home because wood is "unsafe", they'd laugh at you - and then sell you a bunch of "inflammable" crap you don't need.

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

#177

Post by dkga » Wed, Dec 01, 2021, 11:03 PM UTC

jandrese wrote: post #17

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…

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.

I think a good approach could be what curl is doing. AFAIK they are replacing some security-critical parts of their core code with Rust codebases, importantly without changing the API.

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

#178

Post by whimsicalism » Wed, Dec 01, 2021, 11:06 PM UTC

throwaway894345 wrote: post #158

fleventynine wrote: post #85

Earlier quoted context omitted.

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…

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

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

#179

Post by zacmps » Wed, Dec 01, 2021, 11:07 PM UTC

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.

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

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

#180

Post by mleonhard » Wed, Dec 01, 2021, 11:08 PM UTC

tialaramex wrote: post #152

mleonhard wrote: post #126

What went wrong - Issue #0: The library was not re-written in a language that prevents undefined behavior (UB).

I don't think there are any general purpose programming languages with decent performance which outright "prevent undefined behaviour" in something like NSS. Rust, for example, does not. safe Rust doesn't have undefined behaviour but of course you can (and a large project like this will) use unsafe Rust and then you need the same precautions for that code. This sharply reduces your exposure if you're doing a decent j…

> I don't think there are any general purpose programming languages with decent performance which outright "prevent undefined behaviour" in something like NSS. Rust, for example, does not.

You know what I meant by "a language that prevents UB". Your comment argues semantics. That's not nice. Please stop.

> safe Rust doesn't have undefined behaviour but of course you can (and a large project like this will) use unsafe Rust and then you need the same precautions for that code.

How can that can be true? A large Rust project uses unsafe only because its authors don't care enough. Instead of spending the effort to make the safe code fast enough, they resort to using `unsafe`. It's the same reason that people add code without tests or add APIs without docs.

A special purpose language for writing cryptography code is a terrible idea. Once we have a language suitable for handling untrusted data, we should make it good enough to use for everything and then use it for everything.

I have put some effort into making safe Rust usable for everything. I wrote a safe regex library [0] and a safe async library [1]. I plan to put more effort into these and other libraries. For example, I am working on safe Rust TLS and HTTP libraries. Eventually, safe Rust will be production quality and fast enough for most use-cases.

[0] https://crates.io/crates/safe-regex

[1] https://crates.io/crates/safina