Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAKG8Do7kM6n0Qzy6DkV+8y1SvzWYmp_S=bL6MekkLMEVcCP6dQ@mail.gmail.com>
Date: Mon, 20 Jun 2016 13:10:32 +0200
From: Cedric Buissart <cbuissar@...hat.com>
To: oss-security@...ts.openwall.com
Subject: CVE-2016-3189: bzip2 use-after-free on bzip2recover

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

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.