Wednesday, April 28, 2010

Mutable InetAddress Socket Policy Violation (ZDI-10-055/CVE-2010-0095)

Relevant Identifiers:
ZDI-10-055, CVE-2010-0095


Impact:
Violation of Same Origin Policy, allowing unsigned applets to connect to any host.


Oracle Java Patch:
http://www.oracle.com/technology/deploy/security/critical-patch-updates/javacpumar2010.html


Details:
This is a low-impact, but technically somewhat interesting vulnerability.

java.net.InetAddress is a public, non-final, serializable class. It has a package-private constructor.

If one was to respect compiler errors, it would not be possible to create a subclass of InetAddress in another package, because creating a legal constructor for the subclass is impossible. But it turns out one does not need a legal constructor. As the superclass is serializable, the subclass constructor never gets called and never gets verified by the run-time. No tricks are required for creating the subclass. For example, Eclipse compiler will compile the rest of the class normally and create a constructor that just throws an exception.

In the case of InetAddress this allows us to create a subclass which is a mutable InetAddress. In other words, give the same origin policy check one value, and use another value when doing the actual connection. Nothing as complicated as timing is required as the SOP check uses the getHostAddress() method, while the actual connection uses the private address field, which can be deserialized into having any desirable value.

The Fix:
Update 19 added a readObject method to the InetAddress class, which throws a SecurityException if the instance being read was not loaded by the null ClassLoader.

1 comment:

Unknown said...

I totally agree with you. From the potential risk is can be admitted as low. From the type of weakness and/or technical point of view is really interesting since it goes in to details of the interface between bytecode and classloader.
Thanks again for sharing your thought with us,
Cheers Matthias