tag:blogger.com,1999:blog-7283793710804138254.post1231864415860600639..comments2023-06-26T01:33:12.868-07:00Comments on (Slightly) Random Broken Thoughts: Java Trusted Method Chaining (CVE-2010-0840/ZDI-10-056)Sami Koivuhttp://www.blogger.com/profile/14293649159254807206noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-7283793710804138254.post-34049668926364870332013-09-29T20:49:15.181-07:002013-09-29T20:49:15.181-07:00This is awesome!This is awesome!Hymanhttp://coffeemakerstop.usnoreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-30996648130293993932011-05-09T09:50:53.309-07:002011-05-09T09:50:53.309-07:00i would like to know how did you discover this bug...i would like to know how did you discover this bug.NCRhttp://crackinglandia.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-29474199087830443422010-04-26T21:29:31.596-07:002010-04-26T21:29:31.596-07:00In this case, I believe the setValue methods are t...In this case, I believe the setValue methods are treated by the VM as two separate methods, because of the differing signature (=return type). I <a href="http://slightlyrandombrokenthoughts.blogspot.com/2007/01/obfuscating-by-overloading-method-and.html" rel="nofollow">wrote</a> some years ago about how some obfuscators create classes that overload fields, and methods with the same parameters but different return types.<br /><br />Another point is that as the attack doesn't require calling the setValue method, it might never get verified anyway. My third vulnerability fixed in update 19 (that I didn't write about yet) deals with creating a class that doesn't have a valid constructor, but instances of which get deserialized without any problem.Sami Koivuhttps://www.blogger.com/profile/14293649159254807206noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-60417898628751735132010-04-26T20:19:09.563-07:002010-04-26T20:19:09.563-07:00And the java compiler will not like some conflicts...<i>And the java compiler will not like some conflicts between the methods of the superclass and the interface...</i><br /><br />Ah, that explains it.<br /><br />It's documented that exception declarations are ignored by the VM, but I'm slightly surprised that the different return type is accepted. (IIRC, return types were originally novariant, but that was changed to support covariance at some point, so maybe that's why it's accepted.)Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-80480059843940149962010-04-26T18:40:21.920-07:002010-04-26T18:40:21.920-07:00Thanks.
I need a class that can't be compiled...Thanks.<br /><br />I need a class that can't be compiled, because the attack requires the creation of a class which extends java.beans.Expression and implements java.util.Map.Entry. Something like this:<br /><br />public class Link extends Expression implements Map.Entry {<br />...<br />}<br /><br />And the java compiler will not like some conflicts between the methods of the superclass and the interface:<br /><br />Map.Entry:<br /> Object setValue(Object value);<br /> Object getValue();<br /><br />Expression:<br /> public Object getValue() throws Exception ...<br /> public void setValue(Object value) {<br /><br />The conflicts from the setValue's return type and getValue throws clause make it impossible to compile that class. However if you go ahead and generate a class, the runtime accepts it just fine.Sami Koivuhttps://www.blogger.com/profile/14293649159254807206noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-52793226526077210992010-04-26T16:49:12.573-07:002010-04-26T16:49:12.573-07:00Good work! Why do you need a class that can't ...Good work! Why do you need a class that can't be compiled from Java code?<br /><br /><i>Based on my very brief analysis, Java 6 update fixes this problem by altering the Statement.invoke() to use the AccessControlContext captured at the moment of instantiation when it uses the reflection.</i><br /><br />Sigh, fixing the particular instance rather than the underlying design problem with use of stack inspection (as always).Daira Hopwoodhttps://www.blogger.com/profile/07786700719460528830noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-21926506740521993172010-04-16T19:52:44.707-07:002010-04-16T19:52:44.707-07:0005hi: Thanks for the correction. You're absolu...05hi: Thanks for the correction. You're absolutely correct. Fixed it.Sami Koivuhttps://www.blogger.com/profile/14293649159254807206noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-42180142929088149802010-04-16T12:36:05.139-07:002010-04-16T12:36:05.139-07:00ahhh I even tried System.class before but passed a...ahhh I even tried System.class before but passed a wrong argument by mistake, got method not found exception and wrongly assumed it was the target object part. Anyways, thanks Sami!<br /><br />Also in the last 3 points of the 'what happens' part you switched Statement with Expression. e.g.<br />- Statement.getValue() calls Expression.invoke()<br /><br />this should read <br />- Expression.getValue() calls Statement.invoke()05hinoreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-54978979518204197612010-04-14T16:56:19.981-07:002010-04-14T16:56:19.981-07:00Francesco: Thanks!Francesco: Thanks!Sami Koivuhttps://www.blogger.com/profile/14293649159254807206noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-7039227304059829022010-04-14T16:55:44.741-07:002010-04-14T16:55:44.741-07:0005hi: As System.setSecurityManager is a static met...05hi: As System.setSecurityManager is a static method you pass System.class as the target param.<br /><br />The three params that I'm passing to Expression are defined thusly:<br /><br />Object target = System.class;<br />String methodName = "setSecurityManager";<br />Object[] args = new Object[]{null};Sami Koivuhttps://www.blogger.com/profile/14293649159254807206noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-3491162171582902632010-04-14T01:48:44.573-07:002010-04-14T01:48:44.573-07:00Very nice job. I managed to get the exploit workin...Very nice job. I managed to get the exploit working and execute commands through Runtime.exec. How do you pass 'java.lang.System' as a target to Expression? I'm sure it's trivial but can't seem to get it to work. Java is not my first language;) <br />Again, HIGH quality work! Thanks.05hinoreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-85190865706591500192010-04-13T16:37:47.377-07:002010-04-13T16:37:47.377-07:00Absolutely a great finding. Chapeau for your Java ...Absolutely a great finding. Chapeau for your Java Internals skills :)<br /><br />Bye, Francesco `ascii` Ongaro, ush.itAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-30886371294671568552010-04-10T20:55:31.054-07:002010-04-10T20:55:31.054-07:00Thanks Matthias! I appreciate the interest, and lo...Thanks Matthias! I appreciate the interest, and look forward to reading about your discoveries.Sami Koivuhttps://www.blogger.com/profile/14293649159254807206noreply@blogger.comtag:blogger.com,1999:blog-7283793710804138254.post-85664833008797935472010-04-09T03:33:10.900-07:002010-04-09T03:33:10.900-07:00Awesome work, I'll try to reproduce the vuln.
...Awesome work, I'll try to reproduce the vuln.<br />Again, thanks for all the details you share with us on your blog and hope to hear more from you. Apperently your are the only one who is really looking at internal java security issues (non-native ones)! Thanks again!Matthias Kaisernoreply@blogger.com