[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200910281236.59998.tmb@65535.com>
Date: Wed, 28 Oct 2009 12:36:58 +0000
From: Tim Brown <tmb@...35.com>
To: oss-security@...ts.openwall.com
Subject: Re: Handling cases of CWE-776
On Wednesday 28 October 2009 12:03:57 Tim Brown wrote:
> 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.
Doh! Just realised that that "expat bug 1990430" thread earlier essentially
covers the case I'm looking at. For the purposes of shutting down this
thread, the library I was seeing the problem with is Perl's XML::Simple
(which is using expat here).
Case closed,
Tim
--
Tim Brown
<mailto:tmb@...35.com>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
