Re: Handling cases of CWE-776

[Tim Brown <tmb () 65535 com>]

On Wednesday 28 October 2009 10:38:16 Marcus Meissner wrote:
> On Wed, Oct 28, 2009 at 12:02:40AM +0000, Tim Brown wrote:
> > All,
> >
> > How are problems with XML bombs (the so called "billion laughs" attack)
> > being handled?  Should I be filing such bugs against the applications
> > that exposes the XML parser to user input or is it better to report the
> > issue against the parser themselves.  For example, the test case I've
> > prepared for one affected parser simply causes the CPU to spin but the
> > system appears to stay responsive (so far ;)).  Is it even fair to call
> > such a denial of service? (If the code was executed in a real
> > application, no further processing would happen within the affected
> > process as the parser is tied up in memmove()s). I'm just curious as I
> > don't want to waste peoples time with the disclosure process if others
> > are simply filing "standard" bugs against affected parsers and moving on
> > to more interesting matters.
>
> If an application can be made unresponsive this way it would still be
> a denial of service against this app, so Yes.
>
> It always should however be checked if the application can get this data
> from a real life attacker or if a admin user needs to push it in. For the
> latter it is not DoS in my eyes.

So my PoC just calls the parser library directly, but on calling the API to 
take the XML, the binary just sits there, gradually consuming more and more 
memory.  I left it over night and it was still processing the following 
morning, but RAM consumption had doubled.  The host itself was still 
perfectly responsive despite this.  I've seen one example already of code 
that takes in a POST request and drops XML body straight into the parser API 
which would allow you to lockup that the process handling the POST but I 
guess it depends on the design of the various calling applications what 
exactly the effect will be even though the root of the problem is the parser 
library and not the applications themselves.

Tim
-- 
Tim Brown
<mailto:tmb () 65535 com>