Some days ago Comex
published his JailbreakMe
for the new iPhone 4 in the Defcon 18. The interesting thing is that in order to root the device he used a PDF exploit for Mobile Safari to execute arbitrary code and after this another kernel vuln to gain elevated privileges. I've being taking a look at the PDF files
and these are my thoughts about it.
The PDF file itself has no many objects and only one encoded stream:
The stream is encoded with a simple FlateDecode filter, without parameters, and if we decode its content we can see this strings, related to the JailbreakMe stuff:
As this object seems to contain the vulnerability we are looking for we'll take a closer look to this stream and what this is for:
element contains an embedded font program or font file
and the /Type1C
subtype means that the font file
is represented in the Compact Font Format (CFF)
, described in this document
If we make a diff between the first decoded bytes of two different PDF files we can see that the differences start in the section marked in green and that it's the CharStrings Index.
This element of the CFF contains the charstrings of the charset in the described font. The data is stored in an INDEX CFF structure. Because the CharstringType
is not defined in the preceded bytes it will be Type 2, the default value. Again this format has its own specification
telling that these bytes can contain numbers or operators depending on the first byte of each field. This format uses an argument stack, when a number appears it's stored in the stack. The operators take the arguments from there too, leaving the possible result on the top.
Although I've not read the full specification yet, I think that this vulnerability is related to a kind of overflow in the Type 2 argument stack and not to the FlateDecode filter itself. At the moment there's no available patch so it's recommended some type of mitigation and to be careful with the visited links.
Thanks to a message in the Full Disclosure list I've known that the very next day I published this post a patch was released (not for Apple products yet). The diff shows that the bug was in the arguments stack, not checking the end of it after operators execution.