Monday, April 05, 2010

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

Affected Vendors

Affected Products

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:

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:

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

Affected Vendors

Affected Products

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:

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

Affected Vendors

Affected Products

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:

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

2 comments:

Anonymous said...

Sami, great work!

Could explain a bit more CVE-2010-0840 ? I suppose after extending some classes an attacker is able to manipulate protected attributes that is being used in methods that invokes privileged stuff (other methods from different classes, ie. doPrivileged?) How do they patch it ?

Sami Koivu said...

Thanks! :) And absolutely, I'll write some more detailed stuff on each three vulnerabilities, starting with CVE-2010-0840. It's kinda like a digital Rube Goldberg machine that starts with the graphical user interface thread and ends up with Java security getting switched off. They patched the very end of the chain, a clean fix, but one that does nothing against future attacks. But anyway, more details as I finish the post today or tomorrow.