Bug 82635 (CVE-2005-1260)

Created attachment 36472 [details]
CESA-2005-002.txt

Date: Thu, 5 May 2005 11:04:56 +0100 
From: Julian Seward <jseward@acm.org> 
To: chris@scary.beasts.org 
Cc: vendor-sec@lst.de 
Subject: [vendor-sec] Re: bzip2 security bug: decompression bomb 
User-Agent: KMail/1.8 
X-Spam-Level: 
 
 
Hi. 
 
> I've found a security bug in bzip2. It's a decompression bomb (these seem 
> to be quite "trendy" at the moment). 
> 
> Full details are here: 
> http://scary.beasts.org/security/d5d5466da311d907/CESA-2005-002.txt 
 
This is already fixed in 1.0.3, which I released a couple of months 
back.  You can get it from www.bzip.org.  The real problem is that 
nobody seems to have noticed that 1.0.3 is available, despite it 
being announced in the usual places. That might be due to the fact 
that I so far failed to kill off http://sources.redhat.com/bzip2 in 
favour of www.bzip.org. I will try again to contact the 
sources.redhat.com overseers. 
 
 
bzip2-1.0.3/CHANGES: 
 
   1.0.3 (15 Feb 05) 
   ~~~~~~~~~~~~~~~~~ 
   Fixes some minor bugs since the last version, 1.0.2. 
 
   * Further robustification against corrupted compressed data. 
     There are currently no known bitstreams which can cause the 
     decompressor to crash, loop or access memory which does not 
     belong to it.  If you are using bzip2 or the library to 
     decompress bitstreams from untrusted sources, an upgrade 
     to 1.0.3 is recommended. 
 
   * The documentation has been converted to XML, from which html 
     and pdf can be derived. 
 
   * Various minor bugs in the documentation have been fixed. 
 
   * Fixes for various compilation warnings with newer versions of 
     gcc, and on 64-bit platforms. 
 
   * The BZ_NO_STDIO cpp symbol was not properly observed in 1.0.2. 
     This has been fixed. 
 
 
1.0.3 handles your file properly: 
 
   sewardj@phoenix:~$ ./Bz103/bzip2-src/trunk/bzip2-103-x86-linux26 
    -tvv ./bomb.bz2 
     ./bomb.bz2: 
       [1: huff+mtf rt+rlddata integrity (CRC) error in data 
 
1.0.2 does indeed loop: 
 
   sewardj@phoenix:~$ /usr/bin/bzip2 -tvv ./bomb.bz2 
     ./bomb.bz2: 
       [1: huff+mtf rt+rld 
   bzip2: Control-C or similar caught, quitting. 
 
J 
_______________________________________________ 
Vendor Security mailing list 
Vendor Security@lst.de 
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec 
 

Created attachment 37059 [details]
patch extracted by Josh Bressers related to the changelog entry "Further robustification against corrupted compressed data"

Applying the patch is enough, right?

Created attachment 37120 [details]
bomb.bz2

Yes, I just verified it's the diff 1.0.2->1.0.3 without useless noise

Should this go to SLES9 SP2 or be released as regular security fix?

fixes submited

SM-Tracker-1210 
 
I'll ask gp wrt SP2 

You generally don't need to explicitely submit packages for SP2 if they are 
not specifically contained in SP2. bzip2 is not. 

To: Josh Bressers <bressers@redhat.com>
Cc: vendor-sec@lst.de
Subject: Re: [vendor-sec] Re: bzip2 security bug: decompression bomb 

Hi,

On Thu, 19 May 2005, Josh Bressers wrote:

> > I did some digging, here's the 1.0.2 -> 1.0.3 patch which applies to this
> > behavior.
>
> Chris,
>
> Do you plan on making your advisory public anytime soon?  This issue is
> already public and fixed upstream.  I'm writing our errata for this and
> would like to link to your advisory.

All my advisories go to http://scary.beasts.org/security. I've added the
bzip2 one as all the advisories have started coming out.

Argh, why did Josh Bressers change the max hufman length from 20 to 17 in 
bzip-1.0.2? This breaks deltarpms. Ok if we just remove the two hunks from the 
patch? 

It's not Josh Bressers invention. It was changed upstream in 1.0.3. 

I know that it's in 1.0.3. But why put it back into 1.0.2 if it doesn't have 
any security impact? 
Again: ok if we remove the two hunks? 

The comment in huffman.c suggests that it could make the decoder run into an 
infinite loop which would be a problem for e.g. mail virus scanners. If that 
is not the case we can remove the offending hunks but we should tell the other 
vendors as well then. 

No, the comment is about a bug in the decoder which made it loop if the 
maximum huffman length is used. I'm talking about the changes in the 
*encoder*, which reduce the max length from 20 to 17. 

Marcus just told me what you mean :-) Let's remove the hunks. 

packages released  

CVE-2005-1260: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)