Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 4 Aug 2010 15:12:33 -0400 (EDT)
From: "Steven M. Christey" <>
To: Dan Rosenberg <>
        "Steven M. Christey" <>
Subject: Re: CVE Request [two ids] -- cabextract -- 1, Infinite
  loop in MS-ZIP and Quantum decoders (minor) 2, Integer wrap-around (crash)
 by  processing certain *.cab files in test archive mode


Your proposal is a pretty good subset of my own perspective of when DoS 
becomes security-relevant (and I've been meaning to do some kind of 
CVE-related writeup on this, so thanks for the head start ;-)

There are a couple challenges in this area, though:

1) As Josh alluded to, I'm of the mindset of "better safe than sorry."
    If an advisory doesn't come in fully-cooked with root-cause analysis
    and clear research into the impact of the issue, you can't know what's
    going on under the hood.  Maybe there's some evidence of memory
    corruption, but the person doing the CVE assignment may not know that.

2) Item 1 below gets fuzzy when you're analyzing a piece of software you
    don't know yourself.  From a CVE assignment (and vuln database)
    perspective, that's impossible - typically we are dealing with 10-20
    different applications per day.  I don't know if MPEG-player X or
    Doc-converter Y can have multiple sessions or state at the same time.
    So the conservative approach is to include such issues.

3) Item 1 gets fuzzy *if* you consider scenarios in which the affected
    product is part of a chain of behaviors (say, a cron job) where a
    larger, critical task can fail if the program crashes.  Consider an
    image conversion utility that automatically makes thumbnails.  This is
    probably very important functionality for lots of image farms and
    social networking sites.

4) Your item 2 below gets fuzzy when you consider how much of a role the
    attacker has to have, i.e., how "user-assisted" the attack must be.
    I would say that if a victim sets up a chat session with an
    attacker, and the attacker can trigger a crash, that's valid (ignoring
    that item 1 would also apply in typical chat programs).  With
    everything being web-enabled with URL handlers these days, a
    conservative approach would be to assume (unless otherwise specified)
    that an attack only requires "reasonable" or typical actions on the
    part of a user.  For example - clicking on a link or a button in your
    web browser is reasonable behavior.

Fuzzing definitely throws a wrench into this whole thing, because of the 
large number of results and (usually) the lack of root-cause diagnosis. A 
couple years ago, I used to joke to myself that someday, somebody would 
figure out how to exploit NULL pointer dereferences.  Now that joke's not 
so funny anymore - granted, it's a limited scenario, but it's a clear 
demonstration that behavior once thought to be "safe" (from an 
exploitability standpoint) might be proven unsafe at a later time. 
Integer overflows, use-after-frees, double-frees, etc. have all been known 
for decades but only recently have they been demonstrated to be of 
significant security concern.

You are right about this all being a slippery slope.  From a CVE 
perspective, I am often concerned about the "snowball effect" of including 
certain types of issues, but in the case of client-side DoS, I think we 
just have to deal with the fact that client-side software has a very high 
attack surface and, in general, is less protected than server-side 
software (probably a reflection of the emphasis on server-side security in 
earlier years).

- Steve

On Mon, 2 Aug 2010, Dan Rosenberg wrote:

> This seems to be a bit of a slippery slope.  While I have no problem
> with these particular issues being assigned CVEs, since they were
> treated as security issues, fixed, and caused unintended application
> behavior, I have to wonder if maybe it's a bad idea to give CVEs for
> crashes of this variety.  Denial-of-service issues are tricky.  In my
> opinion, the following types of DoS bugs are security relevant:
> 1.  Crashes in client programs that maintain some additional state
> beyond a single session. For example, a document reader with multiple
> tabs where a crash results in losing the contents of other tabs, or a
> web browser.
> 2.  Issues that allow users to crash processes not under their own
> control.  This includes remote DoS vulnerabilities, kernel panics,
> crashes in services such as files that crash A/V engines when parsed,
> etc.
> 3.  Crashes in library code where many programs may be impacted.
> 4.  Crashes in client applications where further exploitability is
> possible (basically, promising memory corruption issues that haven't
> been fully developed).
> When you open it up to "anything that causes a crash", the pool of
> "security" bugs expands to include every fuzz file that causes a crash
> and every stability issue in every program.  For example, I have a
> high number of fuzz files that cause crashes in the readelf utility in
> non-exploitable ways.  I don't consider these relevant for security,
> because if you need to trick a user into running the program to
> trigger the crash and there are no additional consequences besides
> them crashing the program you tricked them into running, there is no
> negative security impact besides perhaps a confused victim.
> Although, I suppose my fourth item is the one that presents a problem
> - who gets to decide whether a program crash is exploitable or not?
> What if they're wrong?  Just trying to spur some discussion on this,
> I'd love to hear what others have to say - sometimes it's nice to
> break up all the CVE assignments with an actual conversation.  :)
> -Dan
> On Mon, Aug 2, 2010 at 4:08 PM, Josh Bressers <> wrote:
>> ----- "Jan Lieskovsky" <> wrote:
>>> Hi Steve, vendors,
>>>    two security issues have been reported against cabextract:
>>> 1, Infinite loop in MS-ZIP and Quantum decoders (minor issue):
>>> A deficiency has been reported in the way cabextract extracted certain
>>> Cabinet (*.cab) files, using the MZ-ZIP and Quantum decompressors.  If a
>>> local user was tricked into opening a specially-crafted *.cab file, it
>>> could lead to infinite loop.
>> CVE-2010-2800
>>> 2, Integer wrap-around (crash) by processing certain *.cab files in
>>> test archive mode
>>> An integer wrap-around flaw has been reported in the way cabextract
>>> processed certain Cabinet (*.cab) archive files. If a local user was
>>> tricked into opening a specially-crafted *.cab archive in test archive
>>> mode, it could lead to cabextract executable crash.
>> CVE-2010-2801
>> Thanks.
>> --
>>    JB

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.