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

Eoin eoin.keary at owasp.org
Wed Aug 7 09:04:00 UTC 2013


This is a good candidate for the compiler to issue a warning if such API's
are being used. similar to dynamic SQL and wek crypto MD5 etc etc.




On 7 August 2013 01:25, Dinis Cruz <dinis.cruz at owasp.org> wrote:

> I agree, I this is one of those cases where we need a Software/API Label<http://www.slideshare.net/DinisCruz/2010-11-owaspsoftwarelabels> saying:
> "*Don't use this for web data*"
>
> In fact I think we should say "*Don't use this, unless you are really
> sure about the integrity and source of the XML files used)*
>
>
> Dinis Cruz
>
> Blog: http://diniscruz.blogspot.com
> Twitter: http://twitter.com/DinisCruz
> Web: http://www.owasp.org/index.php/O2
>
>
> On 6 August 2013 22:20, Stephen de Vries <stephen at continuumsecurity.net>wrote:
>
>>
>> On 6 Aug 2013, at 22:38, Jim Manico wrote:
>>
>> > I noticed Denis' blog post said "We are not sure how to fix this". :) I
>> > don't blame you, this is a tough problem. I would like to fix the
>> > underlying problem, but that would "kill the entire mechanism".
>>
>> I don't think there's anything to fix here, except the docs and to
>> emphasise the risks to developers.
>> Simply don't use XMLDecoder with any data that comes from an untrusted
>> location.  Use Jaxb or xmlbeans etc.
>>
>>
>>
>> stephen
>>
>> >
>> >
>> >
>> >> Remember that you can insert the exploit code even after the valid xml.
>> >>
>> >> Also want to clarify that Dennis, Alvaro and I worked very hard over
>> the
>> >> past year researching, reading and testing REST APIs to find these
>> types of
>> >> vulnerabilities.
>> >>
>> >> Regards,
>> >> Abe
>> >>
>> >>
>> >> On Tue, Aug 6, 2013 at 12:31 PM, 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
>> >>>
>> >>> _______________________________________________
>> >>> 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
>>
>> _______________________________________________
>> Java-project mailing list
>> Java-project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/java-project
>>
>
>


-- 
Eoin Keary
OWASP Member
https://twitter.com/EoinKeary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130807/5493f7f1/attachment-0001.html>


More information about the OWASP-Leaders mailing list