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

371–380 of 499 posts

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

#371

Post by davedx »

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.

Indeed. This is why I find 100% unit test coverage can actually be harmful: it gives you an illusion of safety.

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

#372

Post by lelanthran »

Ar-Curunir wrote: post #294
criddell wrote: post #145

Earlier quoted context omitted.

Languages take off broadly because there's something compelling about them (and it isn't necessarily a technical reason). One of most compelling reasons for adopting Rust is memory safety and that may not be terribly compelling. The comment about it being over a decade old was mostly that it wasn't some new thing that people are unsure about where it can be used. It's mature and has been successful in some niches (an…

How is memory safety not a compelling argument when we're literally in a thread about memory unsafety leading to security exploits?

> How is memory safety not a compelling argument when we're literally in a thread about memory unsafety leading to security exploits?

The ratio of { memory-safety-bugs-in-code : bugs-in-code } is too small in many cases to warrant redoing the entire project.

My last C (and C++) role: over the course of 3 years, a large C++ project had over 1000 bug reports closed, of which one turned out to be a memory safety issue that would have been prevented in Rust. My previous C position had a similar rate.

It's hard to convince the company to throw a 5-person team at a rewrite project for 3 years just to avoid the bug that they got in the previous 3 years, in the process incurring new bugs.

If you're the owner of a company, you'd dismiss anyone who tells you that you need to spend a few million redoing work already completed, with additional risk that the redone work will have new errors that were already fixed in the existing work.

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

#373

Post by kobebrookskC3 »

unobatbayar wrote: post #337
ransom1538 wrote: post #120

Earlier quoted context omitted.

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++ is awesome and fast, don't blame it for human error.

when "human error" happens at a much higher rate than the alternatives, it's fair to blame it.

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

#374

Post by kobebrookskC3 »

criddell wrote: post #145
sophacles wrote: post #119

Earlier quoted context omitted.

I don't understand your argument. In 1982 C was a decade old and still very niche. In 1992 C++ was a decade old and still very niche. In 2002 Python were both about a decade old and very niche. In 2005 Javascript was a decade old and still very niche (only used on some webpages, the web was usable without javascript for the most part). I think it's safe to say that all of them went on to enjoy quite a bit of success/…

Languages take off broadly because there's something compelling about them (and it isn't necessarily a technical reason). One of most compelling reasons for adopting Rust is memory safety and that may not be terribly compelling. The comment about it being over a decade old was mostly that it wasn't some new thing that people are unsure about where it can be used. It's mature and has been successful in some niches (an…

idk, many large companies report about 70% of their security issues are due to memory unsafety. reducing your security bugs by a factor of 3 sounds pretty compelling to me...

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

#375

Post by kobebrookskC3 »

lelanthran wrote: post #372
Ar-Curunir wrote: post #294

Earlier quoted context omitted.

How is memory safety not a compelling argument when we're literally in a thread about memory unsafety leading to security exploits?

> How is memory safety not a compelling argument when we're literally in a thread about memory unsafety leading to security exploits? The ratio of { memory-safety-bugs-in-code : bugs-in-code } is too small in many cases to warrant redoing the entire project. My last C (and C++) role: over the course of 3 years, a large C++ project had over 1000 bug reports closed, of which one turned out to be a memory safety issue t…

your code probably isn't worth attacking

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

#376

Post by Quekid5 »

josephg wrote: post #278
16bytes wrote: post #270

Earlier quoted context omitted.

I'm also really skeptical that one could maintain 1K/lines per day for more than a couple weeks if that. There have been a lot of studies that measure average output of new code at only ~15 or so LOC/day. One can manage more on small projects for a short amount of time. I could believe porting between two C-like languages is 1 order of magnitude easier, but not 2. Std library differences, porting idioms, it adds up.…

I'd love to see some data about that. Even anecdotal experiences - I can't be the only one here who's ported code between languages. I agree with that LOC/day output figure for new code. I've been averaging somewhere around that (total) speed for the last few months - once you discard testing code and the code I'll end up deleting. Its slower than I usually code, but I'm writing some very deep, new algorithmic code.…

> I have no idea how that porting speed would translate to a larger project

IME it doesn't.

I'm not at liberty to discuss all that much detail, but I what I can say is: This was a mixture of C and C++ -> Scala. This was pretty ancient code which used goto fairly liberally, etc. so it would often require quite a lot of control flow rewriting -- that take a looooong time. I'd be lucky to get through a single moderately complex multiply nested loop per day. (Scala may be a bit of an outlier here because it doesn't offer a c-like for loop, nor does it offer a "native" break statement.)

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

#377

Post by lelanthran »

kobebrookskC3 wrote: post #375
lelanthran wrote: post #372

Earlier quoted context omitted.

> How is memory safety not a compelling argument when we're literally in a thread about memory unsafety leading to security exploits? The ratio of { memory-safety-bugs-in-code : bugs-in-code } is too small in many cases to warrant redoing the entire project. My last C (and C++) role: over the course of 3 years, a large C++ project had over 1000 bug reports closed, of which one turned out to be a memory safety issue t…

your code probably isn't worth attacking

> your code probably isn't worth attacking

Maybe, maybe not. What bar do you set for "this product is worth attacking"? Because the product owners and the product users definitely thought that their product was valuable[1].

[1]The products in question were 1) Payment acquirer and processor, and 2) Munitions control software.

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

#378

Post by CJefferson »

lenkite wrote: post #309
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 .

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.

The default [] for vector doesn't do bound checking, so I don't feel it helps they much.

One thing in practice I like about Rust over C++ is the "easy option" is safe, and you have to do things like write 'unsafe' to opt out of safety.

Certainly when teaching C++ I wish the defaults were safer. I can teach ".at", but it isn't what you see in most code / tutorials.

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

#379

Post by pjmlp »

blub wrote: post #357
pjmlp wrote: post #342

Earlier quoted context omitted.

> We will wonder why with all the millions of lines of C/C++ reference code available to be perused and then rewritten in Rust, Pascal, C#, Zig or Nim, and the vociferousness of their advocates, why that didn't happen in a reasonable timeframe. Easy, every single time .NET team does some advances into that direction, it gets sabotaged by WinDev and their C++ love. XNA vs DirectXTK, .NET vs COM/WinRT,... Windows could…

Before I ditched Windows a couple of years ago, I was able to experience first hand how bloated and slow was the software that Microsoft rewrote in C#, so I kind of understand why such rewrites were being sabotaged. If by some minor miracle a C# or Java GUI app is not slow, then it will use a ton of memory. A whole OS of such apps would be a nightmare.

As proven by Midori (used to power Asian bing while in development), Android, ChromeOS, iOS/iPad OS, among others, it is possible when everyone works together for a common goal instead of sabotaging others work.

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

#380

Post by lrem »

saurik wrote: post #288
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 .

More strongly: the idea that "fuzzing" is "doing all the right things" is insane and disappointing of a narrative. The code snippets I am seeing here are ridiculous with manual, flag-based error handling? There is a use of something like memcpy that isn't hidden behind some range abstraction that manages all of the bounds?! This code probably is riddled with bugs, because they are doing all the wrong things, and fuzz…

"All the right things" included, according to the actual narrative in the post:

- Extensive non-fuzzing testing.

- Regular static analysis.

- Being actively maintained and overseen by a competent security team, with a bug bounty program on top.

I believe I've also seen mentions of independent security audits outside the post.

Edit: emphasis is on the fuzzing, because that is how the bug was finally discovered.

Post reply on HN