Heap-based buffer-overflow when decoding openjpeg image

[GoogleCodeExporter]

Hi Mathieu,

While fuzzing, i found another heap-based buffer-overflow, when decoding
an jpeg2000 file.

The affected file is enclosed.

$ /usr/local/bin/j2k_to_image -i test2.j2k -o test.ppm

[INFO] Start to read j2k main header (0).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Psot value of the current tile-part is equal to zero, we assuming
it is the last tile-part of the codestream.
[INFO] Header of tile 0 / 0 has been read.
ERROR -> j2k_to_image: failed to decode image!
Segmentation fault

Please credit:
"Huzaifa Sidhpurwala of Red Hat Security Response Team"

I have not had the time to investigate the issue and write a patch
for it. Feel free to commit a patch, when its ready.

Thanks!
-- 
Huzaifa Sidhpurwala / Red Hat Security Response Team

Original issue reported on code.google.com by antonin on 24 Aug 2012 at 3:25

Attachments:

• test2.j2k

[GoogleCodeExporter]

Kakadu does not decode the image neither but displays this message : 
--
Kakadu Core Error:
Illegal colour transform specified when image has insufficient or incompatible 
colour components.
--

Openjpeg should at least do the same and not segfault.

Original comment by antonin on 24 Aug 2012 at 3:27

[GoogleCodeExporter]

Note: Since this is a security issue it was assigned CVE-2012-3535
More details at:
http://seclists.org/oss-sec/2012/q3/300

Original comment by sidhpurw...@gmail.com on 27 Aug 2012 at 9:35

[GoogleCodeExporter]

Attaching another repro. this ones works with openjpeg-1.5

Original comment by sidhpurw...@gmail.com on 28 Aug 2012 at 5:16

Attachments:

• tst2.j2k

[GoogleCodeExporter]

The first file:
NAME(test2-1.j2k)
LENG(1855168)

ENTER read_jp2c
[0]marker(0xff4f)
    soc len(0)
[2]marker(0xff51)
    siz len(41)
    capabilities(0)
    x(0 : 1420) y(0 : 1416)
    xt(0 : 1420) yt(0 : 1416)
    nr_components(1)
      component[0]signed(0) prec(16) hsep(1) vsep(1)
[45]marker(0xff52)
    cod  len(12)
[59]marker(0xff5c)
    qcd  len(37)
[98]marker(0xff90)
    sot  tile_nr(0) Psot(1855056) TPsot(0) TNsot(1)
    len(10)
[110]marker(0xff93)
    sod  len(1855054)
[1855166]marker(0xd900)
MARKER 0xd900 is unknown. STOP.
EXIT read_jp2c
    end - s ==> 0
EXIT with end - s ==> 0

The second file:

NAME(test2-2.j2k)
LENG(5386885)

ENTER read_jp2c
[0]marker(0xff4f)
    soc len(0)
[2]marker(0xff51)
    siz len(47)
    capabilities(0)
    x(0 : 2592) y(0 : 1944)
    xt(0 : 640) yt(0 : 480)
    nr_components(3)
      component[0]signed(0) prec(8) hsep(1) vsep(1)
      component[1]signed(0) prec(8) hsep(1) vsep(1)
      component[2]signed(0) prec(8) hsep(1) vsep(1)
[51]marker(0xff52)
    cod  len(18)
[71]marker(0x300)
NEXT MARKER 0x4527 is unknown. STOP.
EXIT read_jp2c
    end - s ==> 0
EXIT with end - s ==> 0

winfried

Original comment by szukw...@arcor.de on 28 Aug 2012 at 10:32

[GoogleCodeExporter]

Are you saying that this does not crash for you?

Original comment by sidhpurw...@gmail.com on 30 Aug 2012 at 5:19

[GoogleCodeExporter]

Hi, 

Attaching a patch, which solves the problem for me.
There may be a more elegant way to deal with this issue, but i am not entirely 
familiar with the codebase.

Original comment by sidhpurw...@gmail.com on 3 Sep 2012 at 7:30

Attachments:

• openjpeg-buffer-overflow.patch

[GoogleCodeExporter]

It does not affect release 1.5.0 and branch 1.5 but for some reason was found 
in current dev branch.

Original comment by mathieu.malaterre on 10 Sep 2012 at 11:03

[GoogleCodeExporter]

This issue was closed by revision r1918.

Original comment by mathieu.malaterre on 10 Sep 2012 at 11:05

• Changed state: Fixed

[GoogleCodeExporter]

Actually tst2.j2k does break openjpeg 1.5.0 and release branch. re-opening.

Original comment by mathieu.malaterre on 10 Sep 2012 at 11:06

• Changed state: Accepted

[GoogleCodeExporter]

:)

Original comment by sidhpurw...@gmail.com on 10 Sep 2012 at 11:08

[GoogleCodeExporter]

This issue was closed by revision r1919.

Original comment by mathieu.malaterre on 10 Sep 2012 at 11:16

• Changed state: Fixed