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> 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 > > 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] > 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> > 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 > 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 > > ~ 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
