<div dir="ltr">Gennamen,<div><br></div><div>This issue is another specific instance of the kinds of command injection that have plagued the Java platform since the introduction of reflection quite early on in its evolution.</div>
<div><br></div><div>The current design alternatives being discussed will face challenges. There are a few reasons to refrain from a schema-validation-based approach. And, typically, whitelist approaches fail when applied generally to inversion of control implementations because the lists are a function of the specific implementations--unknown to the framework in a vacuum. The desire to leave advice at "avoid" is compelling (XML RPC is not an optimal scheme IMO) but Security just saying "Don't use it" will not please devs.   </div>
<div><br></div><div>I've been compiling material for a blog post on this class of problems in Java as a background thread for weeks. To my knowledge, I reported and fixed the first instance for Sun in '99. If you guys have two weeks to wait on this issue, I can help dig into it deeply for secure design. </div>
<div><br></div><div>-jOHN</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 1:01 AM, Jim Manico <span dir="ltr"><<a href="mailto:jim.manico@owasp.org" target="_blank">jim.manico@owasp.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was hoping a whitelist approach within schema validation would work<br>
(ie: only allow construction of safe business-domain classes in the<br>
dangerous API's) but I agree it's unlikely to work practically.<br>
<br>
"Avoid using this with untrusted data" seems like the best advice so far.<br>
<br>
--<br>
Jim Manico<br>
@Manicode<br>
<a href="tel:%28808%29%20652-3805" value="+18086523805">(808) 652-3805</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Aug 6, 2013, at 5:30 PM, Dennis Groves <<a href="mailto:dennis.groves@owasp.org">dennis.groves@owasp.org</a>> wrote:<br>
<br>
> Interesting policy - however, attackers don't follow policy. ;-)<br>
> Which is to say, your company if they abide by the policy *may* be able to detect an attack (a.k.a AppSensor Detection point?) if the XML violates the policy - but then what do you do?<br>
><br>
> Dennis<br>
><br>
> On 6 Aug 2013, at 17:14, Dinis Cruz wrote:<br>
><br>
>> I think that the solution is not to use it at all. The scenarios where this<br>
>> API can be used safely and very small, and even then, that application's<br>
>> security would be entirety dependent on the integrity of the XML files used<br>
>><br>
>> What we really need now is Static Analysis rules to quickly identify the<br>
>> uses of this API and help the developers understand its risk (and ideally<br>
>> to replaced it with a safer API).<br>
>><br>
>> I would be good if we also could find a way to fingerprint this issue from<br>
>> a BlackBox point of view, so that PenTesters could look for it.<br>
>><br>
>><br>
>> Dinis Cruz<br>
>><br>
>> Blog: <a href="http://diniscruz.blogspot.com" target="_blank">http://diniscruz.blogspot.com</a><br>
>> Twitter: <a href="http://twitter.com/DinisCruz" target="_blank">http://twitter.com/DinisCruz</a><br>
>> Web: <a href="http://www.owasp.org/index.php/O2" target="_blank">http://www.owasp.org/index.php/O2</a><br>
>><br>
>><br>
>> On 6 August 2013 20:31, Jim Manico <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br>
>><br>
>>> The Java security manager runtime permissions have no management<br>
>>> software available and often break functionality that these libraries<br>
>>> depend on to run. I still think schema validation is in order. I'll dig<br>
>>> a little deeper into this (from a defense perspective) and get back to<br>
>>> you on this.<br>
>>><br>
>>> Cheers,<br>
>>> Jim<br>
>>><br>
>>><br>
>>>> Policy file runtime permissions may help in restricting execution of<br>
>>> rogue code. Most containers have them.<br>
>>>> Nice work btw<br>
>>>><br>
>>>> Eoin Keary<br>
>>>> Owasp Global Board<br>
>>>> <a href="tel:%2B353%2087%20977%202988" value="+353879772988">+353 87 977 2988</a><br>
>>>><br>
>>>><br>
>>>> On 6 Aug 2013, at 19:39, Jim Manico <<a href="mailto:jim.manico@owasp.org">jim.manico@owasp.org</a>> wrote:<br>
>>>><br>
>>>>> You normally want to do structural validation of untrusted XML before<br>
>>>>> you accept it (using XML schema or the like). Such defenses if<br>
>>>>> implemented right should protect you from this kind of vulnerability.<br>
>>>>><br>
>>>>> But wow, very interesting work.<br>
>>>>><br>
>>>>> Cheers,<br>
>>>>> Jim<br>
>>>>><br>
>>>>><br>
>>>>>> I wasn't aware that this was possible. Nice work!<br>
>>>>>><br>
>>>>>> I'd be very interested in seeing how a Security Manager can be used to<br>
>>>>>> sandbox a class like this.<br>
>>>>>><br>
>>>>>> If you restrict it to elementary Objects such as String, Integer,<br>
>>>>>> Boolean, Float, etc, and Collection classes such as Map and List, I<br>
>>>>>> suspect that you should not be able to do too much damage. How would<br>
>>> you<br>
>>>>>> get a reference to the application code, anyway, to attack the<br>
>>>>>> application assets?<br>
>>>>>><br>
>>>>>> Rogan<br>
>>>>>><br>
>>>>>><br>
>>>>>> On 06/08/2013 14:38, Dinis Cruz wrote:<br>
>>>>>>> Hi, where you aware that XmlDecoder could be used this way:<br>
>>> <a href="http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html" target="_blank">http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html</a><br>
>>>>>>> (see<br>
>>>>>>> examples at the end)<br>
>>>>>>><br>
>>>>>>> Me and Abe presented that last week at DefCon and the awareness was<br>
>>> very<br>
>>>>>>> low.<br>
>>>>>>><br>
>>>>>>> I'm also sure that there are other dangerous/exploitable uses of<br>
>>>>>>> XmlDecoder on other REST or web apis.<br>
>>>>>>><br>
>>>>>>> Finally what about fixing/mitigating this? It looks like Java<br>
>>> Sandboxing<br>
>>>>>>> using the Security manager is one option, but even that will not be<br>
>>>>>>> safe, since the attacker will be able to attack the application<br>
>>> assets.<br>
>>>>>>><br>
>>>>>>> Any other ideas?<br>
>>>>>>><br>
>>>>>>> Dinis Cruz<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> OWASP-Leaders mailing list<br>
>>>>>>> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>>>>>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> OWASP-Leaders mailing list<br>
>>>>>> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>>>>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> OWASP-Leaders mailing list<br>
>>>>> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>>>>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
>>><br>
>>> _______________________________________________<br>
>>> Java-project mailing list<br>
>>> <a href="mailto:Java-project@lists.owasp.org">Java-project@lists.owasp.org</a><br>
>>> <a href="https://lists.owasp.org/mailman/listinfo/java-project" target="_blank">https://lists.owasp.org/mailman/listinfo/java-project</a><br>
>> _______________________________________________<br>
>> OWASP-Leaders mailing list<br>
>> <a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
>> <a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
><br>
><br>
> Dennis<br>
> --<br>
> [Dennis Groves](<a href="http://about.me/dennis.groves" target="_blank">http://about.me/dennis.groves</a>), MSc<br>
> [Email me](mailto:<a href="mailto:dennis.groves@owasp.org">dennis.groves@owasp.org</a>) or [schedule a meeting](<a href="http://goo.gl/8sPIy" target="_blank">http://goo.gl/8sPIy</a>).<br>
><br>
>    Unless someone like you...cares a whole awful lot...<br>
>    nothing is going to get better...It's not."<br>
>                                            -- The Lorax<br>
_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Phone: 703.727.4034<br>Web: <a href="http://profiles.google.com/m1spl4c3ds0ul" target="_blank">http://profiles.google.com/m1spl4c3ds0ul</a><br>Rss: <a href="http://feeds.feedburner.com/M1splacedOnTheWeb" target="_blank">http://feeds.feedburner.com/M1splacedOnTheWeb</a>
</div>