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

391–400 of 499 posts

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

#391

Post by flohofwoe »

KronisLV wrote: post #364
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…

> 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 ;)

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

#392

Post by pjmlp »

flohofwoe wrote: post #389
ptx wrote: post #369

Earlier quoted context omitted.

The new modern/UWP apps in Windows 10, like the calculator and start menu, are written in C++, aren't they? They manage to be horrendously slow and bloated without C#, so maybe C# isn't the problem.

It's quite simple really. Bad programmers (or good programmers in bad environments) are able to write slow code in any language, and the current Windows Desktop team seems to be an example of that.

When people write worse C++ code than naive C# performs, it is really bad.

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

#393

Post by flohofwoe »

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.

People who memcpy bytes into a destination without caring if there's enough room would also not hesitate to use memcpy to copy bytes into a std::vector though.

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

#394

Post by kobebrookskC3 »

lelanthran wrote: post #388
kobebrookskC3 wrote: post #382

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 mainly to find exploits on it, and not just incidentally as a product of development.

> 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 garbage collection").

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

#395

Post by zaptheimpaler »

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…

> But a buffer overflow like from the article? That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert

Both the array length and the index can be computed at runtime based on arbitrary computation/input, in which case doing bounds checks at compile time is impossible.

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

#396

Post by scoutt »

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

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.

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

#397

Post by Chris2048 »

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…

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

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

#398

Post by native_samples »

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…

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 such a stack does exist. It's JCA/JSSE and ships with every OpenJDK.

JCA/JSSE is a full, open source TLS and cryptography stack. It's written, even at the lowest levels, in Java, in which this kind of memory error cannot occur. It's usable from C/C++ via JNI. It's commercially maintained and has been maintained for decades. It keeps up with the latest features. Its performance in the latest versions is comparable to OpenSSL even (not always in the past).

Mozilla could have used it. They could have improved it, even. They've shipped browsers with integrated Java before, in times when computers were much less powerful. They chose not to, why, well, the charitable explanation might be download size or performance, but we could just as easily argue it's because C++ guys don't really care about security. Bugs happen, they ship a fix, people let them off the hook. Eh another buffer overflow, who cares. Not like anyone is going to switch products over that, right?

Reality is, our industry could rewrite lots of software in safer languages and already has. Java has tons of libraries that do the same thing as C++ libraries, and which could be used today. You can shrink HotSpot down to about 7mb compressed, last time I experimented with this, which is like 10% of the size of a typical mobile app. It's just not a big deal. Perhaps the biggest problem is that JNI is an awkward FFI but there are fixes for that also, the new FFI (Panama) is a lot better than the old one.

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

#399

Post by native_samples »

Woodi wrote: post #312
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 .

> but we will someday look back on it as asbestos and wonder why we kept at it for so damn long. Maybe. But there is good reason for C dominance - it's low level and close to systems as in "syscalls and stuff". And we need that level of systems control, not only for max performance but also for not loosing what is available in hw and os. Asm is the other option to have full functionality :) Maybe it's just case of av…

C isn't dominant in a lot of areas of software, obviously.

As for NSS. It's a pure data manipulation library. Algorithms, data structures, not more. It doesn't need to do syscalls and stuff. There's not much benefit to writing it in C and as we just saw, a lot of downsides. It could have been written in many other languages.

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

#400

Post by mid-kid »

throwaway894345 wrote: post #101
jschwartzi wrote: post #90

Earlier quoted context omitted.

Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent month…

EDIT: Just re-read the below and realized it might sound terse and argumentative; apologies, I was typing quickly and didn't mean to be combative. :) > I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy Crumby build systems force you to figure out how to build and install dependencies (or die trying). Modern build systems allow you to figure out how to build and install…

I can't speak for cmake but in autotools it's always just been "./configure --host=aarch64-linux-gnueabi" or whatever other target triplet is of relevance. It's similar in Meson.

The annoying factor is gathering the cross compiler and target dependencies, which is fortunately becoming easier with tools such as llvm/clang, and distros such as debian have always made huge efforts to facilitate it.

Post reply on HN