Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heap-buffer-overflow in opj_v4dwt_interleave_h #400

Closed
gcode-importer opened this issue Sep 17, 2014 · 11 comments
Closed

Heap-buffer-overflow in opj_v4dwt_interleave_h #400

gcode-importer opened this issue Sep 17, 2014 · 11 comments

Comments

@gcode-importer
Copy link

Originally reported on Google Code with ID 400

issue 414606: Heap-buffer-overflow in opj_v4dwt_interleave_h
    http://code.google.com/p/chromium/issues/detail?id=414606

Reported by detonin on 2014-09-17 09:12:27

@gcode-importer
Copy link
Author

Reported by detonin on 2014-09-17 09:17:09

  • Labels added: OpjVersion-2.x

@gcode-importer
Copy link
Author

Reproduced on trunk r2885

./bin/opj_decompress -i ../../data/issue400/0.jp2 -o 0.bmp

[INFO] Start to read j2k main header (119).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Header of tile 0 / 8 has been read.
Number of components (1) is inconsistent with a MCT. Skip the MCT step.
[INFO] Tile 1/9 has been decoded.
[INFO] Image data has been updated with tile 1.

[INFO] Header of tile 1 / 8 has been read.
Number of components (1) is inconsistent with a MCT. Skip the MCT step.
[INFO] Tile 2/9 has been decoded.
[INFO] Image data has been updated with tile 2.

[INFO] Header of tile 2 / 8 has been read.
Number of components (1) is inconsistent with a MCT. Skip the MCT step.
[INFO] Tile 3/9 has been decoded.
[INFO] Image data has been updated with tile 3.

[INFO] Header of tile 3 / 8 has been read.
Number of components (1) is inconsistent with a MCT. Skip the MCT step.
[INFO] Tile 4/9 has been decoded.
[INFO] Image data has been updated with tile 4.

[INFO] Header of tile 4 / 8 has been read.
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Expected SOP marker
Error : expected SOP marker
Not enough space for expected SOP marker
[INFO] Tile 5/9 has been decoded.
[INFO] Image data has been updated with tile 5.

[INFO] Header of tile 5 / 8 has been read.
=================================================================
==33817==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x03702f30 at pc
0x0078aa8e bp 0xbffa2168 sp 0xbffa2164
WRITE of size 4 at 0x03702f30 thread T0
    #0 0x78aa8d in opj_v4dwt_interleave_h /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/dwt.c:639:5
    #1 0x78990b in opj_dwt_decode_real /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/dwt.c:870:4
    #2 0x7f75fb in opj_tcd_dwt_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/tcd.c:1555:31
    #3 0x7f704b in opj_tcd_decode_tile /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/tcd.c:1242:20
    #4 0x7a3e17 in opj_j2k_decode_tile /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7796:15
    #5 0x7b8597 in opj_j2k_decode_tiles /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:9305:23
    #6 0x79ff27 in opj_j2k_exec /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7187:41
    #7 0x7a98b3 in opj_j2k_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:9496:15
    #8 0x7bfb7f in opj_jp2_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/jp2.c:1300:8
    #9 0x7caf63 in opj_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/openjpeg.c:412:10
    #10 0x6086c in main /Users/Matt/Dev/OpenJpeg/issue391/src/bin/jp2/opj_decompress.c:821:10
    #11 0x94511700 in start (/usr/lib/system/libdyld.dylib+0x3700)
    #12 0x4 (<unknown module>)

0x03702f30 is located 16 bytes to the right of 1696-byte region [0x03702880,0x03702f20)
allocated by thread T0 here:
    #0 0x2c5dba in wrap_malloc (/Users/Matt/Dev/llvm-clang-3.5.0-macosx-apple-darwin/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x2fdba)
    #1 0x789314 in opj_dwt_decode_real /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/dwt.c:845:26
    #2 0x7f75fb in opj_tcd_dwt_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/tcd.c:1555:31
    #3 0x7f704b in opj_tcd_decode_tile /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/tcd.c:1242:20
    #4 0x7a3e17 in opj_j2k_decode_tile /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7796:15
    #5 0x7b8597 in opj_j2k_decode_tiles /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:9305:23
    #6 0x79ff27 in opj_j2k_exec /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:7187:41
    #7 0x7a98b3 in opj_j2k_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/j2k.c:9496:15
    #8 0x7bfb7f in opj_jp2_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/jp2.c:1300:8
    #9 0x7caf63 in opj_decode /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/openjpeg.c:412:10
    #10 0x6086c in main /Users/Matt/Dev/OpenJpeg/issue391/src/bin/jp2/opj_decompress.c:821:10
    #11 0x94511700 in start (/usr/lib/system/libdyld.dylib+0x3700)
    #12 0x4 (<unknown module>)

SUMMARY: AddressSanitizer: heap-buffer-overflow /Users/Matt/Dev/OpenJpeg/issue391/src/lib/openjp2/dwt.c:639
opj_v4dwt_interleave_h
Shadow bytes around the buggy address:
  0x206e0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x206e05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x206e05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x206e05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x206e05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x206e05e0: 00 00 00 00 fa fa[fa]fa fa fa fa fa fa fa fa fa
  0x206e05f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x206e0600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x206e0610: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x206e0620: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x206e0630: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
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 right 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
  Container overflow:      fc
  ASan internal:           fe
==33817==ABORTING

Reported by mayeut on 2014-09-20 13:28:11

@gcode-importer
Copy link
Author

Matthieu,

Could you attach the JP2 image to the issue ?
Many thanks

Reported by detonin on 2014-09-22 22:15:40

@gcode-importer
Copy link
Author

Reported by mayeut on 2014-09-23 06:17:14


- _Attachment: [0.jp2](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-400/comment-4/0.jp2)_

@gcode-importer
Copy link
Author

+ cc Bo Xu from Foxit 

... so that you can follow what happens on these issues.

Reported by detonin on 2014-09-28 21:18:38

@gcode-importer
Copy link
Author

kdu_expand -i ../../data/issue400/0.jp2 -o 0.bmp
Kakadu Core Error:
Malformed COD marker segment encountered. Invalid "Scod" value!

Reported by mayeut on 2014-09-30 19:56:44

@gcode-importer
Copy link
Author

Patch tested against test suite : OK

./bin/opj_decompress -i ../../data/issue400/0.jp2 -o 0.bmp

[INFO] Start to read j2k main header (119).
[ERROR] Unknown Scod value in COD marker
[ERROR] Marker handler function failed to read the marker segment
ERROR -> opj_decompress: failed to read the header

Reported by mayeut on 2014-10-07 19:59:05

  • Status changed: Verified

- _Attachment: [issue400.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-400/comment-7/issue400.patch)_

@gcode-importer
Copy link
Author

Hi Matthieu, I'm reluctant to apply this one as the patch solves the symptom but not
the cause of the problem.

The corrupted J2K stream has several problems : one of them is an exotic value for
SCod ... Exotic but not illegal (as opposed to what KDU states). The SCod value is
sth like this : 0xRRRR RYYY and the decoder shall ignore the R bits, not throw an error
if sth different than 0 is found.

Ideally we should therefore ignore these bits and continue to decode the image, which
crashes in dwt.c (l.639). 

I might eventually apply the provided patch to be on the safe side but would like to
find the real origin of the buffer overflow described in this issue, as it does not
appear to be related to SCod.

Reported by detonin on 2014-10-14 16:21:27

  • Status changed: Started

@gcode-importer
Copy link
Author

Hi Antonin,

Regarding the exotic value for SCod, my understanding is that it's illegal. ISO 15444-1
Table A.13 states all other values are reserved thus "illegal" for that revision. If
future revisions introduces a new value, OpenJpeg will try to decode the codestream
under the assumption that it can & that might not be the case, leading to other vulnerabilities.

Feel free to explore other options. As you said, this patch solves the symptom only.

Reported by mayeut on 2014-10-14 18:08:48

@gcode-importer
Copy link
Author

Hi Matthieu,

In 15444-1 is written : 
Some marker segments have values assigned to groups of bits within a parameter. In
some cases there are bits, denoted by “x,” that are not assigned a value for any field
within a parameter. The codestream shall contain a value of zero for all such bits.
The decoder shall ignore these bits.

So you're right, exotic values for SCod are illegal. I will apply the patch.
My main point in my previous comment was that the overflow was not due to this illegal
SCod value and that there might be another vulnerability to fix (probably somewhere
in dwt.c). I'll create a new issue with this and attach the same codestream with a
correct SCod value.

Thanks again for all the work !

Reported by detonin on 2014-10-15 08:44:42

@gcode-importer
Copy link
Author

This issue was closed by revision r2900.

Reported by detonin on 2014-10-15 08:48:25

  • Status changed: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants