
US warns on Java software as security concerns escalate - pessimizer
http://www.nbcnews.com/technology/technolog/us-warns-java-software-security-concerns-escalate-1B7938755
======
mixmax
In Denmark we have a state mandated solution for electronically signing
documents and communicating with the state. logging onto public services such
as the IRS, child-care services, motor registration and all sorts of other
stuff is done using this service. In short, if you want to deal with the
government electronically in Denmark you'll have to use this solution. It's
also been adopted by all Danish banks, and is the only alternative for
netbanking. In other words, if you're not a luddite your only choice is to
comply and use this service called NemID (EasyID)

Yes, this runs as a java plugin. And yes the company behind NemID has come out
publicly and said that it shouldn't be a problem, that they don't encourage
users to disable java and that everything is safe.

In other words, if your intent is malicious you can start targeting Danes with
java drive-by downloads, and be fairly sure that if you hit a machine in
Denmark that has the java plugin installed that machine is used for
netbanking.

It's a disaster waiting to happen.

~~~
_delirium
What's strange is that the NemID Java applet doesn't seem to really be doing
anything important. It's just a login box. It takes a username/pwd, and sends
it to the server. The server responds with a query for the 2nd-factor code,
which you look up on your physical NemID card, type in, and it sends it to the
server. If everything matches, you're authenticated. Afaict there's nothing
going on here that couldn't be done by some HTML forms: the two-factor-
authentication magic is done by the server and the paper NemID card (a card
with 148 one-time-use challenge/response codes).

~~~
tragomaskhalos
I suspect a lot of applets are similarly futile - we have a timesheet applet
at work than somehow manages to be clunkier and more annoying in use than
anything you could knock up in plain HTML plus a bit of JavaScript.

------
neya

        "For versions of Java older than Java 7 (which you shouldn't be running anyway), the de-Javafication process for Internet Explorer involves editing the Windows Registry," he notes. "If you don't know what that is, don't do it. Instead, stop using Internet Explorer entirely."
    

Best advice ever.

~~~
nivla
> Best advice ever.

I am not sure how you can construed that as THE best advice given the nature
of the vulnerability being independent of the browser or the o/s in use. It
maybe a good advice but not the best. Something closer to best would be
disabling or uninstalling Java plugin regardless of what operating system or
browser you use.

~~~
neya
Dude, you're taking it too serious. It was meant to be funny. Chillax bro! :D

------
hmottestad
And Norway decided to authenticate people using java applets for government
sites and a separate, but similar, system for online banking. This was quite a
number of years ago, but it still being rolled out on new sites today.

~~~
nkvoll
And their Java applet stops password managers such as LastPass, 1Password etc
from working, and you cannot even copy/paste into its input fields.

I have nothing against Java or the JVM, but applets that require "full access"
to your computer just to sign you in is pretty backwards. To be honest, I
don't trust their code to behave on my computer, but if I don't give their
applet full access, I cannot use my bank online..

I have no idea why they decided to go this route, and why it's not just a 5
minute javascript job to actually fix it.

~~~
martinced
I don't know how often you need to connect to your online bank : I do it once
per week or so...

You could boot a Live Linux CD / DVD / memory stick. Either a Live Linux CD /
DVD which already has Java or add it yourself to the Live CD or keep the Java
install file on a memory stick. Java can be installed without being root on
Linux, which is great and the installation process, once you have the install
file, is very very fast (a few seconds). You could then connect to your bank's
website (and only to that one) and be quite safe.

Of course it's not for the faint of hearth...

But that way you don't need to trust their code to behave well: you're
basically booting a read-only Live CD with zero information about you on it.
And you don't have to fear Java applets exploits from other sites (because you
use that Live CD to go _only_ to your bank's website).

I access my online bank from a Live Linux distro (Java applets aren't needed
here but the principle is the same: by booting from a "read-only OS" and which
I use only for online banking, the risk of being pirated are pretty small).

------
stock_toaster
Maybe this will be the final nail in the coffin of the java browser plugin. I
can only hope...

------
ccdan
Another stupid scare... most idiots will blame the entire set of Java
products, even though applets are just a very minor feat, almost a deprecated
one... and the real threat is greatly exaggerated... there was never a major
security incident in the entire history of java...

~~~
martinced
Back in the early applet days a _lot_ of people were complaining on Usenet's
comp.lang.java.programmer that applets were both a toy and a disaster waiting
to happen that would _never_ bring anything good to Java.

Yet countless Java programmers fought teeth and nails to defend Applets,
saying how great the techno was and how it was going to revolutionize the Web,
etc.

They are the very programmers who, today, say that Java is good but that Java
applets weren't maybe that great after all. It's a bit too easy.

Now I don't know what you call a "major security incident" but in 2011 you
could DoS _any_ Java webserver by crafting an URL (hashtable exploit). A
single customer Internet connection was sufficient to take down entire Java
server farms.

Granted a DoS is not remote-root but still...

Then, still in 2011, there was the 12-years old floating-point parsing bug
where you could DoS _any_ Java web server, again, by sending a thread into an
infinite loop. All that was needed was one parameter set to a certain value on
the client side and make your HTML GET and that's it: one thread into infinite
loop.

Repeat a few times and you had DoS _any_ Java webserver.

It's still not remote root but that's not exactly not major either...

~~~
specialist
Java Applets had great promise. Early interest was high. For the life of me, I
can't phantom how Sun managed to biff this one. I'm among the biggest Java
fans, so my disappointment is acute.

#1 - Netscape. Their Java support always sucked. Broken thread implementation.
The joke was write once debug everywhere. The early troubles soured most and
Sun lost the precious mindshare. Relying on a third party for the success of
Java was a huge mistake.

#2 - Sun killed their HotJava web browser, written in Java. It was the ideal
applet platform. Ran great. Had a great UI for the time. Imagine if they'd
kept that going.

#3 - Sun waited until Java 6, a full decade, to revamp their Java plugin. Way
too late to make a difference.

#4 - AWT controls looked terrible, were too minimal. But Swing was just too
heavy. The design was great for time, being the logical successor to NextStep
-> Cocoa -> Netscape IFC development line. But Sun never put it on a diet,
either the API or the payload.

(Thanks for the floating point parse bug tip. Writing a web server using
Netty, that's a good one to know.)

------
nnq
...jeez ...shouldn't "enterprise grade software" _imply_ at least a "give some
fuck" attitude towards security? wtf is wrong with Oracle?!

Most browsers have an autoupdate mechanism. Can't Oracle encourage browser
devs to push an update with a patched java plugin and Microsoft to push a
windows update with it? I mean, really, wtf?!

~~~
sk5t
Don't go dragging Microsoft into this - they haven't shipped anything Java-
related in a long, long time.

Also, this isn't Slashdot circa 2003, "M$" is quite passé.

~~~
nnq
Ok, ok, I edited the acronym... I was thinking about updating the IE's Java
plugin, and I don't know if it can be done other way than via Windows Update.
I'm so annoyed by the state of Java in the browser because applets are the
only means of running Clojure or Jython or JRuby or your other fav JVM
language in the browser, modifying the DOM and doing whatever you wish without
needing to compile to Javascript. I know, this way of doing things will die
out, but today it can still be done for something like a company internal app
and it's really cool from the developer's pov!

------
saosebastiao
For an article obviously aimed at non-technical people, I am amazed at how
not-incorrect this is.

------
Shank
I was under the impression that Java still prompts the user to allow applets
to start before they're even called - is this still true, or am I missing
something? The dialog always advises not running applets from places you don't
trust, last I checked.

~~~
justinschuh
I think you're confused, because the Java plugin has never behaved the way you
describe.

~~~
bdcravens
All of the sites with Applets I go to do this in Chrome on OSX (unless I've
explicitly said the site is trusted after the first time I run it) (Can't
recall a site off the top of my head, else I'd post a screenshot)

~~~
kijin
It's probably a browser feature, not a Java feature. Firefox also does this.

------
krzyk
Are Java applets still used anywhere? I haven't seen them in open web in years
(I see one in my companies reporting software made by third party - no one
knows why it requires java to do it's things)

~~~
krrrh
It's astonishing how often one still sees Java in device configuration web
pages, ie. printers, PBX systems. It's also still used for weird hardware
devices that are deployed in a lot of financial services, like signature pads.
Lastly, vertical applications that don't recieve a lot of updates.

It's almost impossible to understand why java is necessary in most of these
applications, but simply removing the plugin from a lot of corporate
environments would disrupt vital business functions.

------
krrrh
It looks like Oracle's failure to properly patch a security hole discovered in
August led to the current mess.

[http://thenextweb.com/insider/2013/01/11/latest-java-
vulnera...](http://thenextweb.com/insider/2013/01/11/latest-java-
vulnerability-possible-since-oracle-didnt-properly-fix-old-one-now-pushing-
ransomware/)

------
csense
It's my perception that Java is plagued with more frequent security problems
than Flash, and Flash moreso than Javascript.

Is this perception accurate?

If so, what's the reasoning? I would think Javascript would be the most-
breached browser-based code execution sandbox for the same reason Windows is
the most-breached OS: It's the most popular.

~~~
skymt
For one thing, there's no code base called "JavaScript." There's V8,
SpiderMonkey, JavaScriptCore, Chakra, and more, and an exploit in one is
unlikely to work in others. Flash and Java each have a larger market share
than any given JavaScript implementation.

Java is an interesting case in that the same platform needs to support
sandboxed browser applets and desktop/server software. Unlike JavaScript, the
designers of Java don't have the ability to simply leave the capability of OS
access out of the platform entirely. They rely on a sandbox to keep untrusted
code from calling unsafe procedures, and it's the sandbox that failed here.

------
coditor
I get so tired of articles confusing running Java on a server and running Java
on a web browser via a plugin. The latter is dangerous the former is not. But
this is rarely made clear when people write about it.

------
kabdib
MS should put in an explicit checkbox to disable Java. Bet they'd love to do
that; now they have a reason.

------
ExpiredLink
> "To defend against this and future Java vulnerabilities, disable Java in Web
> browsers."

That's not the problem. Attackers can execute Java code through other attack
vectors (JavaScript, Flash? PDF?). The only solution seems not having java on
your search path. Open a command window, type 'java' (without quotes). If you
can call java that way you are vulnerable.

~~~
Jach
If an attacker can execute code through other attack vectors (JavaScript,
Flash, or whatever), and _happens_ to execute Java, instead of say native
code, or batch files, or something else, that's not a problem with Java, it's
a problem with those programs that have the vulnerability.

The only way to be safe is to take your computer, encase it in a brick of
cement, and drop it in the Mariana Trench. NoScript and careful browsing
habits go a long way, though.

------
camus
What developpers dont understand is that it hurts the brand. if Java is
associated with malwares and exploits , it doesnt matter how you use it , your
potiental clients already heard java is bad , Oracle should either drop the
plugin or get serious at fixing it.

~~~
raverbashing
Humm but the corporate drones only care about the marketing blurb, not about
real security.

Case in point, the widespread use of older versions of IE

------
IheartApplesDix
What does this mean for sites that use Java services internally?

~~~
eranation
It's related to the Java Plugin (AKA Java Applets), running in the browser, so
anyone running a Java (or any JVM based language) on the server, is not
related to this _specific_ exploit.

As quoted:

> "To defend against this and future Java vulnerabilities, disable Java in Web
> browsers."

There are so many JVM based services out there (Including from Google,
Twitter, Foursquare and many others, even many Ruby on Rails apps running on
JRuby) that if it was also a server side exploit of that level, it would have
been even a bigger concern. (Users getting their bank account stolen is
terrible, bank get hacked is a different level of terrible)

