
Oracle to issue huge security patch addressing 36 Java vulnerabilities - dsl
http://www.theinquirer.net/inquirer/news/2322481/oracle-to-issue-huge-security-patch-addressing-36-java-vulnerabilities
======
JohnTHaller
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.

------
pudquick
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
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...](https://blogs.oracle.com/java-platform-
group/entry/new_security_requirements_for_rias)

~~~
0x0
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?

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

~~~
0x0
It's a shame if poorly written applets end up being signed cluelessly.

At least the sandbox used to prevent accidents, if not malicious code. Plenty
of things like "lights-out" server admin tools seem to ship with semi-dodgy
applets for KVM stuff etc.

------
jgalt212
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
So you rather use the ActiveX plugin instead?!

Talk about security.

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

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

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

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

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

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

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

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

It is all relative

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

~~~
taspeotis

        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.

~~~
waps
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".

~~~
cma
So basically, if someone browses to a site with an applet and doesn't block
Java.

~~~
taspeotis
I wouldn't call that a remote exploit.

~~~
tptacek
Unlike the whole software security industry, which does.

~~~
taspeotis
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 running the code for you on their machine, it's local. If
I send a malformed JPG to a Java webservice that process images, and it
doesn't process the JPG correctly leading to code execution or a DoS then
that's remote.

[1]
[http://en.wikipedia.org/wiki/Exploit_(computer_security)](http://en.wikipedia.org/wiki/Exploit_\(computer_security\))

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

~~~
brazzy
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?

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

