Bugzilla – Bug 82635
VUL-0: CVE-2005-1260: bzip2 decompression bomb
Last modified: 2021-11-04 16:08:35 UTC
We received the following report via vendor-sec. This issue is not public yet, please keep any information about it inside SUSE. CAN-2005-1260 Date: Thu, 5 May 2005 03:53:43 +0100 (BST) From: chris@scary.beasts.org To: vendor-sec@lst.de, jseward@acm.org, Julian_Seward@muraroa.demon.co.uk Subject: [vendor-sec] bzip2 security bug: decompression bomb 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 The issue is not disclosed and not linked to. I have not set a disclosure date; it will be when the fix is available and deployed, i.e. fix at your leisure with no time pressure :-) Cheers Chris _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
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)