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

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

#101

Post by throwaway894345 » Wed, Dec 01, 2021, 9:06 PM UTC

jschwartzi wrote: post #90

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.

Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent month…

EDIT: Just re-read the below and realized it might sound terse and argumentative; apologies, I was typing quickly and didn't mean to be combative. :)

> I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy

Crumby build systems force you to figure out how to build and install dependencies (or die trying). Modern build systems allow you to figure out how to build and install dependencies. If the former is "more UNIXy" than the latter, then I strongly contend that "UNIXy" is not a desirable property.

> It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use.

"Centralized" is irrelevant. Go's package manager is decentralized, for example. Moreover, many folks in the C world rely heavily on centralized repositories. Further, I would be shocked if manually managing your dependencies was somehow less error prone (and thus more secure) than having an expert-developed program automatically pull and verify your dependencies.

> Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case.

I mean, C doesn't care about anything, much less cross compilation. It puts the onus on the developer to figure out how to cross compile. Some build system generators (e.g., CMake, Autotools) purport to solve cross compilation, but I've always had problems. Maybe I just don't possess the mental faculties or years of experience required to master these tools, but I think that supports my point. By comparison, cross compilation in Go is trivial (set `CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build` works virtually every time from any platform). I haven't done much Rust cross-compilation, but I would be surprised if it were harder than C/C++.

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

#102

Post by Veserv » Wed, Dec 01, 2021, 9:07 PM UTC

lucb1e wrote: post #8

A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…

How do you know that it was actually "extremely well-maintained"? Everybody thought OpenSSL was well-maintained since it was used as critical infrastructure by multi-billion dollar megacorporations, but it was actually maintained by two full-time employees and a few part-time volunteers with maybe a quick once-over before a commit if they were lucky. How about sudo, a blindly trusted extremely sensitive program [1], which is maintained by basically one person who has nearly 3,000,000(!) changes[2] over 30 or so years?

Assuming that something is well-maintained because it is important is pure wishful thinking. Absent a specific detailed high quality process, or an audit that they conform to a well-established process that has demonstrably produced objectively high-quality output in a large percentage of audited implementations of that process (thus establishing nearly every instance of the audited process -> high quality output) all evidence indicates that you should assume that these code bases are poorly maintained until proven otherwise[3]. And, even the ones that are demonstrably maintained usually use very low quality processes as demonstrated by the fact that almost nobody working on those projects would be comfortable using their processes on safety-critical systems [4] which is the minimum bar for a high quality process (note the bar is "believe it is okay for safety-critical"). In fact, most would be terrified of the thought and comfort themselves knowing that their systems are not being used in safety-critical systems because they are absolutely not taking adequate precautions, which is a completely reasonable and moral choice of action as they are not designing for those requirements, so it is totally reasonably to use different standards on less important things.

[1] https://news.ycombinator.com/item?id=25919235

[2] https://github.com/sudo-project/sudo/graphs/contributors

[3] https://xkcd.com/2347/

[4] https://xkcd.com/2030/

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

#103

Post by lucb1e » Wed, Dec 01, 2021, 9:11 PM UTC

masklinn wrote: post #26

jandrese wrote: post #14

Earlier quoted context omitted.

The same way you would write code written in 2021 over to Rust: by rewriting it from the ground up. Auto-translation won't work because Rust won't allow you to build it in the same way you would have built it in C. It requires a full up redesign of the code to follow the Rust development model.

> Auto-translation won't work because Rust won't allow you to build it in the same way you would have built it in C. That is not entirely true, but if you translate the C code to Rust, you get C code, in Rust, with similar issues (or possibly worse). Of course the purpose would be to clean it up from there on, but it's unclear whether that's a better path than doing the conversion piecemeal by hand. The C2Rust people…

> That is not entirely true, if you translate the C code to Rust, you get C code, in Rust, with similar issues (or possibly worse).

thus it was basically true after all? Like, sure, Rust is turing-complete so you can simulate whatever C did and thus technically you can translate anything that C can do into Rust. But if it doesn't fix any problems, then have you really translated it into Rust?

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

#104

Post by ptaq » Wed, Dec 01, 2021, 9:12 PM UTC

slownews45 wrote: post #77

JulianMorrison wrote: post #53

Earlier quoted context omitted.

Go has no "unsafe" keyword and several parts of the language are unsafe, you're thinking of Rust which has much tighter guarantees. Go idioms, like accepting data into buffers that are resized by "append", work around the unsafe parts of the language.

Go has an unsafe package. Is there an example of even "bad" go code that gets you from a overflow to an exploit? I'm curious, folks (usually rust folks) do keep making this claim, is there a quick example?

You can totally do this with bad concurrency in Go: read-after-write of an interface value may cause an arbitrarily bad virtual method call, which is somewhat UB. I am not aware of single goroutone exploits, though.

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

#105

Post by lucb1e » Wed, Dec 01, 2021, 9:13 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.

I guess the ecosystem that might make a language attractive was not built overnight. I'm not sure looking at the popularity since an initial release is the best way to measure how good a language is for a particular purpose.

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

#106

Post by nullityrofl » Wed, Dec 01, 2021, 9:15 PM UTC

Veserv wrote: post #102

lucb1e wrote: post #8

A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…

How do you know that it was actually "extremely well-maintained"? Everybody thought OpenSSL was well-maintained since it was used as critical infrastructure by multi-billion dollar megacorporations, but it was actually maintained by two full-time employees and a few part-time volunteers with maybe a quick once-over before a commit if they were lucky. How about sudo, a blindly trusted extremely sensitive program [1],…

Tavis explains clearly why he thinks it's well maintained in the post, complete with linkages to source code. To paraphrase:

[...] NSS was one of the very first projects included with oss-fuzz [...]

[...] Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. [... all links to evidence ...]

Did Mozilla have good test coverage for the vulnerable areas? YES.

Did Mozilla/chrome/oss-fuzz have relevant inputs in their fuzz corpus? YES.

Is there a mutator capable of extending ASN1_ITEMs? YES.

I don't think at any point anyone assumed anything.

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

#107

Post by criddell » Wed, Dec 01, 2021, 9:16 PM UTC

gostsamo wrote: post #78

criddell wrote: post #31

Earlier quoted context omitted.

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

Actually, we are talking the creators of rust here. The same guys who were owning it with the idea to rewrite the entire browser in it. The more plausible reason might be that the rewrite to rust haven't advanced to this component yet.

Yeah, that could be. I was speaking about the wider development ecosystem. Rust is doing well in a few places and that's enough for it to survive and exist long term, or at least as long as Mozilla is relevant.

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

#108

Post by [deleted] » Wed, Dec 01, 2021, 9:18 PM UTC

JulianMorrison wrote: post #53

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 has no "unsafe" keyword and several parts of the language are unsafe, you're thinking of Rust which has much tighter guarantees. Go idioms, like accepting data into buffers that are resized by "append", work around the unsafe parts of the language.

[deleted]

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

#109

Post by cjg » Wed, Dec 01, 2021, 9:19 PM UTC

steveklabnik wrote: post #86

jtchang wrote: post #75

Earlier quoted context omitted.

I'd like to write go or rust but embedded constraints are tough. I tried and the binaries are just too big!

The smallest binary rustc has produced is 138 bytes. It is true that it’s not something you just get for free, you have to avoid certain techniques, etc. But rust can fit just fine.

Do you have a link to an article / report about that 138 byte program? I'd be interested how to achieve that.

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

#110

Post by masklinn » Wed, Dec 01, 2021, 9:19 PM UTC

lucb1e wrote: post #103

masklinn wrote: post #26

Earlier quoted context omitted.

> Auto-translation won't work because Rust won't allow you to build it in the same way you would have built it in C. That is not entirely true, but if you translate the C code to Rust, you get C code, in Rust, with similar issues (or possibly worse). Of course the purpose would be to clean it up from there on, but it's unclear whether that's a better path than doing the conversion piecemeal by hand. The C2Rust people…

> That is not entirely true, if you translate the C code to Rust, you get C code, in Rust, with similar issues (or possibly worse). thus it was basically true after all? Like, sure, Rust is turing-complete so you can simulate whatever C did and thus technically you can translate anything that C can do into Rust. But if it doesn't fix any problems, then have you really translated it into Rust?

> thus it was basically true after all?

No?

> Like, sure, Rust is turing-complete so you can simulate whatever C

It's not simulating anything, and has nothing to do with turing completeness.

> But if it doesn't fix any problems, then have you really translated it into Rust?

Yeees? Unless your definition of "translated" has nothing to do with the word or the concept.

You end up with a project full of rust code which builds using rust's toolchains. That sounds like a translation to me.