Snap no feebees for me, I am sure the Security explorations are going to be dogging Oracle about the java issues until they get with the program and get stuff fixed, so expected more upgrades to Java coming.
Z Edward E. Ziots, CISSP, Security +, Network + Security Engineer Lifespan Organization ezi...@lifespan.org This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. [Description: Description: Lifespan] From: Andrew S. Baker [mailto:asbz...@gmail.com] Sent: Tuesday, February 05, 2013 9:21 AM To: NT System Admin Issues Subject: Re: Java 7 patch 13 out... You'll notice that no one took you up on your bet... There's a reason for that. :) ASB http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker> Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market... On Tue, Feb 5, 2013 at 9:05 AM, Ziots, Edward <ezi...@lifespan.org<mailto:ezi...@lifespan.org>> wrote: Did I not say like 1-2 days after Java updated to version 7.0 update 13 that the Security explorations folks would post what is still broken in java security wise, expect a update 14 or even 15 soon enough. Cross post from Bugtraq Hello All, Below, we are providing you with technical details regarding security issues reported by us to Oracle and addressed by the company in a recent Feb 2013 Java SE CPU [1]. [Issue 29] This issue allows for the creation of arbitrary Proxy objects for interfaces defined in restricted packages. Proxy objects defined in a NULL class loader namespaces are of a particular interest here. Such objects can be used to manipulate instances of certain restricted classes. In our Proof of Concept code we create such a proxy object for the com.sun.xml.internal.bind.v2.model.nav.Navigator interface. In order to use the aforementioned proxy object, we need an instance of that interface too. We obtain it with the help of Issue 28, which allows to access arbitrary field objects from restricted classes and interfaces. As a result, by combining Issue 27-29, one can use Navigator interface and make use of its sensitive Reflection API functionality such as obtaining access to methods of arbitrary classes. That condition can be further leveraged to obtain a complete JVM security bypass. Please, note that our Proof of Concept code for Issues 27-29 was reported to Oracle in Apr 2012 and depending Issues 27-28 were addressed by the company sooner than Issue 29. Testing of the PoC will thus give best results on older versions of Java SE 7. [Issue 50] Issue 50 allows to violate a fundamental security constraint of Java VM, which is type safety. This vulnerability is another instance of the problem related to the unsafe deserialization implemented by com.sun.corba.se.impl.io.ObjectStreamClass class. Its first instance was fixed by Oracle in Oct 2011 [2] and it stemmed from the fact that during deserialization insufficient type checks were done with respect to object references that were written to target object instance created by the means of deserialization. Such a reference writing was accomplished with the use of a native functionality of sun.corba.Bridge class. The problem that we found back in Sep 2012 was very similar to the first one. It was located in the same code (class) and was also exploiting direct writing of object references to memory with the use of putObject method. While the first type confusion issue allowed to write object references of incompatible types to correct field offsets, Issue 50 relied on the possibility to write object references of incompatible types to...invalid field offsets. It might be also worth to mention that Issue 50 was found to be present in Java SE Embedded [3]. That is Java version that is based on desktop Java SE and is used in today's most powerful embedded systems such as aircraft and medical systems [4]. We verified that Oracle Java SE Embedded ver. 7 Update 6 from 10 Aug 2012 for ARM / Linux contained vulnerable implementation of ObjectStreamClass class. Unfortunately, we don't know any details regarding the impact of Issue 50 in the embedded space (which embedded systems are vulnerable to it, whether any feasible attack vectors exist, etc.). So, it's up to Oracle to clarify any potential concerns in that area. [Issue 52] Issue 52 relies on the possibility to call no-argument methods on arbitrary objects or classes. The vulnerability has its origin in com.sun.jmx.mbeanserver.Introspector class which is located in the same package as the infamous MBeanInstantiator bug found in the wild in early Jan 2013. The flaw stems from insecure call to invoke method of java.lang.reflect.Method class: if (method != null) return method.invoke(obj, new Object[0]); In our Proof of Concept code we exploit the above implementation by making a call to getDeclaredMethods method of java.lang.Class class to gain access to methods of restricted classes. This is accomplished with the use of the following code sequence: Introspector.elementFromComplex((Object)clazz,"declaredMethods") Access to public method objects of arbitrary restricted classes is sufficient to achieve a complete Java VM security sandbox compromise. We make use of DefiningClassLoader exploit vector for that purpose. [Issue 53] Issue 53 stems from the fact that Oracle's implementation of new security levels introduced by the company in Java SE 7 Update 10 did not take into account the fact that Applets can be instantiated with the use of serialization. Such a possibility is indicated both in HTML 4 Specification [5] as well as in Oracle's code. HTML 4 Specification contains the following description for the "object" attribute of APPLET element: object = cdata [CS] This attribute names a resource containing a serialized representation of an applet's state. It is interpreted relative to the applet's codebase. The serialized data contains the applet's class name but not the implementation. The class name is used to retrieve the implementation from a class file or archive. Additionally, Java 7 Update 10 (and 11) reveal the following code logic when it comes to the implementation of new security features (Java Control Panel security levels). [excerpt from sun.plugin2.applet.Plugin2Manager class] String object_attr = getSerializedObject(); String code_attr = getCode(); ... if(code_attr != null) { Class class1 = plugin2classloader.loadCode(code_attr); ... if(class1 != null) if (fireAppletSSVValidation()) ... } else { if(!isSecureVM) return; adapter.instantiateSerialApplet(plugin2classloader,object_attr); ... } The above clearly shows that the conditional block implementing Applet instantiation via deserialization does not contain a call to fireAppletSSVValidation method. This method conducts important security checks corresponding to security levels configured by Java Control Panel. The lack of a call to security checking method is equivalent to "no protection at all" as it allows for a silent Java exploit in particular. What's worth mentioning is that for Google Chrome the following HTML sequence needed to be used to activate target Applet code: <object type="application/x-java-applet" object="BlackBox.ser"> --- We have made our original reports sent to Oracle and describing Issues 29, 50, 52 and 53 available for download from our project details page: http://www.security-explorations.com/en/SE-2012-01-details.html Along with those reports we have also published the results of our quick Vulnerability Fix Experiment regarding Issue 50. We've never heard a word from Oracle regarding it. Company's fix for Issue 50 is not a mirror of the one we had proposed, but it does rely on Class object instances for hashtable access / caching of translated ObjectStreamClass fields. At the end, we would like to question Oracle's evaluation of the impact of Java vulnerabilities fixed by the Feb 2013 Java SE CPU. Oracle emphasized that patched vulnerabilities affect primarily Java Plugin / desktop environments and that only 3 of them apply to client and server deployments of Java. The 3 vulnerabilities Oracle refers to are specifically the following ones: CVE-2013-0437 Subcomponent 2D CVE-2013-1478 Subcomponent 2D CVE-2013-1480 Subcomponent AWT None of the vulnerabilities above seem to refer to the components where our discoveries were made (i.e. CORBA, JMX / BEANS). The tests we have conducted yesterday against the latest version of Oracle GlassFish Server 3.1.2.2 (with security manager enabled) and RMI Registry from JDK 7 Update 11 confirmed the possibility to launch an attack against remote RMI server with the use of a Java SE vulnerability. We tested Issues patched by the recent CPU such as the MBeanInstantiator bug, Issue 50 and 52 and were able to: 1) remotely load custom classes into the target Java RMI server (over RMI protocol), 2) completely break Java security sandbox with the use of a Java SE vulnerability (the one which "can be exploited only through untrusted Java Web Start applications / untrusted Java applets" according to Oracle's CPU). Although Oracle is aware [6] that Java SE vulnerabilities can be also exploited "in servers, by supplying malicious input to APIs in the vulnerable server component", the company rather undermines such a possibility by delivering a message that a majority of the vulnerabilities affect Java Plugin in the web browser or that in some cases, the exploitation scenario of Java SE bugs on servers is very improbable. In general, relying on a vulnerable Java SE version makes all of the products depending on it potentially vulnerable unless there is absolutely *no way* that a vulnerable component can be reached by an attacker. As long as an attack vector through RMI protocol is valid, a potential for remote exploitation of security issues in Java SE on servers should be always concerned. Thank You. Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations http://www.security-explorations.com "We bring security research to the new level" --------------------------------------------- References: [1] Oracle Java SE Critical Patch Update Advisory - February 2013 http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html [2] Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-11-306/ [3] Oracle Java SE Embedded http://www.oracle.com/us/technologies/java/embedded/standard-edition/overview/index.html [4] Oracle making embedded Java push http://www.infoworld.com/d/application-development/oracle-making-embedded-java-push-203168 [5] HTML 4 Specification, Including an applet: the APPLET element http://www.w3.org/TR/html401/struct/objects.html#h-13.4 [6] February 2013 Critical Patch Update for Java SE Released https://blogs.oracle.com/security/entry/february_2013_critical_patch_update Edward E. Ziots, CISSP, Security +, Network + Security Engineer Lifespan Organization ezi...@lifespan.org<mailto:ezi...@lifespan.org> This electronic message and any attachments may be privileged and confidential and protected from disclosure. If you are reading this message, but are not the intended recipient, nor an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you are strictly prohibited from copying, printing, forwarding or otherwise disseminating this communication. If you have received this communication in error, please immediately notify the sender by replying to the message. Then, delete the message from your computer. Thank you. -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com<mailto:mailvor...@gmail.com>] Sent: Monday, February 04, 2013 7:03 PM To: NT System Admin Issues Subject: Re: Java 7 patch 13 out... On Mon, Feb 4, 2013 at 6:42 PM, Matthew W. Ross <mr...@ephrataschools.org<mailto:mr...@ephrataschools.org>> wrote: >> There's a lot of chatter on the Mozilla Enterprise mailing list >> about this stuff right now. > > Ooh, another list to check out... https://mail.mozilla.org/listinfo/enterprise :-) > Thanks Ben. You're welcome. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com<mailto:listmana...@lyris.sunbeltsoftware.com> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
<<inline: image001.jpg>>
