The new Java 0Day examined (The H)

[Posted August 30, 2012 by corbet]

Here's an article in The H explaining how the latest (still unpatched, apparently known to Oracle since April) Java vulnerability works. "Oracle has not yet released an official statement concerning the critical vulnerability. At this article's time of publication, the company still offered Java version 7 update 6 to download; like all older series 7 versions, this release is vulnerable to attacks via the vector described above. Users who have a vulnerable version installed on their systems are advised to disable the browser plugin that provides Java support."

(Log in to post comments)

Posted Aug 30, 2012 14:17 UTC (Thu) by smurf (subscriber, #17840) [Link]

> apparently known to Oracle since April

Why am I not at all surprised?

The new Java 0Day examined (The H)

Posted Aug 30, 2012 14:32 UTC (Thu) by mjw (subscriber, #16740) [Link]

Note this is already fixed with IcedTea:
https://gnu.wildebeest.org/blog/mjw/2012/08/30/java-bug-c...

And patches posted to openjdk:
http://thread.gmane.org/gmane.comp.java.openjdk.beans.dev...

The new Java 0Day examined (The H)

Posted Aug 30, 2012 15:26 UTC (Thu) by geuder (subscriber, #62854) [Link]

Yes, and it affects only OpenJDK 7 not OpenJDK 6. How many distros are on version 7 compared to version 6 currently?

The new Java 0Day examined (The H)

Posted Aug 30, 2012 16:22 UTC (Thu) by Otus (subscriber, #67685) [Link]

Ubuntu 12.04 has both. At least I had 7 was installed as a dependency for something.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 18:58 UTC (Thu) by dowdle (subscriber, #659) [Link]

Fedora offers both... and RHEL 6 offers both.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 14:59 UTC (Thu) by dashesy (guest, #74652) [Link]

I always wished Firefox would ask me before letting a plugin install itself. Some applications specially in Windows give themselves the right to do whatever they want. In the company desktop I just noticed "Microsoft Office", "Google Update", and two identical!! "NVIDIA 3D Vision" among them. I certainly do not need most of them, and certainly do not need Java plugin, although Firefox is smart to disable Java plugin for being old.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 17:40 UTC (Thu) by Kit (guest, #55925) [Link]

How would Firefox know the difference between a plugin that was just installed, and one that it had already seen before? I'd imagine the exact same situation would happen as when Firefox tried to do that with extensions, where the first time FF sees the extension has been installed outside of it, it prompts the user... the people distributing them simply would change whatever setting in Firefox was necessary so that it didn't consider it 'new'.

As long as the plugins are distributed via an executable installer, there's not really much of anything Firefox can do about it. Sadly, that just seems to be how it's going to go.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 18:19 UTC (Thu) by dashesy (guest, #74652) [Link]

I agree it does not seem to be straight forward. However if the setting is something user visible in a menu (as opposed to some obscure about:config), and another setting warns about possible outsider intrusions, the user will notice it, and will require bolder plugin developers to sneak in with their installers (and subdue the warning).

As a rule of thumb, any plugin that does not have an easy "uninstall" or "update" should be blacklisted with a big warning (e.g. "Firefox is tainted by ...") somewhere visible (maybe in the caption title) until disabled by user, or fixed by developer.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 22:29 UTC (Thu) by HenrikH (subscriber, #31152) [Link]

The problem is that these plugins installers are sneaky. Their developers have figured out how Firefox stores "this plugin is new" somewhere in it's profile and it changes that value to look like the user has OK:ed it so it goes in silently.

Not even crypto signing would work here since the private key must be found on the machine somewhere for Firefox to update it's own profile and the plugin installers would thus also find it.

The new Java 0Day examined (The H)

Posted Aug 31, 2012 7:48 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Right, what's going on here is a "blame the victim" mentality.

From the outset other applications have deliberately tried to sneak past Firefox's built-in restrictions.

That's because those applications are _malware_ and the technical community's failure to react correctly to that is our fault.

When Microsoft did this we got the victim blaming "Firefox should have better defences" as if the application developer can protect their app against the OS vendor. What we should have seen was an outcry until Microsoft put some heads on the block. "My predecessor lost their job for that" is a surprisingly powerful incentive not to behave unethically.

If you could name a handful of senior figures at Microsoft who had left the industry because of that "clever" but quite obviously unethical trick, this wouldn't now be so popular. But instead Windows programmers (for it's always Windows) know that whatever they do to Firefox the technical community will say "Well, Firefox deserved it" and the victim gets the cleanup bill.

The new Java 0Day examined (The H)

Posted Aug 31, 2012 17:02 UTC (Fri) by smurf (subscriber, #17840) [Link]

Reverse Sandboxing would help. I.e. you don't park the plugin into a sandbox (though that's also a good idea, albeit harder to implement), but the part of the browser that stores options and handles authorization.

(Frankly, what would also help is to learn about the difference between "its" and "it's". Just sayin'.)

The new Java 0Day examined (The H)

Posted Sep 17, 2012 15:41 UTC (Mon) by HenrikH (subscriber, #31152) [Link]

No it doesn't, since the plugin author has complete control of the computer he can bypass whatever Firefox does, if Firefox implement reverse sandboxing then the plugin will simply do all the steps that Firefox would do when the user clicks the "click OK to really intstall this plugin".

There is _nothing_ that Firefox can do to protect itself from this. _Nothing_.

The new Java 0Day examined (The H)

Posted Sep 17, 2012 15:53 UTC (Mon) by khim (subscriber, #9252) [Link]

No it doesn't, since the plugin author has complete control of the computer he can bypass whatever Firefox does, if Firefox implement reverse sandboxing then the plugin will simply do all the steps that Firefox would do when the user clicks the "click OK to really intstall this plugin".

At this point said plugin is in clear violation of DMCA anti-circumvention provision and should be treated as malware: added to AV-databases (which will block it's installation and will be quickly be updated if new version of plugin will be released), etc.

There is _nothing_ that Firefox can do to protect itself from this. _Nothing_.

Firefox can not, Mozilla foundation can. I'm not sure if they have enough guts to try, but yes, they can prevent that for most plugins.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 16:25 UTC (Thu) by bronson (subscriber, #4806) [Link]

There is no need to deploy Java on any client (beyond predictable legacy stuff of course). It's time to deprecate the heck out of it.

I've been disabling the Java runtime on all my plaforms for at least two years, a span of 3 or 4 0days... I haven't missed it at all.

(It's somewhat ironic how the VM was supposed to keep you sandboxed and safe, and yet it's the VM that keeps giving up the farm...)

-- ex Java developer

The new Java 0Day examined (The H)

Posted Aug 30, 2012 17:07 UTC (Thu) by hpa (guest, #48575) [Link]

Is it just me, or does it seem like this was a bug that was just waiting to happen?

sun.awt.SunToolkit.getField()

... sounds like something that was just waiting to be exploited, it is half of a security hole all by itself. It just needed the other half.

Browser Java deprecated ... the enterprise problem

Posted Aug 30, 2012 17:23 UTC (Thu) by kmself (guest, #11565) [Link]

As with much else on the security front, inherently vulnerable and/or poorly maintained technologies (of which Java is increasingly appearing to be both) are often required for legacy business purposes. Specific in-house, or worse, business-partner (buyer / seller / government) apps which are required for operations, one-offs, and often, are difficult to replace.

For the run-of-the-mill user to disable and/or remove browser Java support probably is a no-brainer now. Business users may have other needs, and worse, may not have the administrative rights to modify their configurations.

The rest of us can engage in some self-satisfying "I told you so". After we confirm we've disabled the crud ourselves.

Browser Java deprecated ... the enterprise problem

Posted Aug 30, 2012 17:57 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

It's not that Java is especially vulnerable or poorly maintained, or that Oracle people can't write a patch as fast as icedtea people. We are used to patch, configure, make install, but you have to remember Java in SUN tech, and SUN took pride in elegant code (zfs, dtrace, etc) and could never understand the market preferred less elegant code with non-primitive plumbing.

I suspect that to transform changed JVM code in something that can be downloaded for Windows/Solaris/Linux Oracle needs its people to click in various GUI tools, drag and drop files from folders to folders, get approval from various management and QA teams (either physically or through some web forms), and that the whole thing is such a manual bureaucratic nightmare they pretty much can only do releases on a schedule prepared months in advance.

The modus operandi of a company like SUN/Oracle is light years away from the one of the Linux kernel, where Linus could freeze operations a few weeks to write git, just because he didn't like his tooling, and wanted something more efficient. At Sun/Oracle some people write code and others transform it in product binaries, and no one in the first group would even dream intruding on what the second group does.

Browser Java deprecated ... the enterprise problem

Posted Aug 30, 2012 19:20 UTC (Thu) by mjw (subscriber, #16740) [Link]

> At Sun/Oracle some people write code and others transform it in product binaries, and no one in the first group would even dream intruding on what the second group does.

What is weird is that the second group which pushes out proprietary binaries seems to trump the first group which actually creates free software source code (OpenJDK is published under the GPL). Apparently there is now a proprietary binary jdk release from Oracle out there that presumably fixes the issue, but the only code published through OpenJDK is from the IcedTea people (I posted a patch yesterday and only non-Oracle engineers replied and tested it).

It is as if there is a priority reversion where binaries come before publicly reviewed code.

Java is modern cobol thanks to Y2K

Posted Aug 30, 2012 22:14 UTC (Thu) by landley (guest, #6789) [Link]

Keep in mind that Java peaked around 1998, right when everybody was doing the last-minute scramble to finally deal with all the Y2K bugs in their legacy code. An awful lot of that legacy code got rewritten in the hot language of the day, which was Java.

And that's how a thing that runs in your browser (and might grow to the desktop someday) turned into a Fortune 500 back-end mainframe data shoveler. Of course Cobol Jr. it's all about the enterprise: Browser applets were replaced by flash a decade ago (and Flash is already on its way out).

I doubt we'd even _remember_ Java if it wasn't for Y2K, any more than RealAudio or Visual Basic.

Rob

Java is modern cobol thanks to Y2K

Posted Aug 31, 2012 1:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Wrong. Java was widely used for non-Y2K projects. It's widely used _now_ in Android for the same reasons.

Mostly because it's the only real (non-toy) cross-platform static language with a performant VM.

Java is modern cobol thanks to Y2K

Posted Aug 31, 2012 2:07 UTC (Fri) by marcH (subscriber, #57642) [Link]

Well said. While the language can be painful and cumbersome to program into, it's simply the only serious offer with these three properties.

By the way a number of other languages also compile into java bytecode.

Java is modern cobol thanks to Y2K

Posted Aug 31, 2012 9:57 UTC (Fri) by job (guest, #670) [Link]

To be fair, the main reason why it's used in Android is its market share (see: Y2K).

Android had to be quick to market (built on Linux), and accessible to programmers (Java), in order to present itself as an aquisition target. Had Android been developed inside Google it might very well have been done differently. I often fantasize about an Android built on Python instead.

Java is modern cobol thanks to Y2K

Posted Aug 31, 2012 14:13 UTC (Fri) by drag (guest, #31333) [Link]

Java + Linux dominated the more full fledged embedded development scene. That is why Android uses it. It has nothing to do with Y2k because people essentially rewrote their applications for each product.

Java is still extraordinarily popular language for enterprise server applications.

That is because it's the only real VM and it is the only significant competitor to .NET.

Java is modern cobol thanks to Y2K

Posted Aug 31, 2012 16:20 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

..shudder..

Android-on-Python would have been even more slower (Java is a _fast_ interpreted language) and without possibility for enhancements (JITs for Java are commonplace, JITs for Python are not).

And of course, lack of static typing.

Java is modern cobol thanks to Y2K

Posted Sep 1, 2012 23:06 UTC (Sat) by anselm (subscriber, #2796) [Link]

Android-on-Python would have been even more slower (Java is a _fast_ interpreted language) and without possibility for enhancements (JITs for Java are commonplace, JITs for Python are not).

PyPy is supposed to be very good indeed.

Java is modern cobol thanks to Y2K

Posted Sep 2, 2012 3:28 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

And it requires about 20 times more RAM than Dalvik's JIT and _still_ produces inferior code.

We're using a lot of Python (and numpy) code in our R&D and so I've tested all possible ways to make Python work faster. They all suck in various ways.

Java is modern cobol thanks to Y2K

Posted Sep 7, 2012 13:33 UTC (Fri) by pboddie (guest, #50784) [Link]

Care to describe "all possible ways"?

Within Google - I'm guessing that you and another prominent commenter on LWN work there given the numerous "nod and wink" references to various projects - there have apparently been a number of projects to improve Python performance and/or predictability, some being very widely known and others only barely surfacing on the radar of the most central Python core developers (many of whom also seem to be at Google), so I'd be interested to hear what you've looked at.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 23:08 UTC (Thu) by cma (guest, #49905) [Link]

What males you think there is no need of há ing java ru time on any client? Se have been deploying java based solution for financial markets focusing los latency clientes for morder and risk management systems...no problemas so far concerning security contraints compared to a C/C++ or .NET based solutions. Bugs exista on any tecnology or enviroment. Besides security you should falso be concerne on performance, and manteinability of the product as well multiplatform deployment. Java exceeds on any of those even on security constrained enviroment. And that's why java is the facto enterprise and mobile platform... Rgrds. Edu

The new Java 0Day examined (The H)

Posted Aug 30, 2012 23:28 UTC (Thu) by cma (guest, #49905) [Link]

Dammit android's auto correct...sorry below the corrected post: What makes you think there is no need in having java runtime on any client? We have been deploying java based solution for financial markets focusing low latency clients for order and risk management systems...no problemas so far concerning security contraints compared to a C/C++ or .NET based solutions. Bugs exists on any tecnology or enviroment. Besides security you should also be concerned on performance, and manteinability of the product as well multiplatform deployment. Java exceeds on any of those even on security constrained enviroments. And that's why java is the facto enterprise and mobile platform... Rgrds. Edu

The new Java 0Day examined (The H)

Posted Aug 30, 2012 17:27 UTC (Thu) by reddit (guest, #86331) [Link]

Why isn't there criminal prosecution for the managers of companies that leave vulnerabilities unpatched?

As far as I can tell, they are directly acting to help the activities of criminals and organized crime all around the world.

Oh, and maybe they should be forced to pay a reparation of $100k at least (or an equal share of their assets after they declare bankruptcy due to this) for every person they intentionally put in danger of getting all their personal data stolen and/or destroyed.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 18:10 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

Why isn't there criminal prosecution for the managers of companies that leave vulnerabilities unpatched?

Negligence can be a crime, but ignorance and stupidity aren't. At least not yet. Many PHBs simply pull the wool over their eyes and pretend their company/organization couldn't possibly be the target of maliciousness. Sigh.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 19:19 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Why isn't there criminal prosecution for the managers of companies that leave vulnerabilities unpatched?

You're invited to suggest answers to the following questions:

Which managers do you charge?
What actual offence do you charge them with?
How do you prove it beyond reasonable doubt in a court of law?

The new Java 0Day examined (The H)

Posted Aug 30, 2012 20:30 UTC (Thu) by richmoore (guest, #53133) [Link]

Don't forget:

What did you pay for it?

If there's no payment or contract, then I don't see how you'd have any legal recourse anyway.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 20:48 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

Not paying anything might cover civil liability, but criminal liability's another kettle of fish.

The new Java 0Day examined (The H)

Posted Aug 31, 2012 14:17 UTC (Fri) by drag (guest, #31333) [Link]

> Why isn't there criminal prosecution for the managers of companies that leave vulnerabilities unpatched?

Because that would be damn stupid thing to do.

> As far as I can tell, they are directly acting to help the activities of criminals and organized crime all around the world.

So does roads and airports, but nobody is trying to prosecute them.

> Oh, and maybe they should be forced to pay a reparation of $100k at least (or an equal share of their assets after they declare bankruptcy due to this) for every person they intentionally put in danger of getting all their personal data stolen and/or destroyed.

Or you could just take responsibility for your own life and not use shitty software.

The new Java 0Day examined (The H)

Posted Sep 2, 2012 1:30 UTC (Sun) by gmaxwell (guest, #30048) [Link]

Or you could just take responsibility for your own life and not use shitty software.

Meh. Everything else you said was great— but software, certainly closed source binary software, is something of a lemon market. The authors may know that the software was rushed, untested, and shoddy, but the users can only tell after the fact. It's not right to blame the victims, even if it also isn't right to hold the perpetrators accountable.

Perhaps it might be more realistic to establish disclosure requirements— thus delemoning the market and reducing the incentives to be dishonest about your poor software quality— than it would be to make people responsible for unreliable and poorly maintained code?

The new Java 0Day examined (The H)

Posted Sep 7, 2012 10:23 UTC (Fri) by ortalo (subscriber, #4654) [Link]

Do you remember the license agreement you clicked through for Java? (By the way, even for a paid-for software, I guess a similar answer would be applicable.)

The "culprit" will be the one who tries to exploit (maybe even the one who finds/talks about it), not the one that leaves everything exploitable.
For me, this situation is not satisfying; however, Very Serious People usually think it is.

The new Java 0Day examined (The H)

Posted Aug 30, 2012 17:44 UTC (Thu) by pheldens (guest, #19366) [Link]

So 7 . 7 fixes this? http://java.com/en/download/linux_manual.jsp?locale=en

The new Java 0Day examined (The H)

Posted Aug 30, 2012 18:48 UTC (Thu) by juhah (subscriber, #32930) [Link]

Yes.
http://www.oracle.com/technetwork/topics/security/alert-c...

The new Java 0Day examined (The H)

Posted Aug 31, 2012 7:26 UTC (Fri) by ogj (subscriber, #3024) [Link]

But, even with this version, Google Chrome complains that the plugin is outdated!

The new Java 0Day examined (The H)

Posted Aug 31, 2012 5:18 UTC (Fri) by CChittleborough (subscriber, #60775) [Link]

Java sandboxes untrusted applets by having library methods that do possibly-dangerous things check for permission first. It's a tedious, finicky approach that requires programmers who work on low-level library classes to think carefully about security. That the Oracle team either ignored the security implications of Expression.execute() or bungled the checking says something very bad about Oracle's project management. Erk.

And still can't save.

Posted Sep 1, 2012 5:35 UTC (Sat) by gmatht (guest, #58961) [Link]

Despite unsigned applets being rather dangerous, they are missing four important and rather safe rights:
1) The right to open a trusted file save dialog that a user can use to save a file to a location of their choosing.
2) The right to open a trusted file open dialog, as above.
3) The right to read from the clipboard immediately after the user has pressed Ctrl-V.
4) The right to write to the clipboard immediately after the user presses Ctrl-C or Ctrl-X.

Incidentally, since BicaVM came fairly close to creating a JavaScript JVM, I wonder if we could compile a JVM into NaCl to eliminate additional risk from Java plugins?

And still can't save.

Posted Sep 2, 2012 1:20 UTC (Sun) by khim (subscriber, #9252) [Link]

Incidentally, since BicaVM came fairly close to creating a JavaScript JVM, I wonder if we could compile a JVM into NaCl to eliminate additional risk from Java plugins?

Well, Mono and V8 both work with NaCl so it's perfectly possible. The devil is in details, as usual. NaCl does not support all the APIs Java plugin supports (no synchronous API at all) so you can not create drop-in replacement. You can embed NaCl in the usual Java plugin instead... but this will be huge mess so it's not clear if it'll be an advantage or not.

0Day? Too late

Posted Sep 7, 2012 14:02 UTC (Fri) by man_ls (guest, #15091) [Link]

In the interest of pedantry, this is not a 0-day vulnerability. If it has been known to Oracle since April, and it is now widely known, then the vendor has had several days (or months) to patch it, so it is a regular unpatched vulnerability. 0-day means that the malicious party has a head-start over everyone else, including the vendor.