Bug#874118: CVE-2017-14039: Heap-based buffer overflow in opj_t2_encode_packet function in lib/openjp2/t2.c

[Mathieu Malaterre]

Hi Salvatore,

This is the second time you /saved/ me (sorry for my limited Spanish) :)

On Mon, Oct 16, 2017 at 7:12 PM, Salvatore Bonaccorso  wrote:
> Hello Mathieu,
>
> On Mon, Oct 16, 2017 at 06:12:30PM +0200, Mathieu Malaterre wrote:
>> Control: severity -1 important
>>
>> While I understand the this generic heap based buffer overflow ought
>> to be fixed in Debian stable, I fail to see why it is marked as
>> affecting stretch.
> [...]
>
>
> In my initial report I wrote: "The issue is covered by [3], so trying
> to reproduce the issue leads to an assertion failure up to the version
> in sid instead."
>
> My point was, yes if you try to reproduce with current version you
> will reach the assertion, because it's yet covered by the missing
> commit 4241ae6fbbf1de9658764a80944dc8108f2b4154. Applying that as well
> shows the underlying issue.

Indeed I missed your carefully written bug report(s). Can't believe I
could not use one of those fancy AI to figure out the
whitespace/indent changes to merge those original commits.

Anyway I've manually fixed all those. Pushed +deb9u2 a moment ago.

Thanks again for your bug report(s) they contained all the details needed.

-M

Bug#874118: CVE-2017-14039: Heap-based buffer overflow in opj_t2_encode_packet function in lib/openjp2/t2.c

[Salvatore Bonaccorso]

Hello Mathieu,

On Mon, Oct 16, 2017 at 06:12:30PM +0200, Mathieu Malaterre wrote:
> Control: severity -1 important
> 
> While I understand the this generic heap based buffer overflow ought
> to be fixed in Debian stable, I fail to see why it is marked as
> affecting stretch.
[...]


In my initial report I wrote: "The issue is covered by [3], so trying
to reproduce the issue leads to an assertion failure up to the version
in sid instead."

My point was, yes if you try to reproduce with current version you
will reach the assertion, because it's yet covered by the missing
commit 4241ae6fbbf1de9658764a80944dc8108f2b4154. Applying that as well
shows the underlying issue.

Hope this helps!

Regards,
Salvatore

Bug#874118: CVE-2017-14039: Heap-based buffer overflow in opj_t2_encode_packet function in lib/openjp2/t2.c

[Mathieu Malaterre]

Control: severity -1 important

While I understand the this generic heap based buffer overflow ought
to be fixed in Debian stable, I fail to see why it is marked as
affecting stretch.

Here is what I see:

$ bin/opj_compress -r 20,10,1 -jpip -EPH -SOP -cinema2K 24 -n 1 -i
/tmp/00322-openjpeg-heapoverflow-opj_t2_encode_packet.tif -o null.j2k
CINEMA 2K profile activated
Other options specified could be overridden

TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are
not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 27154 (0x6a12) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 32512 (0x7f00) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 15163 (0x3b3b) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 15318 (0x3bd6) encountered.
TIFFFetchNormalTag: Warning, Incorrect count for "FillOrder"; tag ignored.
TIFFReadDirectory: Warning, TIFF directory is missing required
"StripByteCounts" field, calculating from imagelength.
WARNING:
Input image bitdepth is 4 bits
TIF conversion has automatically rescaled to 12-bits
to comply with cinema profiles.
[WARNING] JPEG 2000 Profile-3 and 4 (2k/4k dc profile) requires:
1 single quality layer-> Number of layers forced to 1 (rather than 3)
opj_compress: 
/home/mathieu/debian/openjpeg2/sec/openjpeg2-2.1.2/src/lib/openjp2/j2k.c:6672:
opj_j2k_setup_encoder: Assertion `res_spec>0' failed.
-> Rate of the last layer (1.0) will be used[1]22262 abort
bin/opj_compress -r 20,10,1 -jpip -EPH -SOP -cinema2K 24 -n 1 -i  -o
null.j2k


So the code describe in the bug report is not even reached.

Downgrading to severity important.