Live data from Hacker News

Oracle to issue huge security patch addressing 36 Java vulnerabilities

theinquirer.net

21–30 of 38 posts

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#21
post #14

Earlier quoted context omitted.

Unlike the whole software security industry, which does.

I don't work in the software security industry like you but I don't see how it's a remote exploit. Wikipedia gives a way of discerning the two [1] that makes sense to me, as a software security industry layperson: > Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote). So if a user starts…

I agree, it's a local exploit, not a remote exploit (I've debated this with people as well), but in the end Java sandbox bypass exploits are (or were) the most effective local exploit possible. And they're arguably far more valuable than the vast majority of remote exploits out there.

Silent, cross-browser, cross-platform; browser plugin installed by default with anyone who has Java. And that's a huge number of people, since a ton of corporate and residential users have Java installed on all sorts of devices. Java is responsible for a massive ramp up in infections of computer literate and illiterate users alike between 2010 and now.

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#24

Does anyone know if this is the infamous 7u51 which will disable unsigned applets from running AT ALL in a browser? (Yes, I know about the whitelist jar)

It is, this one raises the security baseline. In case you need to make applets compatible with 7u51 take a look at https://blogs.oracle.com/java-platform-group/entry/new_secur...

So now all applets will have to be signed, and users will be trained to accept running the signed applets with that horrible GUI for confirming it. Did you know that popup about running a signed applet also confirms you're OK with running the applet outside the sandbox?

So from now on, all applets will by default run outside the sandbox? How is this an improvement?

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#25

Earlier quoted context omitted.

I don't work in the software security industry like you but I don't see how it's a remote exploit. Wikipedia gives a way of discerning the two [1] that makes sense to me, as a software security industry layperson: > Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote). So if a user starts…

I agree, it's a local exploit, not a remote exploit (I've debated this with people as well), but in the end Java sandbox bypass exploits are (or were) the most effective local exploit possible. And they're arguably far more valuable than the vast majority of remote exploits out there. Silent, cross-browser, cross-platform; browser plugin installed by default with anyone who has Java. And that's a huge number of peopl…

An interesting aspect of the whole Java pluigin fiasco is that, as you write, there were very few exploits until a couple of years ago - but the plugin was widely deployed for over a decade before that, and there is no reason to believe that it was somehow more secure before. So why the recent increase?

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#26
post #24

Earlier quoted context omitted.

It is, this one raises the security baseline. In case you need to make applets compatible with 7u51 take a look at https://blogs.oracle.com/java-platform-group/entry/new_secur...

So now all applets will have to be signed, and users will be trained to accept running the signed applets with that horrible GUI for confirming it. Did you know that popup about running a signed applet also confirms you're OK with running the applet outside the sandbox? So from now on, all applets will by default run outside the sandbox? How is this an improvement?

It's an improvement because all applets will by default not run at all, and most users don't need to use any applets and thus will not in fact be trained to agree to run applets.

Basically, it acknowledges that the Java sandbox is as leaky as a sieve and that securitywide, running an applet not much different from downloading and running a regular executable file, so you should only do it if you trust the source.

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#27
post #25

Earlier quoted context omitted.

I agree, it's a local exploit, not a remote exploit (I've debated this with people as well), but in the end Java sandbox bypass exploits are (or were) the most effective local exploit possible. And they're arguably far more valuable than the vast majority of remote exploits out there. Silent, cross-browser, cross-platform; browser plugin installed by default with anyone who has Java. And that's a huge number of peopl…

An interesting aspect of the whole Java pluigin fiasco is that, as you write, there were very few exploits until a couple of years ago - but the plugin was widely deployed for over a decade before that, and there is no reason to believe that it was somehow more secure before. So why the recent increase?

I think it is a combination of third party bug bounty programs (ZDI, etc) which is causing vulnerabilities to be disclosed to the vendor and the blood in the water effect.

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#29
We really need to implement the missing functionality Java applets are providing in plain JS, so applets can die. The last time i absolutely had to implement an applet was to provide my client with this functionality that was not available with pure JS:

- direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fine grained printer control.

- serial/parallel/usb access: access to a POS for card processing, and we needed to write some data on a smartcard.

- plain TCP connections

- read/write files on the local filesystem.

I understand that all these features require more control of the underlying hardware and need to be somehow secured, but we did not want to write a desktop app just for these features, and applets gave us the means to implement what the user needed. Once JS can do that, applets can die a quick dead.

Re: Oracle to issue huge security patch addressing 36 Java vulnerabilities

#30

We really need to implement the missing functionality Java applets are providing in plain JS, so applets can die. The last time i absolutely had to implement an applet was to provide my client with this functionality that was not available with pure JS: - direct access to printer: the user wanted to print on a specific tray of the printer, without selecting it every time. JS only implements window.print() with no fin…

Out of curiousity, why did it have to run in the browser?
Post reply on HN