oss-sec mailing list archives

Re: Handling cases of CWE-776


From: "Steven M. Christey" <coley () linus mitre org>
Date: Mon, 9 Nov 2009 20:45:36 -0500 (EST)


On Wed, 28 Oct 2009, Tim Brown wrote:

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).

If it's a specific parser/library, then it has a special responsibility to
avoid DoSing its callers.  Kind of like having a library that exits the
entire process when it encounters an error (hello libgssapi/CVE-2007-5471
and MSVCR80.DLL/CVE-2007-0842).

From a CVE perspective, if an application uses the vulnerable library,
then it shouldn't get its own CVE.

In the case of XML bomb, there is very little effort required to generate
massive consumption, so I'm comfortable with assigning CVEs to them.  The
notion of asymmetric effort seems important to resource consumption at
this point.

However, I am nervous about resource-exhaustion DoS problems in general,
for the long-term implications.  They are design-level problems and can be
very difficult to fix; if you're a library, then you may require an API
change, thus affecting all your callers; and it's not like there's a
hard-and-fast rule about how much CPU or memory you have to consume before
resource consumption becomes a DoS instead of just a bug or feature.
(I'm still not sure whether trying to load the CVE XML into any browser
should count as a DoS; it doesn't feel like a 45-meg file should require
500+ meg and full CPU consumption to render.  Don't try this at home
though ;-))

I suspect resource exhaustion issues are everywhere, so at some time we
may reach a tipping point where vulnerability analysts - including vendors
and databases - get slammed with zillions of DoS issues.  Such issues
*should* be fixed, and I'm not discouraging people from disclosing them,
but we should try not to be too surprised if/when the deluge comes.

- Steve


Current thread: