oss-sec mailing list archives

CVE-2016-3189: bzip2 use-after-free on bzip2recover


From: Cedric Buissart <cbuissar () redhat com>
Date: Mon, 20 Jun 2016 13:10:32 +0200

Hi all,

This is to report CVE-2016-3189: bzip2 use-after-free on bzip2recover

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

Originally reported by Aladdin Mubaied

For additional information & proposed patch:
https://bugzilla.redhat.com/show_bug.cgi?id=1319648

== 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 __libc_start_main () from /lib64/libc.so.6
#5  0x0000000000405bd9 in _start ()

Regards,

-- 
Cedric Buissart,
Product Security

Current thread: