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

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

#301

Post by masklinn » Thu, Dec 02, 2021, 5:53 AM UTC

speed_spread wrote: post #282

titzer wrote: post #275

Earlier quoted context omitted.

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 .

At least Asbestos is inert once in place.

Isn’t asbestos always inert unless you matchmake it to a ridiculously strong oxidiser?

In my recollection it dealt purely physical damage, and its inability to react with much of anything is what leads to its accumulation in dwellings.

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

#302

Post by moring » Thu, Dec 02, 2021, 5:54 AM UTC

a-priori wrote: post #36

jandrese wrote: post #20

Earlier quoted context omitted.

> - "There is an arbitrary limit of 10000 bytes placed on fuzzed input. There is no such limit within NSS; many structures can exceed this size. This vulnerability demonstrates that errors happen at extremes" This is the one that seemed short sighted to me. It's a completely arbitrary (and small!) limit that blinded the fuzzer to this very modest sized buffer overflow.

The problem is that the search space grows (exponentially?) as you increase the fuzzer’s limit. So there’s a cost, and likely diminishing returns, to raising that limit.

Is it possible to feed a fuzzer with information from static analysis to limit the search space? Such as, if you have a check like "someParameter > 0" in the code, have the fuzzer generate a positive, negative, and zero value for someParameter, but not thousands of them -- at least not based on this check alone -- because they will all behave the same.

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

#303

Post by fulafel » Thu, Dec 02, 2021, 5:56 AM 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.

In 2003 you could have generated C from a DSL, for one. Like yacc and lex had been standard practice (although without security focus) since the 80s.

Or generate C from a safe GP language, eg C targeting Scheme such as Chicken Scheme / Bigloo / Gambit.

People have been shipping software in memory safe languages all this time, since way before stack smashing was popularized in Phrack, after all.

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

#304

Post by cozzyd » Thu, Dec 02, 2021, 5:58 AM UTC

titzer wrote: post #281

fleventynine wrote: post #172

Earlier quoted context omitted.

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.

Have you measured the pause times of free()? Because they are not deterministic, and I have met few people who understand in detail how complex it can be in practice. In the limit, free() can be as bad as GC pause times because of chained deallocation--i.e. not statically bounded.

But you can generally control when free is called.

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

#305

Post by saagarjha » Thu, Dec 02, 2021, 6:00 AM UTC

astrange wrote: post #296

eyelidlessness wrote: post #261

Earlier quoted context omitted.

I promise I’m not trying to be obtuse or argumentative, but I think apart from cycles your response restates exactly what I took from my reading on the subject and tried to articulate. So I’m not sure if what I should take away is: - ARC is generally avoided by GC languages, which puts Swift in a peculiar position for a language without manual memory management (without any consideration of Swift per se for the case…

Swift has a similar memory model to Rust, except that where Rust forbids things Swift automatically copies them to make it work. People using other languages appear terrified of reference count slowness for some reason, but it usually works well, and atomics are fast on ARM anyway.

It's important to note that while Swift often allows for code similar to Rust to be written, the fact that it silently inserts ARC traffic or copies often means that people are going to write code that do things that Rust won't let them do and realize after the fact that their bottleneck is something that they would never have written in Rust. I wouldn't necessarily call this a language failure, but it's something worth looking out for: idiomatic Swift code often diverges from what might be optimally efficient from a memory management perspective.

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

#306

Post by bluGill » Thu, Dec 02, 2021, 6:01 AM UTC

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 you drop the parts of C++ that are that way because of C it is a much safer language. Weird and inconsistent, but someone who is writing C++ wouldn't make the error in the code in question any more than they would in rust. In C++ we never is unbounded arrays, just vectors and other bounded data structures.

I often see students asking a C++ question and when I tell then that is wrong they respond that their professor has banned vector. We have a real problem with bad teachers in C++, too many people learn to write C that builds with a C++ compiler and once in a while has a class.

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

#307

Post by saagarjha » Thu, Dec 02, 2021, 6:01 AM UTC

foobiekr wrote: post #269

nicoburns wrote: post #161

Earlier quoted context omitted.

C vulnerabilities do have a nasty habit of giving the attacker full code execution though, which doesn’t tend to be nearly so much of a problem in other languages (and would likely be even less so if they weren’t dependant on foundations written in C)

I don’t disagree with you. But just before writing that message I was code reviewing some python that was vulnerable a to the most basic SQL injection. Who needs or wants execution authority when you can dump the users table of salted sha passwords?

In C you can just use code execution to grab the passwords before they get salted…

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

#308

Post by saagarjha » Thu, Dec 02, 2021, 6:08 AM UTC

asdfasgasdgasdg wrote: post #226

cjbprime wrote: post #122

Earlier quoted context omitted.

Go is sometimes considered memory unsafe because of the presence of data races. (This is a controversial semantics.)

Even in the case of data races, you could not develop an exploit like the one discussed in this blog post, right? It's kinda a non-sequitur in this context?

Go allows data races to arbitrarily corrupt metadata, which is the precursor to an exploit like this. A brief rule-of-thumb is if the race allows you to directly touch data that isn't available via APIs, such as the count on a vector–once you do that, you can "resize" it to be larger than its actual size, and run off the end to do whatever you want. (There are many other ways to achieve something similar: type confusion, etc.)

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

#309

Post by lenkite » Thu, Dec 02, 2021, 6:09 AM UTC

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 .

Is it OK to remove modern C++ from your statement ? Using a `std::vector` wouldn't cause this problem. Don't know why everyone always berates C++ for vulnerabilities in traditional C code.

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

#310

Post by saagarjha » Thu, Dec 02, 2021, 6:09 AM UTC

astrange wrote: post #297

josephg wrote: post #207

Earlier quoted context omitted.

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.

It's common to exploit JavaScript engines with this kind of bug, and JS engines probably have better security teams at this point, so I expect you could get an RCE if you really tried.

Yes, but those would be bugs in the runtime itself, rather than in the programming language. Java and JavaScript both define behavior of racy code; Go does not.