FireEye security researchers are warning that they have detected a new zero-day vulnerability that is being used successfully in the wild against browser clients with both Java 6u41 and Java 7u15 installed.

Given that the Java 7 update was only released a couple of weeks ago, this is yet more bad news for Oracle and for users of the Java browser plug-in. bad news, but not exactly surprising as security researchers have been finding flaws in the update since it was made available. The difference here is that this isn't just a lab-based, theoretical, vulnerability: this is, it would appear, a fully-blown in the wild exploit.

FireEye researchers state that:

...this vulnerability leads to arbitrary memory read and write in JVM process. After triggering the vulnerability, exploit is looking for the memory which holds JVM internal data structure like if security manager is enabled or not, and then overwrites the chunk of memory as zero.

At the moment the exploit doesn't appear to be all that reliable, which is something, as the amount of memory being overwritten fails to execute and causes a JVM crash. Hopefully a more reliable update will be made available by Oracle soon, in time to prevent the bad guys from tweaking this exploit and making it work reliably. FireEye is working with Oracle to this end, but in the meantime advises users to disable Java in the browser until such a time that a patch becomes available.

Similar advice is being issued by Qualys this morning:

These attacks are all against Java on the desktop and use the browser as an attack vector. Our recommendation is to uninstall Java from the desktop if possible, otherwise disconnect Java from the browser, which recent versions of Java have made much easier. If neither of these options work, look at a whitelisting solution for Java. Through its Zone mechanism Internet Explorer enables you to disable Java in the Internet Zone, but to leave it enabled in the Trusted Sites zone, which then needs to contain the sites that you need to run Java on (GotoMeeting, internal sites, etc).

Edited 3 Years Ago by peter_budo: Removing as sticky, 4 weeks old

No flaming inteded, however it would be nice once in while if you wrote about something that got fixed. Open source community is doing their best to help to tacle all while trying to bring new stuff in. World is not all negative... ;)

PS: Can get you in touch with London open source community with influence on Oracle Java development, just ask.

The world may not be all negative Peter, but security problems usually are. Would you rather people were not warned, in a timely fashion, of real world threats out there that could impact upon their data? Some things just cannot be sugar coated...

All security issues are some variety of design failure. No one can sneak into your computer through the internet without an invitation, so the big questions are what design failure in the JVM makes this theoretically possible, and what is being done about it?

The good news that I want to hear is that Oracle has not only fixed the security hole, but fixed the bad design that caused security holes to be possible. Just fixing the security hole wouldn't be news; another security hole must be expected to pop up in future updates and so Java cannot ever be trusted. On the other hand, if the design problem were found and corrected so that Java becomes immune to all security holes forever, that would be good news worth reading.

Edited 3 Years Ago by bguild

When Oracle fixes it, really fixes it rather than keep using sticking plasters to try and stem an arterial bleed, then I will be the first to write a news story saying so. That said Peter, don't hold your breath :)

Comment from Lamar Bailey, Director of Security Research and Development at nCircle on the latest patch/fix:

Oracle has taken a beating this year on Java. It is good to see they are fixing critical vulnerabilities in a code base they want to quit updating but it is past time for them to get serious and do a deep dive on Java to fix the security issues. I hope Oracle will assign a team of their best security engineers to Java to squash any of the remaining security issues. Until then many users will be updating Java as often as they update AV signatures.

what complete bollocks. These vulnerabilities are extremely rare and hard to trigger, and I seriously doubt Oracle is going to pump out new JVM versions 3-4 times a day, which is the rate of database updates for serious AV products.
Or do you suggest most people update their AV product only when they get a new PC, which is roughly how often most people update their Java plugin?

Last year I was still maintaining applications written for 1.4 JVMs, the customer was considering an eventual upgrade to 1.5 sometime mid 2013 at the earliest.

I find it very strange that we're getting this flood of high profile "security warnings" about Java only AFTER Oracle has taken over the product, usually from companies that look like they are closely tied with those that would benefit greatly from Oracle's demise...
Of course a lot of the core dev team responsible for the Java platform left Sun during the takeover, which may have something to do with it, and the increasing reliance of amateurs adding "fixes" to the openJVM codebase can't be helping either.

I seriously doubt Oracle is going to pump out new JVM versions 3-4 times a day, which is the rate of database updates for serious AV products.

Java doesn't need and shouldn't have an anti-virus database. Java runs on a virtual machine, which means that the virtual machine is directly responsible for any inappropriate behaviour in any Java program. We don't need to fight a eternal war against malware like the anti-virus people fight; all we need is a virtual machine that refuses to do anything bad.

By that I mean slash away at Java's capabilities until it can only do harmless things, because the vast majority of Java programs don't need to be able to do the sorts of things that could be harmful. If you can display some GUI (marked as Java) and read and write some files (of moderate size) from carefully restricted directories, then you have all the access to the operating system that any Java program should need. Not even system code should be able to do more than that; system code should be the code that's making those OS accesses happen.

Of course you may sometimes want to have Java applications with more liberal access to the OS, but that can be done using libraries that a normal virtual machine can't even load because they aren't in the normal class path and if they somehow where loaded then the JVM would throw an exception instead of running any of their native code because the JVM knows that those are the dangerous classes.

This article has been dead for over six months. Start a new discussion instead.