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 KoivuSun 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 KoivuSun 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
2 comments:
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 ?
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.
Post a Comment