The bzexe command in bzip2 1.0.5 and earlier generates compressed executables that do not properly handle temporary files during extraction, which allows local users to execute arbitrary code by precreating a temporary directory.

BZ2decompress in decompress.c in bzip2 through 1.0.6 has an out-of-bounds write when there are many selectors.

A heap use after free vulnerability was reported in bzip2recover. A maliciously crafted file could cause the application to crash.

Proposed patch attached.

== ASAN output & backtrace == bzip2recover 1.0.6: extracts blocks from damaged .bz2 files. /opt/bzip-asan/bin/bzip2recover: searching for block boundaries ... block 1 runs from 176 to 175 block 2 runs from 224 to 871 block 3 runs from 920 to 919 block 4 runs from 968 to 1024 (incomplete) bzip2recover: splitting into blocks writing block 2 to crasherfile1' ... Program received signal SIGSEGV, Segmentation fault. ================================================================= ==8476== ERROR: AddressSanitizer: heap-use-after-free on address 0x60060000ef8c at pc 0x40277c bp 0x7fff7f1afe90 sp 0x7fff7f1afe80 READ of size 4 at 0x60060000ef8c thread T0 #0 0x40277b (/opt/bzip-asan/bin/bzip2recover+0x40277b) #1 0x401f35 (/opt/bzip-asan/bin/bzip2recover+0x401f35) #2 0x7f10fcae2af4 (/usr/lib64/libc-2.17.so+0x21af4) #3 0x4020e4 (/opt/bzip-asan/bin/bzip2recover+0x4020e4) 0x60060000ef8c is located 12 bytes inside of 24-byte region [0x60060000ef80,0x60060000ef98) freed by thread T0 here: #0 0x7f10fce98009 (/usr/lib64/libasan.so.0.0.0+0x16009) #1 0x40205c (/opt/bzip-asan/bin/bzip2recover+0x40205c) previously allocated by thread T0 here: #0 0x7f10fce98129 (/usr/lib64/libasan.so.0.0.0+0x16129) #1 0x40175f (/opt/bzip-asan/bin/bzip2recover+0x40175f) Shadow bytes around the buggy address: 0x0c013fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c013fff9df0: fd[fd]fd fa fa fa 00 00 00 fa fa fa fd fd fd fa 0x0c013fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe

bt #0 0x00007ffff7a8fa11 in putc () from /lib64/libc.so.6 #1 0x00000000004046ad in bsPutBit (bit=0x0, bs=<optimized out>) at bzip2recover.c:183 #2 bsPutUChar (c=<optimized out>, bs=<optimized out>) at bzip2recover.c:246 #3 main (argc=<optimized out>, argv=<optimized out>) at bzip2recover.c:455 #4 0x00007ffff7a3caf5 in libcstartmain () from /lib64/libc.so.6 #5 0x0000000000405bd9 in start ()

bzip2 before 1.0.2 in FreeBSD 4.5 and earlier, OpenLinux 3.1 and 3.1.1, and possibly systems, uses the permissions of symbolic links instead of the actual files when creating an archive, which could cause the files to be extracted with less restrictive permissions than intended.

bzip2 before 1.0.2 in FreeBSD 4.5 and earlier, OpenLinux 3.1 and 3.1.1, and possibly other operating systems, does not use the OEXCL flag to create files during decompression and does not warn the user if an existing file would be overwritten, which could allow attackers to overwrite files via a bzip2 archive.

Race condition in bzip2 before 1.0.2 in FreeBSD 4.5 and earlier, OpenLinux 3.1 and 3.1.1, and possibly other operating systems, decompresses files with world-readable permissions before setting the permissions to what is specified in the bzip2 archive, which could allow local users to read the files as they are being decompressed.

bzip2 allows remote attackers to cause a denial of service (hard drive consumption) via a crafted bzip2 file that causes an infinite loop (a.k.a "decompression bomb").

Race condition in bzip2 1.0.2 and earlier allows local users to modify permissions of arbitrary files via a hard link attack on a file while it is being decompressed, whose permissions are changed by bzip2 after the decompression is complete.

bzlib.c in bzip2 before 1.0.5 allows user-assisted remote attackers to cause a denial of service (crash) via a crafted file that triggers a buffer over-read, as demonstrated by the PROTOS GENOME test suite for Archive Formats.

Common Vulnerabilities and Exposures assigned an identifier CVE-2009-1884 to the following vulnerability:

Off-by-one error in the bzinflate function in Bzip2.xs in the Compress-Raw-Bzip2 module before 2.018 for Perl allows context-dependent attackers to cause a denial of service (application hang or crash) via a crafted bzip2 compressed stream that triggers a buffer overflow, a related issue to CVE-2009-1391.

References: ----------- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1884 https://bugs.gentoo.org/showbug.cgi?id=281955 https://bugs.gentoo.org/showbug.cgi?id=281955

A bzip2 security issue was reported to Debian security team:

Mikołaj Izdebski has discovered an integer overflow flaw in the BZ2decompress function in bzip2/libbz2. An attacker could use a crafted bz2 file to cause a denial of service (application crash) or potentially to execute arbitrary code. (CVE-2010-0405)