Oracle to issue huge security patch addressing 36 Java vulnerabilities

http://www.theinquirer.net/inquirer/news/2322481/oracle-to-issue-huge-security-patch-addressing-36-java-vulnerabilities

by dsl • 13 years ago

40 36 13 years ago

waps2• 13 years ago

Please note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break. The only thing this allows you to do is to break out of the java sandbox, and keep in mind that most languages don't even pretend that sandbox isolates code (e.g. python/perl/go/... all openly say you can easily break out of the sandbox). So they're trying to solve a really hard problem.

taspeotis3• 13 years ago

    Please note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break

I can't reconcile this with the article.

    ...34 that are bugs that can be exploited remotely by an attacker without requiring authentication

By "your code" do you mean "Java-based application"? Honest question.

waps2• 13 years ago

I mean that these bugs only solve the "break out of the sandbox" issue. They do not get your code on to the machine to exploit.

In other words these flaws are the equivalent of "I can upload code, how do I get to shell access to the java account".

tptacek4• 13 years ago

They are indeed trying to solve a hard problem, and they're shackled to a 1990s design.

But I'm not sure I understand the rest of your comment. The threat model for a Java plugin vulnerability is, if your target has the Java plugin enabled, they can't safely browse the web; any page they visit could end up redirecting them to a page with a malicious applet. That's pretty bad.

InclinedPlane• 13 years ago

This is a very disingenuous way of describing the risk of drive by exploits in the browser.

beedogs• 13 years ago

What an utter mess Java is. You'd think after 20 years they'd have this sorted out by now.

tptacek4• 13 years ago

You mean, what an utter mess the Java Applet Plugin is. And it is, but keep in mind that the Java team signed up for a world of hurt: they produced a design whose attack surface is an entire programming language, complete with networking and a user interface toolkit and all the timers, retention cycles, native code bindings, and other junk that comes with it.

Surely there are several bugs here that aren't specific to the Applet Plugin, but their impact is probably minimal outside of the plugin.

jgalt2122• 13 years ago

Let's say this update does everything advertised and more, the perception remains that Java is just not usable in the browser--it's just too dangerous.

Away from testing purposes, the only reason we use IE in the office is so that we can use Webex without Java.

pjmlp• 13 years ago

So you rather use the ActiveX plugin instead?!

Talk about security.

jgalt2122• 13 years ago

Is ActiveX more dangerous than Java applets? If so, that's news to me, but I'm all ears.

hershel• 13 years ago

I think bromium.com includes a hw-virtualization option that enables one to use java in the browser safely.

pudquick• 13 years ago

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)

rickette• 13 years ago

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

0x02• 13 years ago

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?

JohnTHaller• 13 years ago

For context, Java will not run by default in any of the 3 major web browsers. In Firefox, it uses Click to Play, requiring you to click on the plugin to load it. In Chrome and IE, it will present a permissions box asking you for permission to run the applet that you can deny.

gojomo• 13 years ago

And then, finally, Java will be secure. Right?

mragab• 13 years ago

No system/platform is 100% secure, and Java is no exception

It is all relative

y0ghur7_xxx3• 13 years ago

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.

Joister2• 13 years ago

Out of curiousity, why did it have to run in the browser?

y0ghur7_xxx3• 13 years ago

Why not? - "we did not want to write a desktop app just for these features"

skybrian• 13 years ago

Why not an HTTP server running on localhost that provides these things?

y0ghur7_xxx3• 13 years ago

Yes, we thought of that too, but the installation of the server on every client was a lot more work than writing an applet. But it was a valid alternative if the clients using the app where few.

Oracle to issue huge security patch addressing 36 Java vulnerabilities

Related Stories