Star

From The iPhone Wiki
Jump to: navigation, search

Star (also known as JailbreakMe 2.0) is a userland untethered jailbreak from comex that utilizes two exploits to jailbreak iPhone OS 3.1.2 through iOS 4.0.1 (except for 3.2.2). The jailbreakme.com domain was repurposed after AppSnapp, making this a "2.0". The exploits were supposedly patched in 3.2.2 and 4.0.2, but comex stated that the one of the exploits used for the jailbreak existed until iOS 4.3 as Apple did not patch the bug correctly. It was properly patched on 4.3.1 in order to prevent the jailbreak of the iPad 2. It's still possible the site could be repurposed to jailbreak devices up to 4.3, but this has not yet been done.

Star warns that 3.1.2 and 3.1.3 are known to fail on iPod touch (3rd generation), and that performing a fresh restore to 4.0(.1) is recommended.

Payloads

  • The first payload is deployed via a HTTP redirect to a PDF file. The PDF contains a CFF font with a malformed type 2 charstring, which contains commands to repeatedly push and duplicate random numbers onto an "argument stack". This allows arbitrary code execution due to stack overflow in CFF parser inside FreeType 2 library used by iOS. Then an integer overflow in IOSurface.framework used to get root access and privileges.[1]
  • The second payload (wad.bin) contains Cydia and code to install it into filesystem.

PDF Patch

Because this jailbreak revealed a new major security hole in iOS, it could also be adopted by rogue developers to create malware to take over your iPad/iPhone/iPod touch. Therefore it is highly recommended to install the patch saurik released via Cydia in order to keep your device safe.

Analysis

First, the process uses the Malformed CFF Vulnerability (CVE-2010-1797), which is a simple stack-based buffer overflow. With this vulnerability, an overly long CFF charString entry ends up with attacker-controlled $pc. Many people think of Return Oriented Programming (ROP) as a rather immature technique to use for complicated jobs. But the Star shellcode uses ROP to execute more than a total of 150 API calls. This means non-executable memory is not a defense against these kinds of memory corruption attacks. Looks as if the current ROP technique for iPhone exploitation is very mature and stable.

The ROP payload actually abuses a vulnerability in IOSurface.framework. This vulnerability allows a normal process to have access to kernel memory with write privileges. After it modifies kernel space data to circumvent security checks, it calls “setuid(0)” to get root access. So, the game is pretty much over at this point. The Safari process at this point has root user privileges, and it can do whatever it wants.

After this exploitation phase, it drops the “installui.dylib” shared library, loads it, and executes the “iui_go” function from the library. This allows some UI text to be displayed on the user’s screen to ask whether to go forward with jailbreaking. Then it downloads the “wad.bin” and extracts necessary files like “install.dylib” from there, and then executes the “do_install” function from there, which will do the typical jailbreaking process. All these operations are possible because the Safari process has root access acquired using the kernel bug.

The jailbreaking phase involves something like moving some system directories and modifying essential system files like “/private/etc/fstab”. Also it directly accesses the “/dev/kmem” device to patch kernel flags or code. And finally it installs the “Cydia” installer package and restarts SpringBoard using the “uicache” command.

Links