[Owasp-leaders] [Java-project] Using XMLDecoder to execute server-side Java Code on an Restlet application (i.e. Remote Command Execution)

Jim Manico jim.manico at owasp.org
Wed Aug 7 05:01:50 UTC 2013


I was hoping a whitelist approach within schema validation would work
(ie: only allow construction of safe business-domain classes in the
dangerous API's) but I agree it's unlikely to work practically.

"Avoid using this with untrusted data" seems like the best advice so far.

--
Jim Manico
@Manicode
(808) 652-3805

On Aug 6, 2013, at 5:30 PM, Dennis Groves <dennis.groves at owasp.org> wrote:

> Interesting policy - however, attackers don't follow policy. ;-)
> 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?
>
> Dennis
>
> On 6 Aug 2013, at 17:14, Dinis Cruz wrote:
>
>> I think that the solution is not to use it at all. The scenarios where this
>> API can be used safely and very small, and even then, that application's
>> security would be entirety dependent on the integrity of the XML files used
>>
>> What we really need now is Static Analysis rules to quickly identify the
>> uses of this API and help the developers understand its risk (and ideally
>> to replaced it with a safer API).
>>
>> I would be good if we also could find a way to fingerprint this issue from
>> a BlackBox point of view, so that PenTesters could look for it.
>>
>>
>> Dinis Cruz
>>
>> Blog: http://diniscruz.blogspot.com
>> Twitter: http://twitter.com/DinisCruz
>> Web: http://www.owasp.org/index.php/O2
>>
>>
>> On 6 August 2013 20:31, Jim Manico <jim.manico at owasp.org> wrote:
>>
>>> The Java security manager runtime permissions have no management
>>> software available and often break functionality that these libraries
>>> depend on to run. I still think schema validation is in order. I'll dig
>>> a little deeper into this (from a defense perspective) and get back to
>>> you on this.
>>>
>>> Cheers,
>>> Jim
>>>
>>>
>>>> Policy file runtime permissions may help in restricting execution of
>>> rogue code. Most containers have them.
>>>> Nice work btw
>>>>
>>>> Eoin Keary
>>>> Owasp Global Board
>>>> +353 87 977 2988
>>>>
>>>>
>>>> On 6 Aug 2013, at 19:39, Jim Manico <jim.manico at owasp.org> wrote:
>>>>
>>>>> You normally want to do structural validation of untrusted XML before
>>>>> you accept it (using XML schema or the like). Such defenses if
>>>>> implemented right should protect you from this kind of vulnerability.
>>>>>
>>>>> But wow, very interesting work.
>>>>>
>>>>> Cheers,
>>>>> Jim
>>>>>
>>>>>
>>>>>> I wasn't aware that this was possible. Nice work!
>>>>>>
>>>>>> I'd be very interested in seeing how a Security Manager can be used to
>>>>>> sandbox a class like this.
>>>>>>
>>>>>> If you restrict it to elementary Objects such as String, Integer,
>>>>>> Boolean, Float, etc, and Collection classes such as Map and List, I
>>>>>> suspect that you should not be able to do too much damage. How would
>>> you
>>>>>> get a reference to the application code, anyway, to attack the
>>>>>> application assets?
>>>>>>
>>>>>> Rogan
>>>>>>
>>>>>>
>>>>>> On 06/08/2013 14:38, Dinis Cruz wrote:
>>>>>>> Hi, where you aware that XmlDecoder could be used this way:
>>> http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html
>>>>>>> (see
>>>>>>> examples at the end)
>>>>>>>
>>>>>>> Me and Abe presented that last week at DefCon and the awareness was
>>> very
>>>>>>> low.
>>>>>>>
>>>>>>> I'm also sure that there are other dangerous/exploitable uses of
>>>>>>> XmlDecoder on other REST or web apis.
>>>>>>>
>>>>>>> Finally what about fixing/mitigating this? It looks like Java
>>> Sandboxing
>>>>>>> using the Security manager is one option, but even that will not be
>>>>>>> safe, since the attacker will be able to attack the application
>>> assets.
>>>>>>>
>>>>>>> Any other ideas?
>>>>>>>
>>>>>>> Dinis Cruz
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OWASP-Leaders mailing list
>>>>>>> OWASP-Leaders at lists.owasp.org
>>>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>>
>>>>>> _______________________________________________
>>>>>> OWASP-Leaders mailing list
>>>>>> OWASP-Leaders at lists.owasp.org
>>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>>>
>>>>> _______________________________________________
>>>>> OWASP-Leaders mailing list
>>>>> OWASP-Leaders at lists.owasp.org
>>>>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>>
>>> _______________________________________________
>>> Java-project mailing list
>>> Java-project at lists.owasp.org
>>> https://lists.owasp.org/mailman/listinfo/java-project
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
> Dennis
> --
> [Dennis Groves](http://about.me/dennis.groves), MSc
> [Email me](mailto:dennis.groves at owasp.org) or [schedule a meeting](http://goo.gl/8sPIy).
>
>    Unless someone like you...cares a whole awful lot...
>    nothing is going to get better...It's not."
>                                            -- The Lorax


More information about the OWASP-Leaders mailing list