반응형
해당 링크에서 퍼옴..
자료 보관용
http://digdog.tumblr.com/post/894317027/jailbreak-with-pdf-flatedecode-filter


Update

According to @chpwd, @comex uses CFF font stack overflow to jailbreak. (font file placed in FlateDecode stream)

If you look at the jailbreakme.com closely, it loads corresponding PDF file as image in javascript (through new Image()) to jailbreak the iOS devices.

Open the PDF file in the hex editor, you can easily find out what kind of PDF vulnerability they are using:

The jailbreak stuff saved as FlateDecode stream within that PDF file, and vulnerability occurs when Mobile Safari loaded the PDF file, letting iOS to parse the FlateDecode filter, and use the font file inside, then Kaboom.

What is FlateDecode?

According to the specification, PDF can embed raster images. They are represented by a dictionary that described the properties of the image, with an associated stream that contains image data. And those embedded images are filtered with different kinds of filters that supported in PDF, such as DCTDecode (lossy image-specific filter based on JPEG), ASCIIHexDecode (general purpose filter for ASCII stream), FlateDecode and many others.

The FlateDecode filter is a lostless general purpose filter for data compressed with zlib deflate function. You can compressed plaintext or any kinds of data with zlib and put it into FlateDecode section.

In today’s case, they put jailbreak stuff. If you decoded their FlateDecode steam, it looks like this:

If you wan to try it yourself, you can decompress the FlateDecode stream with ghostscript:

% gs — toolbin/pdfinflt.ps iPhone1,x_3.1.3.pdf output.txt

How the Vulnerability Works?

According to “Adobe Reader and Acrobat FlateDecode Integer Overflow Vulnerability”:

The vulnerability occurs when parsing a FlateDecode filter inside a PDF file. FlateDecode is a filter for data compressed with zlib deflate compression method. Several parameters can be specified for the FlateDecode filter. Those values are used in an arithmetic operation that calculates the number of bytes to allocate for a heap buffer. This calculation can overflow, which results in an undersized heap buffer being allocated. This buffer is then overflowed with data decompressed from the FlateDecode stream. This leads to a heap-based buffer overflow that can result in arbitrary code execution.

It’s a heap overflow. I don’t know if Apple fixed this on iOS or not, but it definitely looks like the cause.

Apparently my guess was totally wrong, it’s even deeper. Turns out it’s the font file embedded in FlateDecode stream that causes the stack overflow.

References

반응형

+ Recent posts