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

411–420 of 499 posts

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

#411

Post by nineteen999 »

titzer wrote: post #403
nineteen999 wrote: post #300

Earlier quoted context omitted.

No issue with the first sentence of your message at all, but... > 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. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

> We will understand that those people are the ONLY ones that stepped up to the task over 50 years to write this kind of software, organize standards bodies for their languages and platforms, get their software packaged as part of mainstream operating systems and out into the world, deal with patches from users, and help millions of other people make a living, enable the internet to happen, etc. While my comment was…

This comment misses the point so far as to be completely unnecessary.

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

#412

Post by nineteen999 »

Chris2048 wrote: post #406
nineteen999 wrote: post #405

Earlier quoted context omitted.

I actually agree with you - in many cases, I am sure they do. But are they complete, and usuable enough in production? Did they ever acquire enough mindshare? Did they get enough buy in? The clear answer is no.

Mindshare and buy-in might be an issue of the ecosystem though. Not enough lisp/Haskell devs.

Maybe thats because while those languages solve particular problem, they, or their proponents aren't solving the particular problems at hand.

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

#413

Post by nineteen999 »

oblio wrote: post #383
renewiltord wrote: post #355

Earlier quoted context omitted.

Lmao. Absolute perfection. Software that exists has way more value.

Not when that software and the ecosystem around it, which are entrenched, actively fight against change. If you think that's not true, C++ programmers, raise your hand if you were ever working on/contributing to a C program and you proposed C++ as a safer/better language and got shot down. So even C++ is facing the same kind of challenges now faced by newer programming languages.

> So even C++ is facing the same kind of challenges now faced by newer programming languages.

Couldn't agree more with this.

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

#414

Post by albntomat0 »

sangnoir wrote: post #280
albntomat0 wrote: post #149

Since this comes up whenever there is a Project Zero article, here is a summary I made in summer 2020 on the distribution of the bugs they find/report: Since this always comes up, here's an overview I made several weeks ago about where Project Zero focuses their efforts: All counts are rough numbers. Project zero posts: Google: 24 Apple: 28 Microsoft: 36 I was curious, so I poked around the project zero bug tracker t…

> I made several weeks ago about where Project Zero focuses their efforts Are you sure the numbers track where they put effort? I can think of a couple of confounding factors (including P0 methodologies, and number of low-hanging[1] bugs in target products) 1. Relatively speaking

I absolutely agree that there are numerous reasons why the numbers are not equal.

My sole reason for posting is the "P0 is a hit squad against Apple/Mozzilla/Microsoft" comments that come up whenever their blog posts end up on HN.

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

#415

Post by nineteen999 »

flohofwoe wrote: post #391
KronisLV wrote: post #364

Earlier quoted context omitted.

> C/C++ people may not always be the sharpest tools in the shed, and they may be a dime a dozen. I feel like you're not entirely serious about it, but i'm not sure about the premise of that statement. To me, it feels like C/C++ has a barrier of entry that's significantly higher than that of other languages: e.g. everything from JavaScript and Python to those like .NET and Java. Wouldn't that mean that it'd be easier…

> C/C++ has a barrier of entry that's significantly higher than that of other languages Especially in this context it's important to mention that C and C++ are actually very different languages ;)

No, its actually absolutely irrelevant to the argument.

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

#416

Post by nineteen999 »

native_samples wrote: post #398
nineteen999 wrote: post #300

Earlier quoted context omitted.

No issue with the first sentence of your message at all, but... > 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. We won't wonder at all. We will understand that those people are the ONLY ones that stepped up to the task o…

I don't think that's actually true. I think it's rather than the market rewards performance above security. Let's see: is there a mature, maintained TLS stack written in a memory-safe, high performant, cross platform language that Mozilla could have been using for free, instead of NSS? Your argument is that there isn't one because only C++ coders are "doers" instead of "talkers" but this argument is wrong because suc…

Technobabble.

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

#417

Post by pornel »

scoutt wrote: post #396
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++.

Please.... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust I read "double free", "denial of service", "out-of bounds read", "NULL pointer dereference", etc... And that's a list of vulnerabilities found for a language that is barely used compared to C/C++ (in the real world). It won't change. C/C++ dominates and will dominate for a very long time.

You need to read the list more carefully.

• The list is not for Rust itself, but every program ever written in Rust. By itself it doesn't mean much, unless you compare prevalence of issues among Rust programs to prevalence of issues among C programs. Rust doesn't promise to be bug-free, but merely catch certain classes of bugs in programs that don't opt out of that. And it delivers: see how memory unsafety is rare compared to assertions and uncaught exceptions: https://github.com/rust-fuzz/trophy-case

• Many of the memory-unsafety issues are on the C FFI boundary, which is unsafe due to C lacking expressiveness about memory ownership of its APIs (i.e. it shows how dangerous is to program where you don't have the Rust borrow checker checking your code).

• Many bugs about missing Send/Sync or evil trait implementations are about type-system loopholes that prevented compiler from catching code that was already buggy. C doesn't have these guarantees in the first place, so in C you have these weaknesses all the time by design, rather than in exceptional situations.

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

#418

Post by moring »

rhdunn wrote: post #350
moring wrote: post #299

Earlier quoted context omitted.

FWIW, this does not match my experience. I have caught lots of bugs with unit tests, especially in code that is fundamentally complex (because it does complex things, not because it needs polishing). OTOH, refactorings often span units because real simplification comes from changing the ways units interact, or even which units exist, so the tests have to be changed anyway. Granted, even tests that have to be changed…

If you are writing tests to check new code in tandem with writing that code (either via TDD, or some other code-test loop), or are writing tests for existing code, you can (and usually will) find and fix bugs. Likewise if you are investigating a problem and write one or more test cases to check the behaviour. Once those tests have been written, then they act as regression tests like the parent comment notes. On "unit…

To clarify, when I wrote "the ways units interact", I was referring to units that represent external dependencies in some kind (often a database, as you said). Many refactorings change those interactions in some way.

I agree that there is no reason to mock data containers or other classes with fully self-contained behaviour.

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

#419

Post by gpderetta »

CJefferson wrote: post #378
lenkite wrote: post #309

Earlier quoted context omitted.

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.

-D_GLIBCXX_ASSERTIONS

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

#420

Post by criddell »

kobebrookskC3 wrote: post #374
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…

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

Yeah, it's weird. I really don't know why Rust isn't more popular.

Edit: I just read another comment you made about somebody's program not being worth attacking. I think you are on to something with that argument. Most software isn't worth attacking.

Post reply on HN