'jailbreakme'에 해당되는 글 4건

  1. 2011.02.21 More about the JailbreakMe PDF exploit
  2. 2010.10.11 Apple iOS 4.1 탈옥 방법
  3. 2010.08.24 About the JailbreakMe PDF exploit (1)
2011.02.21 19:40

More about the JailbreakMe PDF exploit

Today has been released the source code of the Jailbreakme exploit, so maybe this explanation comes a bit late. In the update of the previous post about this subject I knew that I was right about the overflow in the arguments stack when parsing the charstrings in the Type 2 format, so here is a little more info.

After decoding the stream of the object 13 we can see the following bytes (talking about this file):

The selected bytes are the important ones for this exploit because the overflow occurs when parsing them. Like I mentioned, the Type 2 format is composed of operands, operators and numbers, and use the stack to push and pop values. This stack has a maximum size of 48 elements. We can understand better the meaning of these bytes with this tips:

 

  • The 0xFF byte means that the next 4 bytes are interpreted as a 32-bit two’s-complement number that will be pushed into the stack.
  • 0x0C17 is the random operator that returns a pseudo random number greater than zero and less than or equal to one. This operator doesn't take any argument from the stack.
  • The operator 0x0C04 is an or that takes two arguments from the stack and puts a 0 is both arguments are zero and a 1 otherwise.
  • 0x0C0D is the index operator, which takes an argument num from the stack and puts the argument in the position num of the stack on the top of it.
  • The drop operator is composed by the bytes 0x0C12 and removes the stack top element.

 

Then, from the stack modification perspective we can separate the bytes in 4 "instructions" set:

 

  • 0xFFXXXXXXXX (45*5 bytes): we put XXXXXXXX into the stack. There is a limit here in the amount of this type of "instruction" because of the stack arguments size, that is checked in this case. So the maximum number that we can push is 45.
  • 0x0C170C170C040C1D (20*8 bytes): it pushes the stack element in position 1 (one position after the top element) into the stack. The position is always 1 because the random elements pushed are always non-zero. So in this case will be 0x00C00000.
  • 0x0C170C1D (170*4 bytes): we push the element in the position specified by the random number into the stack. The random number always has 16 bits and after a 16-bits movement to the right it becomes 0, so the pushed value will be always the top of the stack, 0x00C00000.
  • 0x0C1D0C12 (42*4 bytes): it pushes the stack element in the position C0 into the stack and removes it. The first "instruction" of this type will push F00DF00D (the 4th last number pushed with FF), and the next "instructions" will write into the stack the 41 previous numbers.

 

These "instructions", except the FF one, don't check if the stack is full before pushing values, so after parsing and executing them the stack state will be similar to this image, being 48*4 the maximum size for the stack:

After the last 0x0C12 an FF "instruction" is executed, checking the stack size and returning from the function with an error code. The successful exploitation will depend on the program and the architecture where the PDF file is parsed. As you know, this affects to Apple products (now patched) and to the Foxit Reader. In the case of the latter we can exploit it easily through a SEH overflow, putting the shellcode into the bytes pushed by the FF "instructions". Here we'll have more than 100 bytes for it, depending on the SEH position. Anyway we can jump from here to the rest of the decoded stream and really do what we want.

출처 : http://eternal-todo.com

Trackback 0 Comment 0
2010.10.11 18:33

Apple iOS 4.1 탈옥 방법






http://www.limera1n.com/

위 사이트를 통해 제공되며 현재 베타버젼 상태입니다.

조만간 정식버젼이 릴리즈 될 것 같습니다.

Trackback 0 Comment 0
2010.08.24 17:12

About the JailbreakMe PDF exploit

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:
The /FontFile3 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.
 

Update (2010-08-06):

Thanks to a message in the Full Disclosure list  I've known that the very next day I published this post apatch 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.


출처 : http://eternal-todo.com/


Trackback 0 Comment 1
  1. 2010.08.24 17:14 address edit & del reply

    비밀댓글입니다