sscanf buffer overflow in opj_jp3d_compress.c

[robbiejones96]

A buffer overflow is possible in opj_jp3d_compress when using the -P option.

Vulnerable Code: opj_jp3d_compress.c:parse_cmdline_encoder

while (sscanf(s, "T%d=%d,%d,%d,%d,%d,%s", &POC[numpocs].tile,
                          &POC[numpocs].resno0, &POC[numpocs].compno0,
                          &POC[numpocs].layno1, &POC[numpocs].resno1,
                          &POC[numpocs].compno1, POC[numpocs].progorder) == 7) {

Reason: The string s comes straight from argv, so there is no enforcement that the %s conversion fits into the progorder array in the opj_poc_t struct. A malicious user can supply a progression order longer than 4 bytes, which results in a buffer overflow after the sscanf call.

Reproducing the attack:

./opj_jp3d_compress -P T0=1,2,3,4,5,aaaaa

Here we can use any string that fits the format specifications in the sscanf call, and include a progression order of length 5 to overflow the progorder buffer.

On my machine (ec2 t2-micro), using 3000 a's results in a segmentation fault.

Proposed mitigation:

Use the maximum field width specifier to limit the number of characters written to POC[numpocs].progorder to 4, i.e.,

while (sscanf(s, "T%d=%d,%d,%d,%d,%d,%4s", ...