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

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

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: openjpeg2: CVE-2017-14039: Heap-based buffer overflow in opj_t2_encode_packet function in lib/openjp2/t2.c

Date: Sun, 03 Sep 2017 15:34:38 +0200

Source: openjpeg2
Version: 2.1.0-2
Severity: important
Tags: patch upstream security
Forwarded: https://github.com/uclouvain/openjpeg/issues/992

Hi,

the following vulnerability was published for openjpeg2.

CVE-2017-14039[0]:
| A heap-based buffer overflow was discovered in the opj_t2_encode_packet
| function in lib/openjp2/t2.c in OpenJPEG 2.2.0. The vulnerability
| causes an out-of-bounds write, which may lead to remote denial of
| service or possibly unspecified other impact.

The issue is covered by [3], so trying to reproduce the issue leads to
an assertion failure up to the version in sid instead.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-14039
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14039
[1] https://github.com/uclouvain/openjpeg/issues/992
[2] https://github.com/uclouvain/openjpeg/commit/c535531f03369623b9b833ef41952c62257b507e
[3] https://github.com/uclouvain/openjpeg/commit/4241ae6fbbf1de9658764a80944dc8108f2b4154

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Message #16 received at 874118-submitter@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: control@bugs.debian.org

Cc: 874118-submitter@bugs.debian.org

Subject: closing 874118

Date: Mon, 16 Oct 2017 13:20:04 +0200

close 874118 2.3.0-1
thanks

Message #21 received at 874118@bugs.debian.org (full text, mbox, reply):

From: Mathieu Malaterre <malat@debian.org>

To: 874118@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>

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

Date: Mon, 16 Oct 2017 18:12:30 +0200

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.

Message #26 received at 874118@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Mathieu Malaterre <malat@debian.org>, 874118@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>

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

Date: Mon, 16 Oct 2017 19:12:07 +0200

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

Message #31 received at 874118@bugs.debian.org (full text, mbox, reply):

From: Mathieu Malaterre <malat@debian.org>

To: Salvatore Bonaccorso <carnil@debian.org>

Cc: 874118@bugs.debian.org, Debian Security Team <team@security.debian.org>

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

Date: Mon, 16 Oct 2017 21:22:41 +0200

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 <carnil@debian.org> 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

Send a report that this bug log contains spam.