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

311–320 of 499 posts

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

#311

Post by fulafel »

josephg wrote: post #207
senderista wrote: post #146

Earlier quoted context omitted.

Then Java is also unsafe by the same standard.

Yes. Java and C# are unsafe by the same standard. Last I checked, they both allow multiple threads to nonatomically modify a raw variable - which can lead to data races and data corruption. I haven't heard of anyone getting RCE out of this class of bug in C# or java though.

JVM semantics[1] don't allow this to corrupt program state arbitrarily, just the data variables in question, right? Whereas in Go.. Search for "corruption" in https://research.swtch.com/gomm

[1] Not just Java, meaning all the many nice JVM languages enjoy this is as well, eg Clojure, Scala etc

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

#312

Post by Woodi »

titzer wrote: post #275
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…

The whole post is a giant blinking red sign that says (or should say) "Fuzzing is a horribly ineffective workaround for a treacherous language." No offense to the many bright and capable people who have worked hard on the C/C++ language, tools, compilers, libraries, kernels, etc over the years, but we will someday look back on it as asbestos and wonder why we kept at it for so damn long .

> but we will someday look back on it as asbestos and wonder why we kept at it for so damn long.

Maybe. But there is good reason for C dominance - it's low level and close to systems as in "syscalls and stuff". And we need that level of systems control, not only for max performance but also for not loosing what is available in hw and os.

Asm is the other option to have full functionality :) Maybe it's just case of available libraries but still C is curently only one option for feature completness. And on low levels all you have is bytes and bits and calls and that allows to do everything with bits, bytes and calls - Core Wars style - and most of languages try to prevent or easy use of that by cutting possibilities, eg. "goto is so nono !11".

And yes, C is not perfect and bullshit even grows, eg. in last years NULL checks are "optimized-out"...

C actually should be improved and not fucked up into forced disuse...

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

#313

Post by trissylegs »

PeterisP wrote: post #111
lucb1e wrote: post #69

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. Is that special? Are there buffer overflow bugs that are not security bugs? It could be just my bubble as a security consultant, since (to me) "buffer overflow" assumes remote code execution is a given. It's not my area of expertise, though, so perhaps indeed not all reachable buf…

As a crude example, there sometimes are off-by-one bugs which allow the buffer to overflow by one byte, and that single overflowing byte is always 0 (the last bye in a zero-terminated string), and it overwrites data in a variable that doesn't affect anything meaningful, giving you a buffer overflow with no security impact.

Although single zero byte overflows are sometimes exploitable.

https://googleprojectzero.blogspot.com/2014/08/the-poisoned-...

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

#314

Post by saagarjha »

slownews45 wrote: post #125
ptaq wrote: post #104

Earlier quoted context omitted.

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.

Concurrency issues / bad program flow feel a bit different don't they? I mean, I can store the action to take on a record in a string in any language, then if I'm not paying attention on concurrency someone else can switch to a different action and then when that record is processed I end up deleting instead of editing etc. I mention this because in SQL folks not being careful end up in all sorts of messed up situati…

It's a different kind of bug–changing the type on a record cannot give you a shell, it can just let you do something funny with the record, such as deleting it. Which is bad, of course, but a bounded bad.

Memory corruption is unbounded bad: in general, corruption is arbitrary code execution. Your program might never interact with the shell but it's going to anyways, because an attacker is going to redirect code execution through the libc in your process. This is just not possible in languages like Java* , which provide details of what kinds of (mis)behaviors are permissible when a race occurs. The list of things is always something like "one of the two writes succeeds" or similar, not "¯\_(ツ)_/¯".

*Barring bugs in the runtime, which do exist…but often because they're written in unsafe languages ;) Although, a bug in runtime written in a safe language will also give you arbitrary code execution…but that's because the job of the code is to enable arbitrary code execution.

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

#315

Post by tannhaeuser »

bee_rider wrote: post #293
Godel_unicode wrote: post #283

Earlier quoted context omitted.

I think you and a sibling comment might be too close to the problem. When heartbleed dropped my Twitter feed had a few crypto engineers saying "I mean, eventually this was going to happen" and a ton of developers whose main language starts with a "p" going "how?? OpenSSL is core plumbing of the internet, it can't be this bad can it???". Edit: to be clear, not maligning the "p" language developers, I was one myself. S…

To be fair, it was unreasonable to expect Prolog coders to keep up with crypto advancements, I mean the language pre-dates SSL by decades.

Care to expand on what Prolog coders have to do with OpenSSL? Not getting the context here.

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

#316

Post by saagarjha »

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…

The jury's out on whether Rust code with unsafe around all of it is better than C. It's good that you can slowly reduce the unsafe, which is not something you can do with C, but the code is frequently harder to read and may have new bugs.

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

#317

Post by saagarjha »

nielsole wrote: post #134

> Issue #2 Arbitrary size limits.[...] > A reasonable choice might be 2^24-1 bytes, the largest possible certificate How does one treat untrusted input whose length might exceed available memory? I am working on a patch for a jwks implementation which does not even have upper bounds in the spec. Accepting any valid input until OOMing seems like a suboptimal solution.

Generally, taint tracking.

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

#318

Post by est31 »

fulafel wrote: post #298
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.

The Ring readme doesn't really cover its functionality but sounds like it may be a lower level crypto lib than NSS? And it also seems to be partly written in C. Anyway, NSS wouldn't necessarily need to be replaced with a Rust component, it could well be an existing lib written in another (possibly GCd) safeish language, or some metaprogramming system or translator that generated safe C or Rust, etc. There might be so…

ring incorporates a barebones ASN.1 parser that also webpki uses, which is probably the crate you want to use if you want to do certificate verification in Rust. webpki is C-free but it does use ring for cryptographic primitives so that will have to be replaced if you don't like ring. More generally, I think Firefox wants to have great control over this specific component so they likely want to write it themselves, or at least maintain a fork.

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

#319

Post by est31 »

DamnableNook wrote: post #268
zacmps wrote: post #179

Earlier quoted context omitted.

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

This sounds like a nightmare for any downstream users of this library. Any one of those bullet points in that section would be a major concern for me using it in anything other than a hobby project, but all of them together seem almost willfully antagonistic to users. This is especially true given it’s a security library, which perhaps more than any other category I would want to be stable, compatible, and free of su…

Note that the readme is outdated. With the upcoming 0.17 release, which is in the making for almost a year already, you can link multiple versions of ring in one executable: https://github.com/briansmith/ring/issues/1268

Similarly, while the policy is still that ring only supports the newest rust compiler version, due to the fact that there has been no update for months already, you can use it with older compiler versions.

Last, the author used to yank old versions of its library, which caused tons of downstream pains (basically, if you are a library and are using ring, I recommend you have a Cargo.lock checked into git). This yanking has stopped since 3 years already, too. Don't think this was mentioned in the readme, but I feel it's an important improvements for users.

So a great deal of things has improved, although I'd say only the first bullet point is a permanent improvement, while the second two might be regressed upon. idk.

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

#320

Post by terinjokes »

elabajaba wrote: post #265
dpifke wrote: post #211

Earlier quoted context omitted.

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

Discord was consistently seeing pauses in the range of several hundred ms every 2 minutes a couple years ago. https://blog.discord.com/why-discord-is-switching-from-go-to...

Hard to say without more details, but those graphs look very similar to nproc numbers of goroutines interacting with the Linux-of-the-time's CFS CPU scheduler. I've seen significant to entire improvement to latency graphs simply by setting GOMAXPROC to account for the CFS behavior. Unfortunately the blog post doesn't even make a passing mention to this.
Post reply on HN