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

131–140 of 499 posts

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

#131

Post by alfalfasprout »

ransom1538 wrote: post #120
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…

Dumb question: Do we need to use C++ anymore? Can we just leave it to die with video games? How many more years of this crap do we need before we stop using that language. Yes I know, C++ gurus are smart, but, you are GOING to mess up memory management. You are GOING to inject security issues with c/c++.

C/C++ is great for AI/ML/Scientific computing because at the end of the day, you have tons of extremely optimized libraries for "doing X". But the thing is, in those use cases your data is "trusted" and not publicly accessible.

Similarly in trading, C/C++ abounds since you really do have such fine manual control. But again, you're talking about usage within internal networks rather than publicly accessible services.

For web applications, communications, etc.? I expect we'll see things slowly switch to something like Rust. The issue is getting the inertia to have Rust available to various embedded platforms, etc.

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

#132

Post by VWWHFSfQ »

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.

nss was also generally considered to be thoroughly vetted though

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

#134

Post by nielsole »

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

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

#135

Post by antod »

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],…

> Everybody thought OpenSSL was well-maintained since it was used as critical infrastructure by multi-billion dollar megacorporations

I wasn't under the impression anybody who knew the project ever really thought that. Some other people may have assumed that as a default if they hadn't looked into it.

This article spells out a whole bunch of reasoning why this particular library was well maintained though. There's a difference between reasoning based on evidence and assumptions.

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

#136

Post by tialaramex »

howdydoo wrote: post #9
edoceo wrote: post #3

Buffer Overflow is a classic right? (queue Rust enthusiasts)

"This shouldn't have happened," says user of the only language where this regularly happens. https://www.theonion.com/no-way-to-prevent-this-says-only-na...

I've been meaning for some time to write one of these (with auto-generation whereas I believe The Onion actually has staff write a new one each time they run this article) for password database loss. [Because if you use Security Keys this entire problem dissipates. Your "password database" is just a bunch of public data, stealing it is maybe mildly embarrassing but has no impact on your users and is of no value to the "thieves"]

But a Rust one for memory unsafety would be good too.

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

#137

Post by duped »

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…

> Or are C/C++ benefits just too high to ever give up?

FFI is inherently memory-unsafe. You get to rewrite security critical things from scratch, or accept some potentially memory-unsafe surface area for your security critical things for the benefit that the implementation behind it is sound.

This is true even for memory-safe languages like Rust.

The way around this is through process isolation and serializing/deserializing data manually instead of exchanging pointers across some FFI boundary. But this has non-negligible performance and maintenance costs.

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

#138

Post by duped »

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.

In a sense, reducing the error case to the physical limitations of a device is a perfectly "optimal" solution

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

#139

Post by rocqua »

ransom1538 wrote: post #120
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…

Dumb question: Do we need to use C++ anymore? Can we just leave it to die with video games? How many more years of this crap do we need before we stop using that language. Yes I know, C++ gurus are smart, but, you are GOING to mess up memory management. You are GOING to inject security issues with c/c++.

If im going to be making code that needs to run fast, works on a bit level, and isn't exposed to the world, then I am picking up C++

It's more convenient than C. It's easier to use (at the cost of safety) compared to Rust.

Perhaps this will change if I know rust better. But for now C++ is where it's at for me for this niche.

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

#140

Post by senderista »

openasocket wrote: post #92
xiphias2 wrote: post #59

Earlier quoted context omitted.

Memory safe language that can compete with C/C++ in performance and resource usage is a new concept. AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead. Rust is really something new.

There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a…

> We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust.

Sorry, that just isn’t the case. It is simple to design an allocator that can detect any double-free (by maintaining allocation metadata and checking it on free), and prevent any use-after-free (by just zeroing out the freed memory). (Doing so efficiently is another matter.) It’s not a language or GC issue at all.

Post reply on HN