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.

Java Security Updates

Zero Day Initiative has released three Advisories relating to vulnerabilities I discovered last year. Here are the original advisories, more details to follow shortly.

Sun Java Runtime RMIConnectionImpl Privileged Context Remote Code Execution Vulnerability

ZDI-10-051: April 5th, 2010

CVE ID

CVE-2010-0094

Affected Vendors

Sun Microsystems

Affected Products

Java Runtime

TippingPoint™ IPS Customer Protection

TippingPoint IPS customers are protected against this vulnerability by Digital Vaccine protection filter ID 9591. For further product information on the TippingPoint IPS:

http://www.tippingpoint.com

Vulnerability Details

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of the Sun Java Runtime Environment. User interaction is required to exploit this vulnerability in that the target must visit a malicious website.

The specific flaw exists within the deserialization of RMIConnectionImpl objects. Due to a lack of privilege checks during deserialization it is possible to supply privileged code in the ClassLoader of a constructor being deserialized. This allows for a remote attacker to call system level Java functions without proper sandboxing. Exploitation of this can lead to remote system compromise under the context of the currently logged in user.

Vendor Response

Sun Microsystems has issued an update to correct this vulnerability. More details can be found at:

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

Disclosure Timeline

2009-10-21 - Vulnerability reported to vendor
2010-04-05 - Coordinated public release of advisory

Credit

This vulnerability was discovered by: Sami Koivu

---

Sun Java Runtime Environment Mutable InetAddress Socket Policy Violation Vulnerability

ZDI-10-055: April 5th, 2010

CVE ID

CVE-2010-0095

Affected Vendors

Sun Microsystems

Affected Products

Java Runtime

Vulnerability Details

This vulnerability allows remote attackers to violate security policies on vulnerable installations of Sun Java Runtime. User interaction is required to exploit this vulnerability in that the target must run a malicious applet.

The specific flaw allows malicious applets to connect to network addresses other than the originating applet and client IPs. A handcrafted applet can override compile time checks to prevent compilation of a mutable InetAddress subclass. This results in the ability to circumvent the Applet SecurityManager restictions.

Vendor Response

Sun Microsystems has issued an update to correct this vulnerability. More details can be found at:

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

Disclosure Timeline

2009-10-21 - Vulnerability reported to vendor
2010-04-05 - Coordinated public release of advisory

Credit

This vulnerability was discovered by: Sami Koivu

---

Sun Java Runtime Environment Trusted Methods Chaining Remote Code Execution Vulnerability

ZDI-10-056: April 5th, 2010

CVE ID

CVE-2010-0840

Affected Vendors

Sun Microsystems

Affected Products

Java Runtime

Vulnerability Details

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Sun Java Runtime. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the code responsible for ensuring proper privileged execution of methods. If an untrusted method in an applet attempts to call a method that requires privileges, Java will walk the call stack and for each entry verify that the method called is defined within a class that has that privilege. However, this does not take into account an untrusted object that has extended the trusted class without overwriting the target method. Additionally, this can be bypassed by abusing a similar trust issue with interfaces. An attacker can leverage these insecurities to execute vulnerable code under the context of the user invoking the JRE.

Vendor Response

Sun Microsystems has issued an update to correct this vulnerability. More details can be found at:

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

Disclosure Timeline

2009-11-24 - Vulnerability reported to vendor
2010-04-05 - Coordinated public release of advisory

Credit

This vulnerability was discovered by: Sami Koivu