Newly Discovered Java Vulnerability Effects All Versions 5/6/7

A newly discovered Java vulnerability allows an attacker to bypass the Java sandbox allowing remote code execution of unsigned content. An attacker exploiting this vulnerability would be able to exploit Java 5, 6, and the latest version Java 7.

Due to the nature of Java as a cross platform language all Java users, whether on Linux, OSX, or Windows, are vulnerable. It’s because of this ability to ‘write once, exploit everywhere’ feature that Java is such a tempting target. With over 1 billion devices running Java it’s plain to see why an attacker would look for exploits there.

The exploit is also confirmed to work on all browsers on Windows 7 32bit, though it should work on all browsers on all Java capable platforms.

On top of the tempting nature of Java there’s Oracle’s poor history with Java security. Patches tend to be late and long after an attack while the Java Runtime Environment has no particular security oriented aspects (despite it seeming like it could if they only tried).

It wasn’t long ago that another vulnerability in the JRE had been found. That one had been for Java 7 only and everyone was surprised that Oracle was able to patch it after about 4 days. Or at least they were surprised until they found out Oracle had been notified of the vulnerabilities months ago.

The short story is that Java is always going to be a target. On Windows you can rely on third party software to secure it and on Linux you can Apparmor it.

Oracle Relases Java 7u7 – Patch For Recent Vulnerabilities

Oracle has released an out of cycle patch for the recently exploited vulnerabilities in the JRE. It took a few days but it’s out now. Even in this short amount of time it’s reported that 10’s of thousands of users have been infected and let’s remember how very often it is that users take days or weeks to patch.

Get the patch here.

AppArmor And Java

What with the latest 0day getting a surprising amount of attention I figured I’d go ahead and show you guys my personal apparmor profile for Java, which I’ve only used a bit (I rarely run into the plugin online). I use this profile with Google Chrome on Ubuntu 12.04. It may require a few ‘tweaks’ depending on your specific setup and usage (see notes below) but for the most part this should work fine. If you have to add anything to it let me know – this should act as a helpful ‘base’ to start from though, I’ve covered the major things.

Notice that I don’t use any Cx. That means you can turn this profile into a child profile from your browser.

For a guide to write your own apparmor profile you can click here. I suggest you read that if you’re unfamiliar with apparmor – best to know what you’re getting into.

You can create the profile through:

# aa-autodep /usr/lib/jvm/java-7-oracle/jre/bin/java

And the profile itself:

# Last Modified: Sun Dec 9 01:46:38 2012
#include <tunables/global>

/usr/lib/jvm/java-7-oracle/jre/bin/java {
#include <abstractions/base>

network inet stream,
network inet6 stream,
/anon_hugepage//deleted r,
/dev/snd/* rw,
/etc/.java/ rw,
/etc/.java/deployment/ rw,
/etc/fonts/** r,
/etc/host.conf r,
/etc/hosts r,
/etc/java-*/ r,
/etc/java-*/** r,
/etc/lsb-release r,
/etc/nsswitch.conf r,
/etc/passwd mr,
/etc/pulse/client.conf r,
/etc/ssl/certs/java/* r,
/etc/timezone r,
owner /home/** w,
/home/** mrk,
/home/*/.cache/dconf/user rw,
/home/*/.java/** rwk,
/home/*/.pulse-cookie rwk,
/proc/*/cmdline r,
/proc/*/coredump_filter rw,
/proc/[0-9]*/fd/ r,
/proc/asound/version r,
/proc/filesystems r,
/run/resolvconf/resolv.conf r,
/run/shm/ r,
/run/shm/* rw,
/sys/devices/system/cpu/ r,
/sys/devices/system/cpu/** r,
/tmp/ r,
owner /tmp/** m,
/tmp/** rw,
/usr/bin/env ix,
/usr/lib/j2*-ibm/jre/bin/java ix,
/usr/lib/jvm/java-&-oracle/jre/bin/java mr,
/usr/lib/jvm/java-*-sun-1.*/jre/bin/java{,_vm} ix,
/usr/lib/jvm/java-*-sun-1.*/jre/lib/*/client/classes.jsa mr,
/usr/lib/x86_64-linux-gnu/pango/*/modules/*.so mr,
/usr/local/share/fonts/ r,
/usr/share/alsa/** r,
/usr/share/fonts/ r,
/usr/share/fonts/** r,
/usr/share/glib-*/schemas/* r,
/usr/share/icons/** r,
/usr/share/themes/** r,
/var/cache/fontconfig/* r,
/var/lib/dbus/machine-id r,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/ r,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/* r,
@{PROC}/[0-9]*/net/if_inet6 r,
@{PROC}/[0-9]*/net/ipv6_route r,
@{PROC}/loadavg r,



A few things are worth mentioning.

1) /tmp/** rw, could potentially become “/tmp/** r, owner /tmp/** w”. This shouldn’t break anything but I haven’t tested this. Just one more way to restrict it.

2) I use PaX and open source GPU drivers. I can’t really test Java with anything that uses GPU acceleration (it’s not supported with this drivers) so you may want to add: ”  #include <abstractions/nvidia>”. Without quotes. This should give it access to some areas of the system that are more dangerous but allow for GPU acceleration. You can also manually add the locations by following my apparmor guide (posted earlier).

3) You can replace some version numbers (java-7-oracle) with a * (java-*-oracle) so that the profile works with all versions or at least should.

4) This isn’t perfect.

What Does This Do?

The benefits of running the Java plugin in Apparmor are numerous and revolve around keeping Java stuck in an environment where it only has access to what it legitimately needs to function. Just reading the profile it should be clear that it pretty much has access to some harmless font/ gtk files, its own files, and some slightly unruly read access to the /home/ directory.

So if I’m an attacker there are two things this is really stopping me from doing.

1) I can’t launch any second payloads, I can’t read a lot of sensitive information, and I can’t write to any critical parts of your system. It’s pretty crippled and anything not built specifically for a task like this (ie: NOT the one in the wild) is gonna break quickly.

2) I’m unable to gain access to a ton of information that could help me exploit the system further. Information on the file system can lead to ASLR information leaks or information on the system itself, giving attackers a big advantage if they want to locally exploit the system.

What it won’t stop is a payload that is built to work within the constraints of the profile. It’ll still stop it from reading/writing to a lot of dangerous places but a clever attacker could potentially work with the rights provided to them (network access, for example) to keylog the system or otherwise snoop. It just makes it way more difficult.

Java Zero-Day Out In The Wild

Another Java vulnerability is being exploited out in the open internet. It should work against all currently patched versions of Java and there is no patch out for it yet.

Without knowing the details of the exploit I can’t say how something like EMET would change things – if it’s  trying to spawn shell or use a buffer overflow EMET will help, if it’s just a sandbox escape it won’t. I still recommend you use EMET to be safe. Otherwise for Windows users the best you can do is try to stay away from shady sites, don’t let Java run on a website you don’t absolutely trust, and patch as soon as you can.

Linux users can use AppArmor to sandbox Java, this is the most effective way to stay secure against an attack like this. The exploit drops a payload, which then executes. AppArmor would stop this in a lot of ways – preventing the initial write, preventing the payload execution, etc. Even if the second payload launched or if the attacker worked exclusively from their initial .class they’d be very limited.



Just Set Up A Computer For Someone Who’s Never Had One

I’ve just finished setting up a computer for someone who’s only ever had a work computer, which isn’t connected to the internet. They share a laptop with someone but rarely use it.

Today I helped them pick out a system, Dell, and I got them started. One really interesting thing I saw was that Dell packaged the Java plugin… an out of date Java plugin. So right off the start my friend was running Java 7.1 (wtf?), which is something like 3 patches behind.

So, naturally, I updated it and installed EMET, which I set Java to use (and changed default Windows 7 settings for DEP Always On). The system also came with Webroot security. I actually think Webroot’s pretty good but I don’t have enough personal use with it to trust it and I’m pretty sure it isn’t free, which means it’ll bug my friend in a few months and he’ll be at risk.

So I removed Webroot and put in Microsoft Security Essentials. Why? For the low false positives and direct Microsoft support.

I also put Google Chrome on the system. I can not explain to someone that they need to use NoScript when they’ve never used a personal computer – they will hate me. Chrome is the only way I can keep him secure without ever getting in his way. The Chrome sandbox is “silent” and that’s really important as this guy is likely very vulnerable to social engineering having never been exposed to it in the past.

I think he’ll be fine. With 5 minutes I’ve set his system up in such a way as to be very difficult to exploit through the most common ways (browser, plugins) and Microsoft Security Essentials is good enough and quiet enough that he should be able to trust it.

Adobe Flash For Firefox Gets A Sandbox

Adobe Flash 11.3 for Firefox now runs in a sandbox! Yay. It’s not super strong, it should be virtually identical in nature to Chrome’s NPAPI sandbox, which Vupen broke out of twice. Still, this moves the cost of Flash exploitation far above what it used to be.

Chrome users will also be pleased to know that the PPAPI plugin has moved to 11.3 and it is really stable. I’m running it full time and youtube and google music run flawlessly.

So it’s a good day for security. You can expect Flash exploits in the wild to wither away because all three major browsers now sandbox it. Where will hackers go? Well… either we’ll start seeing more sophisticated attacks on the Windows system (kernel exploits, yada yada) or we’ll start seeing attacks on other plugins like… Java.

My advice… either EMET Java or uninstall it. It’s just gonna get worse for that plugin.

Java Exploits Will Continue To Rise

Before I want to start I want to say that as a language I like Java and all animosity I ever express towards Java is likely really meant for Oracle.

Oracle is officially promoting Java 7 (u4) to users now. It offers no real security benefits in terms of system compromise but it does depreciate a few broken hash methods like md4. There’s some performance improvements as well but it’s Java so, yeah.

And, once again, they’re not removing old versions of Java when they update users to 7. Yep, Java 7 installs to the side of Java 6. That’ll work out well.

Java already makes up the vast majority of exploits used against Windows systems and now users will likely have two versions installed without realizing it. Not only is that two versions of software that’s exploited daily, they probably won’t even realize the first version wasn’t overwritten so they’ll likely not patch it either. The Java Updater is pretty broken, requires you give it UAC (task scheduler wtf) permissions when it runs, and it’s on like… a 1-week schedule or 1-month by default agh it’s actually painful to talk about.

Incidentally Adobe Flash Player 13 for Firefox is going to be sandboxed by default similar to what Chrome does. It’s not a super strong sandbox but unlike Oracle Adobe actually gives a damn about security (I know, I know) and they’re made really big progress with improved ASLR and this new sandbox, which has involved serious cooperation with vendors.

So, Flash, which is the most exploited software after Java, is now going to be significantly more secure on ~20-30% of computers. Attackers could break the relatively weak sandbox given enough time but why the hell bother? You’ve now got two Java versions sitting on systems ready to be exploited.

And, because it’s Java, exploit once – run anywhere! In a study by (I believe) Sophos they actually found quite a few pieces of Windows malware on OSX machines. The OSX users weren’t infected but they’d run into an exploit that had dropped a Windows payload. I’m betting you can guess which program was dropping them.

I’d say EMET + Java = enough but that’s a lie. JIT and EMET don’t go together, it’s irrelevant really for a lot of the exploits. DEP/ASLR/EAF helps only because it’s the JVM that’s so broken and I absolutely still recommend running EMET with your Java (see my guide) but your best bet is to just uninstall it. Seriously, you can’t rely on EMET here – uninstall it.

Linux users just AppArmor Java (see my guide) and you’ll be fine. Updates are handled by the OS so patching isn’t an issue anyways. Feels good.