Integer overflow in opj_t1_encode_cblks (src/lib/openjp2/t1.c)

[ProbeFuzzer]

(This problem is discovered when UBSAN is enabled)

on openjpeg 2.3 (latest version):
there is a integer overflow in the opj_t1_encode_cblks function (src/lib/openjp2/t1.c), which could be triggered by the POC.

POC address: https://github.com/ProbeFuzzer/poc/blob/master/openjpeg/openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp

Command: opj_compress -n 1 -i $POC -o /tmp/null.j2k
openjpeg/master/src/src/lib/openjp2/t1.c:2173:55: runtime error: signed integer overflow: 322385710 * 64 cannot be represented in type 'int'

[kevien]

mark

[carnil]

This issue was assigned CVE-2018-5727

[hlef]

cf. PR #757.

I see two distinct issues here.

First issue:

This reproducer triggers a bug earlier, in src/bin/jp2/convertbmp.c (bmpmask32toimage):

 227             image->comps[2].data[index] = (OPJ_INT32)((value & blueMask)  >>
 228                                           blueShift);  /* B */

Here, value is 2148742123 and blueMask is 3958107120 so value & blueMask (type OPJ_UINT32, 2147689440) becomes -2147277856 when cast to OPJ_INT32.

These values are legit according to the BMP spec.

This cast seems incorrect to me if value & blueMask > INT_MAX.

Question: What is the meaning of negative data values in opj_image_comp_t ? / what is the expected format of data values in opj_image_comp_t ?

Second issue:

2173    tiledp[tileIndex] *= 1 << T1_NMSEDEC_FRACBITS;

The original code assumed that the first T1_NMSEDEC_FRACBITS (6) bits of tiledp[tileIndex] are all zero.

I don't understand this assumption. This is wrong in several cases, e.g. when tiledp[tileIndex] is negative.

The changes introduced by PR #757 didn't fix the actual issue, namely that something wrong is assumed about the format or value of tiledp[tileIndex].

[lidskialf]

Hello,
after testing the POC's i don't have/see any issue/overflow.

Tested Systems: FreeBSD 12 & Ubuntu 18.04 LTS

shell# opj_compress -n 1 -i openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp -o /tmp/null.j2k

Error, not a BMP file!
Unable to load bmp file

shell# opj_compress -n 1 -i openjpeg_2-3_opj_compress_excessive-iteration_opj_t1_encode_cblks.bmp -o /tmp/null.j2k

Error, not a BMP file!
Unable to load bmp file

shell# opj_compress -n 1 -i openjpeg_2-3_opj_compress_integer-overflow_opj_j2k_setup_encoder.bmp -o /tmp/null.j2k                                                                     

Error, not a BMP file!
Unable to load bmp file

Is this bug still relevant?

[hlef]

Yes this bug is still affecting the master.

Please make sure to build with at least -DCMAKE_C_FLAGS="-fsanitize=undefined" since this is ubsan output. Also, not sure your reproducer is valid, you might have downloaded the GitHub HTML page and not the file itself.

[pesc]

/usr/local/bin/opj_compress -n 1 -i openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp -o /tmp/null.j2k

[INFO] tile number 1 / 1
[ERROR] opj_t2_encode_packet(): only 22 bytes remaining in output buffer. 359 needed.
[ERROR] Cannot encode tile
failed to encode image: opj_encode
failed to encode image: opj_end_compress
failed to encode image

So is it still affected?

[szukw000]

@ProbeFuzzer, @pesc ,
the BMP image has bugs. I tried several programs:
//----
IMAGE HAS: num_colors (INT)-336860181 (UINT)3958107115

//----
opj_compress -i openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp -o out.jp2

[ERROR] Number of resolutions is too high in comparison to the size of tiles
failed to encode image: opj_start_compress
failed to encode image: opj_encode
failed to encode image: opj_end_compress
failed to encode image

//----
gm animate openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp
(accepted)

//----
animate openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp
animate: insufficient image data in file `openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp' @ error/bmp.c/ReadBMPImage/677.

//----
bmptoppm -verbose openjpeg_2-3_opj_compress_integer-overflow_opj_t1_encode_cblks.bmp > bmp-to-ppm.txt
bmptoppm: Read 124 bytes of header
bmptoppm: BMP image header says:
bmptoppm: Class of BMP: Windows (v5)
bmptoppm: Width: 233 pixels
bmptoppm: Height: 3 pixels
bmptoppm: Depth: 1 planes
bmptoppm: Row order: bottom up
bmptoppm: Byte offset of raster within file: 138
bmptoppm: Bits per pixel in raster: 32
bmptoppm: Compression: none (bitfields)
bmptoppm: Colors in color map: 0
bmptoppm: warning: some image data remains unread.
bmptoppm: WRITING PPM IMAGE
(accepted)

//----
I used 'openjpeg2-2018-12-26'.
winfried

[sremick]

FYI: FreeBSD currently blocks the install of openjpeg due to CVE-2018-5727. This breaks other ports that depend on openjpeg.

[gessel]

Just as a cross reference, there's a fairly long discussion regarding these vulns and work-arounds on the FreeeBSD Forum.
https://forums.freebsd.org/threads/vulnerability-on-these-ports.67787/page-3

[sunpoet]

FYI: FreeBSD currently blocks the install of openjpeg due to CVE-2018-5727. This breaks other ports that depend on openjpeg.

As a workaround, you could set DISABLE_VULNERABILITIES to build openjpeg. It's described in /usr/ports/Mk/bsd.port.mk.

# DISABLE_VULNERABILITIES
#                               - If set, do not check if the port is listed in the
#                                 vulnerabilities database.