웹센스(Websense), Technical Analysis on iPhone Jailbreaking

웹센스(WebSense)에서 이번 아이폰(iPhone) iOS 4.0.1 JailBreaking에 대해 분석한 결과를 발표하였다.

나도 현재 아이폰을 사용 중이기때문에 눈여겨 보았다.

아무리 봐도 머리가 좋다 ㅡㅡ;;

원문보기 : http://community.websense.com/blogs/securitylabs/archive/2010/08/06/technical-analysis-on-iphone-jailbreaking.aspx

So, we have this situation here. iPhone has a remote jailbreaking capability without any USB connection or anything. If you launch Safari and connect to the jailbreakme site, you can have your phone jailbroken with just a few steps. Obviously, this can be abused by bad guys to attack any iPhone in the world. We had time to analyze the mechanism of jailbreaking, and as we expected, it's just a matter of time before anyone can abuse this. Here's the summary of what we found.

 

    Picture 1: The flow of Jailbreaking using 2 iPhone vulnerabilities

 

 

First, the process uses the PDF Compact Font Format vulnerability (CVE-2010-1797). To our surprise, it's 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 jailbreakme 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 an undisclosed kernel vulnerability residing in an IOSurface component from Apple. It seems that the 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” file from the jailbreakme site 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 “/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.

 

The whole lesson here is that it is extremely easy to modify PDF payloads provided by the jailbreakme site, to make it do more operations than it was originally intended to do. The attack will surface soon, and it could be devastating, because we don't have any practical defense mechanisms against this type of attack on iPhone. We'd better try not to click any suspicious links on our iPhone browser from now on. And we'd better not check any PDF attachments delivered through iPhone mail until we have the fix. I hope the patch will be out soon, and I recommend that everyone install the patch when it's out.