[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.51.0911092030480.4011@faron.mitre.org>
Date: Mon, 9 Nov 2009 20:45:36 -0500 (EST)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: oss-security@...ts.openwall.com
Subject: Re: Handling cases of CWE-776
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
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.
