Out of bounds heap write

[gsingh93]

Thanks for reporting your issue. Please make sure these boxes are checked before submitting your issue - thank you!

• I looked for a similar issue and couldn't find any.
• I tried with the latest version of GPAC. Installers available at http://gpac.io/downloads/gpac-nightly-builds/
• I give enough information for contributors to reproduce my issue (meaningful title, github labels, platform and compiler, command-line ...). I can share files anonymously with this dropbox: https://www.mediafire.com/filedrop/filedrop_hosted.php?drop=eec9e058a9486fe4e99c33021481d9e1826ca9dbc242a6cfaab0fe95da5e5d95

Detailed guidelines: http://gpac.io/2013/07/16/how-to-file-a-bug-properly/

---

There is an out of bounds heap write in av_ext.c: https://github.com/gpac/gpac/blob/master/src/isomedia/avc_ext.c#L2415

op->layer_count is read from user input, and then used in the condition of the for loop. This means the user can force the loop to execute up to 256 times. The layers_info array only has 64 elements, and this array is allocated on the heap, so I can craft a file that causes this file to write out of the bounds of the array onto the heap. For example, an attacker could overwrite the top chunk of the glibc heap, which can be used with other bugs to achieve remote code execution in services processing user supplied media files.

[rbouqueau]

@jeanlf or anyone who knows: a reason MAX_LHEVC_LAYERS is set to 64?

[aureliendavid]

I don't know (maybe a spec somewhere?) but it looks like it used to be 256: 3d17f95#diff-e61e7a94ff33b9b8d6420afc5577f1e1

[gsingh93]

Regardless of what the value should be, there's no harm in adding a i < sizeof(op->layers_info) check into the loop.

[jeanlf]

nuh_layer_id is 6 bits, hence the 64. I agree a cross check should be added in the parser

[aureliendavid]

should now be ok - thanks for the report, reopen if needed

[carnil]

This issue was assigned CVE-2018-1000100