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

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

#211

Post by dpifke » Thu, Dec 02, 2021, 12:16 AM UTC

fleventynine wrote: post #172

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…

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.

Not sure current state of the art, but Go's worst-case pause time five years ago was 100µs: https://groups.google.com/g/golang-dev/c/Ab1sFeoZg_8

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

#212

Post by FartyMcFarter » Thu, Dec 02, 2021, 12:25 AM UTC

IshKebab wrote: post #163

slownews45 wrote: post #39

Earlier quoted context omitted.

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…

The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs. Nobody is going to ship a JVM with their project just so they can have the "fun" experience of using Java FFI to do crypto. Realistically Rust is still the only memory safe language that you could use, so it's not especially surprising that nob…

> The issue isn't really that there was a shortage of memory safe languages, it's that there was a shortage of memory safe languages that you can easily use from C/C++ programs.

Just as importantly, there was also a shortage of memory safe languages that had good performance.

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

#213

Post by bialpio » Thu, Dec 02, 2021, 12:27 AM UTC

bluejekyll wrote: post #98

rfoo wrote: post #65

Earlier quoted context omitted.

What's special here is the bug is a memory corruption, and memory corruption bugs in such libraries are usually instantly security bugs. Otherwise, the same story could be told as a generic software testing joke: "unit-tests are short-sighted and coverage lies", i.e. an "extremely well-maintained codebase, with extensive unittest, >98% test coverage and constantly scanned by all-static-analyzers-you-may-come-up" can…

Ah, brings to mind one of my favorite Dijsktra quotes, "Program testing can be used to show the presence of bugs, but never to show their absence!" I've never understood that to mean that he wasn't in favor of automated testing, only that it's got its limits. In this case, they now know a test case that was missing.

Yup, in my previous gig we had an approach that if there is a bug in the code that the tests didn't catch, it's actually 2 bugs: a product and a test issue. Similarly, if a dev needed to have access to the live debugging session to diagnose the issue, it meant there was yet another bug (to improve debuggability of the product). It was quite nice, taught me a lot.

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

#214

Post by nova22033 » Thu, Dec 02, 2021, 12:30 AM UTC

gausswho wrote: post #208

albntomat0 wrote: post #149

Since this comes up whenever there is a Project Zero article, here is a summary I made in summer 2020 on the distribution of the bugs they find/report: Since this always comes up, here's an overview I made several weeks ago about where Project Zero focuses their efforts: All counts are rough numbers. Project zero posts: Google: 24 Apple: 28 Microsoft: 36 I was curious, so I poked around the project zero bug tracker t…

I'm not clear. What do these varying counts imply to you?

Because someone will invariably accuse project zero of being hostile to google's competitors.

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

#215

Post by Gigachad » Thu, Dec 02, 2021, 12:30 AM UTC

staticassertion wrote: post #197

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…

It only matters if rust runs everywhere that Firefox runs, which it does.

Considering firefox already uses rust components, that seems a safe bet.

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

#216

Post by dralley » Thu, Dec 02, 2021, 12:38 AM UTC

mleonhard wrote: post #180

tialaramex wrote: post #152

Earlier quoted context omitted.

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…

> A large Rust project uses unsafe only because its authors don't care enough.

This is not true at all. There are plenty of reasons to occasionally use unsafe code, even if your bar for "is it really worth it" is quite high. One reason, if you're writing a crypto library, is that certain kinds of timing attacks are pretty much impossible to prevent without inline assembly.

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

#217

Post by hedora » Thu, Dec 02, 2021, 12:42 AM UTC

staticassertion wrote: post #196

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

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

#218

Post by tristor » Thu, Dec 02, 2021, 12:51 AM UTC

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 not lost on me that the organization that produced NSS also invented Rust. That implies the knowledge of this need is there, but it’s not so straightforward to do.

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

#219

Post by eyelidlessness » Thu, Dec 02, 2021, 12:53 AM UTC

fleventynine wrote: post #186

eyelidlessness wrote: post #184

Earlier quoted context omitted.

Answering a question with a sincere question: if the answer to 3 is yes to deterministic time, but no to tight memory constraints, does Swift become viable in question 4? I suspect it does, but I don’t know nearly enough about the space to say so with much certainty.

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?) for Rust’s case they’re regarded as a relatively fixed overhead?

- That would seem to hold for Swift as well, just… with more overhead.

To the extent any of this is wrong or missing some nuance, I’m happy to be corrected.

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

#220

Post by sizediterable » Thu, Dec 02, 2021, 12:54 AM UTC

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

Converting code to Rust while keeping the logic one-to-one wouldn't work. Rust isn't ensuring memory safety by just adding some runtime checks where C/C++ aren't. It (the borrow checker) relies on static analysis that effectively tells you that the way you wrote the code is unsound and needs to be redesigned.