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

Dinis Cruz dinis.cruz at owasp.org
Wed Aug 7 00:25:09 UTC 2013


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20130807/5f330858/attachment-0001.html>


More information about the OWASP-Leaders mailing list