Bug 1319648 (CVE-2016-3189) - CVE-2016-3189 bzip2: heap use after free in bzip2recover
Summary: CVE-2016-3189 bzip2: heap use after free in bzip2recover
Status: CLOSED WONTFIX
Alias: CVE-2016-3189
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=low,public=20160620,reported=2...
Keywords: Security
Depends On: 1348181 1348179 1348180
Blocks: 1319653
TreeView+ depends on / blocked
 
Reported: 2016-03-21 09:17 UTC by Andrej Nemec
Modified: 2016-07-03 09:18 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A use-after-free flaw was found in bzip2recover, leading to a null pointer dereference, or a write to a closed file descriptor. An attacker could use this flaw by sending a specially crafted bzip2 file to recover and force the program to crash.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-20 12:56:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch, by Jakub Martisko (468 bytes, patch)
2016-06-20 10:46 UTC, Cedric Buissart 🐶
no flags Details | Diff

Description Andrej Nemec 2016-03-21 09:17:22 UTC
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 __libc_start_main () from /lib64/libc.so.6
#5  0x0000000000405bd9 in _start ()

Comment 1 Andrej Nemec 2016-03-21 09:18:01 UTC
Acknowledgments:

Name: Aladdin Mubaied

Comment 4 Cedric Buissart 🐶 2016-06-20 10:46 UTC
Created attachment 1169843 [details]
Proposed patch, by Jakub Martisko

Comment 5 Cedric Buissart 🐶 2016-06-20 10:47:39 UTC
== Analysis from Jakub Martisko == 

During the first phase (where the program identifies starts and ends of the blocks), blockEnd of the first block is set to be blockStart-1. Similarly for block 3. During the second phase, the first block is ignored (it is not long enough), the second block is recovered correctly and the third one leads to crash. The cause of crash is, that because the end of this block is set to be one bit before its start, it tries to write the end stream sequence (sqrt(PI)....), however since it writes its end before the start, no file is opened and this leads to crash. Problem is, that after closing the output file, the second block does not set variable "outFile" to NULL. Third block then checks this variable and because it is not NULL, it tries to write to the output stream, which was closed with bsClose(). As for the fix, it seems to be enough to add "outFile=NULL;" to the end of block that is responsible for creation of the end of stream sequence (patch attached).

Comment 7 Cedric Buissart 🐶 2016-06-20 10:57:46 UTC
Created bzip2 tracking bugs for this issue:

Affects: fedora-all [bug 1348179]

Comment 8 Cedric Buissart 🐶 2016-06-20 10:57:51 UTC
Created mingw-bzip2 tracking bugs for this issue:

Affects: fedora-all [bug 1348180]
Affects: epel-7 [bug 1348181]

Comment 9 Cedric Buissart 🐶 2016-06-20 12:55:55 UTC
Statement:

Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.


Note You need to log in before you can comment on or make changes to this bug.