Gast-Artikel: Der harte Weg aus der Sandbox des iOS 5.0.1, beim iPhone 4S

Kein Kommentar Autor: Jürgen (jdo)

Mein Name ist iGenius, von Beruf WirtschaftsIng Student und leidenschaftlicher Blogger. Meine Seite www.iPhone247.de dreht sich rund um Jailbreaks aller Devices, ich berichte darüber hinaus, über all die schönen Tweaks und Widgets, die sich mit einem Jailbreak auf dem Gerät installieren lassen. Doch auch Testberichte, wie meinen neuen iPhone Dockingstation Test gibt es auf dieser Seite. Langfristig soll diese Site ein hochwertiges Magazin werden.

Die ganze iPhone-Welt steht Kopf, wenn das Dev Team oder das Corona Dev Team einen den Jailbreak zum neusten iOS Betriebssystem veröffentlichen. Doch wie stellen pod2g und die anderen Mitglieder von Team das eigentlich an?

Diesmal hat es der junge Hacker “pod2g” geschafft, den Exploit zu finden. Er ist hauptsächlich auch für den Jailbreak des iPhone 3GS, dem iPhone 4, des iPod Touch 3G/4G, des iPad 1 und Apple TV 2G verantwortlich. In seinem Blog bringt er uns die Verfahren etwas näher, wie der aktuelle Jailbreak zu Stande kommt, wieso diese Methode eigentlich Corona genannt wird und wie er den Exploit (Sicherheitslücke) fand – welcher übrigens ein Kernel Exploit ist.

Der Name Corona stammt dabei, nicht wie naheliegend, vom Namen des Bieres. Es handelt sich um ein Anagramm “racoon” (IPSec IKE-Daemon).

Maßgeblich besteht der Jailbreak aus zwei verschiedenen Sicherheitslücken, damit die Sandbox von Apple umgangen werden und eigenerCode in das iOS 5.0.1 implementiert werden kann. Dem Userland Exploid und dem Kernel Exploit.

Der Userland Exploit

Dabei hat Pod2G den Exploit in einer Config-Datei von IKE-Deamon “racoon” gefunden, der wie oben beschrieben, auch der Namensgeber war. Es ist möglich unsignierten Code in dieser Config auszuführen. Diese Schwachstelle nutzten das Dreamteam (bestehend aus pod2G und dem Dev Team) aus, um den Kernel mit Hilfe der modifizierten Config-File auszutriggern. Doch ist das Problem dieser Sicherheitslücke ist ganz klar: spätestens mit dem neuen Betriebssystem 5.1 und den zukünftigen kommenden iOS Updates ist diese, leicht zu behebende Sicherheitslücke schnell von Apple wieder geschlossen.

Der Kernel Exploit

Damit die oben beschriebene Config-File, die modifiziert wurde, vom Kernel akzeptiert wird, bedarf es einer Abschaltung des Sicherheitscodes vom Kernel. Dies wird erzeugt, in dem ein Pufferüberlauf, auf englisch Buffer Overflow, erzwungen wird. Genau da, ist Pod2g gescheitert und dankt in seinem Blog dem Dev Team. Die Hacker kannten sich bis dato nur aus dem Internet. Das Dev Team stieg wegen des Jailbreaks extra in ein Flugzeug, reiste zu Pod2g und wohnten auch 4 Wochen bei ihm. Diese Unterstützung war auch nötig, damit der Jailbreak, der übrigens Absinthe heisst, für die Massen veröffentlicht werden konnte. Hier gibt es den iPhone Jailbreak mit Anleitung und Download.

I just realized that it is a heap overflow in the zone allocator, so I started to try to mount clean, overflowed and payload images in a Heap Feng Shui way And hey, that worked :p Thanks to @i0n1c for his papers on this subject. This helped me a lot. I may have given up without them.
The kernel heap overflow exploit copies 0×200 bytes from the vnimage.payload file to the kernel sysent replacing a syscall to a write anywhere gadget. Some syscalls (first 0xA0 bytes and the last 0×6 bytes) are trashed in the operation because I needed to respect the HFS protocol.