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

401–410 of 499 posts

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

#401

Post by lelanthran »

kobebrookskC3 wrote: post #394
lelanthran wrote: post #388

Earlier quoted context omitted.

> a product can be valuable without being worth attacking, like something that only runs on trusted inputs. the bar for software "worth attacking" for me is that there are people who are paid to find exploits on it. I'm in agreement, but then we get back to the fact that memory safety may not be a compelling argument to use a new language. After all, most products aren't "worth attacking" until they are large and suc…

why is the "payment processing" software written in c/c++ and not something like java in the first place? i would imagine not needing to care too much about memory would speed up development velocity. was it before java became popular? i can understand the munitions control software possibly running on a constrained device and not needing very sophisticated memory management (cue the old joke about the "ultimate in g…

> why is the "payment processing" software written in c/c++ and not something like java in the first place?

Until recently[1] payment terminals were memory constrained devices. Even right now, a significant portion of payment terminals are constrained (128MB of RAM, slow 32-bit processors).

Even though Java was around in 2006, the payment terminals I worked on then ran on 16-bit NEC processors (8088, basically).

Even if we aren't looking payment terminals (or any of the intermediaries), there's still a large and not-insignificant class of devices for which anything but C or a reduced set of C++ is possible. Having common libraries (zip, tls, etc) written in C means that those libraries are usable on all devices from all manufacturers.

[1] The industry-wide trend right now is a move towards android-based terminals. While this does mean that you can write applications in Java and Kotlin for these terminals, it's still cheaper to port the existing C or C++ codebase to Android and interface via JNI, as that reduces the costs (of which certification is a significant minority).

Even right now, there is more portability in writing the EMV transaction logic in plain C because then it can be used from almost anywhere. A team that went ahead and wrote the core payment acquisition logic in Java would find themselves offering a smaller variety of products and will soon get beaten in the market by those manufacturers who packaged the logic up into a C library.

Don't underestimate how price-sensitive embedded consumers are. A savings of a few dollars per product can absolutely lead to a really large leg up over the competition.

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

#402

Post by galangalalgol »

jmull wrote: post #167
rfoo wrote: post #71

Earlier quoted context omitted.

That's because these are "lessons learned" for how to catch these bugs, instead of "how to write more secure code". Because you can't.

You catch the bug by flagging the use of memcpy instead of something that takes the dest buffer size (like memcpy_s or whatever). It seems to me linters have been flagging this kind of thing since forever. This code is using a wrapper, "PORT_memcpy", so a default ruleset isn't going to flag it. So here I guess no one noticed PORT_memcpy == memcpy (or maybe noticed but didn't take the initiative to add a lint rule or…

was no one linting the wrapper? the static analysis tools we use wouldn't like memcpy_s either. It would create a finding to use an stl container probably.

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

#403

Post by titzer »

nineteen999 wrote: post #300
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 .

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 written to be respectful, yours clearly wasn't. I'll politely point you Niklaus Wirth's work on Oberon as just one example of a giant blind spot in the popular consciousness. Once you learn a bit more about the many, many other systems that were built over the years, you can stop spreading a false narrative of heroism and supremacy.

> The answer will be: these people aren't doers - they are talkers.

Ok, now I am thoroughly done with your comment. Niklaus Wirth was anything but a "talker". Look what was built with Oberon and tell us more about how he was a "talker".

It's OK to not know things. But striking out in profound ignorance is completely unnecessary.

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

#404

Post by pornel »

jstimpfle wrote: post #193
pornel wrote: post #157

Earlier quoted context omitted.

The C ABI will outlive C, like the term "lingua franca" outlived the Franks. Pretty much every other language has support for the C ABI.

One complication is that it's not just about ABIs but at least as much about APIs. And C headers often make some use of the preprocessor. Usage of the preprocessor often even is part of the API, i.e. APIs expose preprocessor macros for the API consumer. Zig has a built-in C compiler and supposedly you can just "include " from within a Zig source file. Rust has a tool called bindgen. There are other tools, I haven't t…

The Windows meta-API thing is done: https://lib.rs/windows

We'll probably continue using C headers as a poor ABI definition format, even without writing programs in C. Sort-of like JSON used outside of JavaScript, or M4 known as autoconf syntax, rather than a standalone language.

But C headers as an ABI definition format are overcomplicated and fragile (e.g. dependent on system headers, compiler-specific built-in defs, and arbitrary contraptions that make config.h), and not expressive enough at the same time (e.g. lacking thread-safety information, machine-readable memory management, explicit feature flags, versioning, etc.).

So I think there's a motivation to come up with a better ABI and a better ABI definition format. For example, Swift has a stable ABI that C can't use, so there's already a chunk of macOS and iOS that has moved past C.

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

#405

Post by nineteen999 »

Chris2048 wrote: post #397
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…

> wonder why all the Lisp and Haskell programmers .. didn't get off their asses I'm sure all these things exist in these languages, totally unused.

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.

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

#406

Post by Chris2048 »

nineteen999 wrote: post #405
Chris2048 wrote: post #397

Earlier quoted context omitted.

> wonder why all the Lisp and Haskell programmers .. didn't get off their asses I'm sure all these things exist in these languages, totally unused.

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.

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

#407

Post by pornel »

steve_adams_86 wrote: post #274
mjw1007 wrote: post #24

I think the main surprising thing here is that people are putting smallish arbitrary limits on the sizes of inputs that they let their fuzzer generate. With the benefit of a little hindsight, that does feel rather like saying "please try not to find any problems involving overflows".

I agree. I haven’t done a lot of fuzzing, but my understanding is that this is how fuzzing can be helpful. Am I wrong? Or is it more complicated than that?

It's a trade-off. Larger input files may slow the fuzzing process, and therefore explore less of the problem space. You usually want to test many different kinds of inputs, not just more of the same.

OTOH file formats often include sizes of fields, which a fuzzer will set to arbitrarily high values. This tests (some) handling of overly large inputs without files being actually that large.

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

#408

Post by account42 »

thrdbndndn wrote: post #35

Kinda tangent, but when I was browsing NSS' repo ( https://hg.mozilla.org/projects/nss or mirror: https://github.com/nss-dev/nss/commits/master ) I found that the latest commit has a much older date (7 weeks ago) than the following ones. Why is that? (Sorry I don't know much about git other than push/pull.)

To expand on what others have said, the date shown is when the change was authored, which is not neccesarily the date when the commit object was created.

In open source collaborative development, pathes are usually shared either old-style on mailing lists or review software (phabricator in this case it seems) as patches which include a date and then only applied in the repo once they are reviewed.

You can also get non-monotonic authorship dates without leaving a git repo (and without manually overriding the date) by cherry-picking or rebasing commits onto different branches.

Also, the first link is not a git repository but a mercurial one.

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

#409

Post by nineteen999 »

Scramblejams wrote: post #362
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 Not to take away from what they've shipped, but it bears repeating that they are also, generally, profligate writers of severe security holes. Some of the most expert programmers in the world have created mighty CVEs. There's a school of thought that it's a poor craftsman who blames his to…

Agree there is a problem. Now step up to the plate, and fix it.

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

#410

Post by nineteen999 »

FeepingCreature wrote: post #333
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 this is fair. First-mover advantage is absolutely a thing at the ecosystem level.

There were plenty of first movers before UNIX and C, and later C++. They didn't stick. Now, step up to the plate and fix it.
Post reply on HN