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

451–460 of 499 posts

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

#451

Post by native_samples »

scoutt wrote: post #442
native_samples wrote: post #398

Earlier quoted context omitted.

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…

Sincerely, as a C/C++ programmer, if I have to start a new project and you propose to link a Java library, it'd give me the creeps. Let's say I agree: does my project now requires to install a Java VM together with my project? Which Java VM? I still don't understand the difference between OpenJDK and the "other one"... JDK? JRE? I only installed it once many years ago because Eclipse CDT required it and I might have…

I think you're making my point for me, no? Your arguments are all variants on "I don't understand modern Java and prefer to keep writing buffer overflows than finding out".

To answer your questions:

1. Java is these days like UNIX, there are lots of "distros". OpenJDK is the upstream on which most of them are based. You can just use that unless you have some particular preference for the other vendors. However the compatibility situation is much better, there aren't any compatibility issues and JVMs are all more or less drop-in replacements for each other (Android is an exception but has got a lot better over time).

2. You don't need to install Java alongside your app. The JVMs is just a library and a few data files. You can easily bundle it with your app and the user will never know.

3. JCA/JSSE is built in to Java so there's nothing to build. Additionally you don't have to build Java libraries to use them anyway, because binary distribution works so everyone just distributes binary JAR files.

4. The source code is spread around several modules because JCA is pluggable. But for example a lot of the crypto code is found here:

https://github.com/openjdk/jdk/tree/master/src/java.base/sha...

5. Oracle maintains it but other companies contribute, like Amazon, Microsoft, Red Hat etc (well, to Java as a whole). It's released under the GPL with Classpath exception license. They aren't going to come after you for using it - there are 12 million Java developers in the world. The only company that has ever got sued is Google and that's because they violated the (at the time non open source) license of Java to make a mobile version that wasn't from Sun. They knew they were doing it and chose to chance it anyway (which worked out quite well for them actually). Since then Java became fully open source and this no longer applies, and it'd have never applied to normal users of it anyway.

I'm not trying to convince you here of anything, only to point out that everyone saying "there was no alternative" is just wrong. The failure mode here is not sufficiently advanced fuzzers. The failure is that there has been an alternative to NSS for years but C++ shops like Mozilla keep maintaining crappy decades old C libraries with memcpy calls all over the place, because they know and like C. That's it. That's all it boils down to.

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

#452

Post by pjmlp »

titzer wrote: post #433
pjmlp wrote: post #426

Earlier quoted context omitted.

One reason why we are getting hardware memory tagging to transform modern computers into basically C Machines, is that everyone kind of gave up doing it at sofware level in regards to C and C++.

Just compile it all to Wasm and we'll run it in virtualization. Give us memory segments back and I think we have a shot of making this a reality.

Except WASM made the big mistake of not having bounds checking on linear memory, so attacks with input data that corrupt internal state and by it try to influence the outcome of WASM modules behaviour are still a good attack vector.

Being sandboxed is good, however if one can start an internal fire from the outside, not so much.

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

#453

Post by pjmlp »

snovv_crash wrote: post #448
pjmlp wrote: post #345

Earlier quoted context omitted.

True, except the code will be tainted and it is easy to find it.

Memory corruption doesn't always trigger segfaults. I don't believe it will be obvious why some random other part of your program will start giving intermittent errors even if it is in Rust.

In Rust, or any other systems programming language with unsafe code blocks, all the way back to JOVIAL and ESPOL, one can search for those code blocks.

At very least they provide an initial searching point.

On C, C++ and Objective-C, any line of code is a possible cause for memory corruption, integer overflow, or implicit conversions that lead to data loss.

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

#454

Post by badpun »

scoutt wrote: post #442
native_samples wrote: post #398

Earlier quoted context omitted.

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…

Sincerely, as a C/C++ programmer, if I have to start a new project and you propose to link a Java library, it'd give me the creeps. Let's say I agree: does my project now requires to install a Java VM together with my project? Which Java VM? I still don't understand the difference between OpenJDK and the "other one"... JDK? JRE? I only installed it once many years ago because Eclipse CDT required it and I might have…

That’s the reason Java is used almost exclusively on servers. None of your pain points (well maybe except Oracle getting litigious) apply there.

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

#455

Post by pjmlp »

blub wrote: post #445
davedx wrote: post #368

Earlier quoted context omitted.

You literally mention Java GUI apps in response to a post that calls out Android, a mobile OS and application ecosystem implemented in Java . The languages are not the issue.

It took Google more than a decade of trying and a VM rewrite to get close to the perceived performance of iOS. And anything performance intensive was done in the NDK anyway. All of this because of Java.

Indeed, the big difference is that Google was willing to put money on the table to make it work.

Those improvements are exactly what WinDev sabotaged in regards to Windows.

Also in case you have forgotten, Objective-C and Swift are also managed languages, check chapter 5 of Garbage Collection Handbook, or any other CS reference in automatic memory management algorithms.

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

#456

Post by [deleted] »

seanhunter wrote: post #338
Godel_unicode wrote: post #283

Earlier quoted context omitted.

I think you and a sibling comment might be too close to the problem. When heartbleed dropped my Twitter feed had a few crypto engineers saying "I mean, eventually this was going to happen" and a ton of developers whose main language starts with a "p" going "how?? OpenSSL is core plumbing of the internet, it can't be this bad can it???". Edit: to be clear, not maligning the "p" language developers, I was one myself. S…

Pascal does predate the era of SSL by some margin to be fair.

[deleted]

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

#457

Post by Godel_unicode »

bee_rider wrote: post #293
Godel_unicode wrote: post #283

Earlier quoted context omitted.

I think you and a sibling comment might be too close to the problem. When heartbleed dropped my Twitter feed had a few crypto engineers saying "I mean, eventually this was going to happen" and a ton of developers whose main language starts with a "p" going "how?? OpenSSL is core plumbing of the internet, it can't be this bad can it???". Edit: to be clear, not maligning the "p" language developers, I was one myself. S…

To be fair, it was unreasonable to expect Prolog coders to keep up with crypto advancements, I mean the language pre-dates SSL by decades.

Don't worry, I told both of them what was going on ;)

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

#458

Post by legulere »

nicoburns wrote: post #161
foobiekr wrote: post #43

Earlier quoted context omitted.

To provide some context for my answer, I’ve seen, first hand, plenty of insecure code written in python, JavaScript and ruby, and a metric ton - measured in low vulnerabilities/M LoC - of secure code written in C for code dating from the 80s to 2021. I personally don’t like the mental burden of dealing with C any more and I did it for 20+ years, but the real problem with vulnerabilities in code once the low hanging f…

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)

SQL or shell command injection also gives attackers full code execution.

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

#459

Post by scoutt »

native_samples wrote: post #451
scoutt wrote: post #442

Earlier quoted context omitted.

Sincerely, as a C/C++ programmer, if I have to start a new project and you propose to link a Java library, it'd give me the creeps. Let's say I agree: does my project now requires to install a Java VM together with my project? Which Java VM? I still don't understand the difference between OpenJDK and the "other one"... JDK? JRE? I only installed it once many years ago because Eclipse CDT required it and I might have…

I think you're making my point for me, no? Your arguments are all variants on "I don't understand modern Java and prefer to keep writing buffer overflows than finding out". To answer your questions: 1. Java is these days like UNIX, there are lots of "distros". OpenJDK is the upstream on which most of them are based. You can just use that unless you have some particular preference for the other vendors. However the co…

> "I don't understand modern Java"

Exactly!

> "and prefer to keep writing buffer overflows than finding out"

Not exactly. I would rather take the risk of writing buffer overflows than using over-bloated infrastructure, being in code size and/or performance, tooling, including learning time. It's a tradeoff. It's always a tradeoff. Mozilla might have had their own reasons, and probably not on a whim. If I have to write the software for an ECU the approach will be different (no, it won't be Java).

I've been in the industry for a long time now (C/C++, mostly embedded). The pattern is the same. This time is you with Java, it might be the Rust/Go crowd , the other 4 users with Ada or the 2 users with FP: everybody loves to hate C/C++ and everybody have their whiteboard reasons, but C/C++ has been pushing the world forward for the last 30 years minimum, and it's not stopping anytime soon. There must be a reason other than "C/C++ programmer are lazy dummies, they prefer to write bugs instead of learning the marvels of [insert random language here], because they are in love with memcpy", don't you think?

The code is there. You can try to link Java JCA/JSSE to Firefox or whatever the project is about. I'm interested in learning how it looks and how it works.

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

#460

Post by terinjokes »

randomswede wrote: post #351
terinjokes wrote: post #320

Earlier quoted context omitted.

Hard to say without more details, but those graphs look very similar to nproc numbers of goroutines interacting with the Linux-of-the-time's CFS CPU scheduler. I've seen significant to entire improvement to latency graphs simply by setting GOMAXPROC to account for the CFS behavior. Unfortunately the blog post doesn't even make a passing mention to this.

Anecdotally, the main slowdown we saw of Go code running in Kubernetes at my previous job was not "GC stalls", but "CFS throttling". By default[1], the runtime will set GOMACSPROCS to the number of cores on the machine, not the CPU allocation for the cgroup that the container runs in. When you hand out 1 core, on a 96-core machine, bad things happen. Well, you end up with a non-smooth progress. Setting GOMACPROCS to…

AFAIK, it hasn't changed, this exact situation with cgroups is still something I have to tell fellow developers about. Some of them have started using [automaxprocs] to automatically detect and set.

[automaxprocs]: https://github.com/uber-go/automaxprocs

Post reply on HN