Seite 8: Plattform-Überblick

Inhaltsverzeichnis

Plattform-Überblick

Beim Betriebssystem setzt das iPhone auf ein spezielles Mac OS X, das wie der große Bruder auf einer Mischung aus MACH-Kernel und FreeBSD beruht. Android setzt auf den bewährten Linux-Kernel 2.6. Auf beiden Plattformen stammen zahlreiche Systemanwendungen und Dienste aus der Open-Source-Welt. Bei den Apps gehen die Plattformen verschiedene Wege: Anwendungen für Android sind üblicherweise in Java geschrieben und laufen in der Dalvik getauften Virtual Machine, die nicht zu normalen Java-Compilern kompatibel ist. Konzeptbedingt können in Java berühmt-berüchtigte Sicherheitsprobleme wie Buffer Overflows nicht auftreten. Apps für das iPhone sind zumeist aus Objective-C in Maschinensprache übersetzt und laufen ohne zusätzliche Laufzeitumgebung.

Durch den Ablauf der Android-Apps in der VM und die integrierte Zugriffskontrolle (Mandatory Access Control, MAC) ist jede Anwendung gegen andere Anwendungen abgeschottet und hat keinen unmittelbaren Zugriff auf das Android-System und seine Ressourcen, sprich die Hardware, das Dateisystem, Daten anderer Apps und so weiter. Der Anwender kann bei der Installation benötigte Zugriffsrechte gewähren. Android zeigt alle angeforderten Rechte an. Welche Rechte eine App gerne hätte, ist im Installationspaket in der Manifest-Datei formuliert (AndroidManifest.xml). Leider hat man nur die Wahl, alle Wünsche zu erfüllen oder die Installation abzubrechen; einzelne Rechte lassen sich nicht gewähren. In der Manifest-Datei ist die digitale Signatur der App hinterlegt, mit der der Entwickler sein Programm unterzeichnet hat. Das dafür benutzte Zertifikat des Autoren darf selbst signiert sein – es geht bei Android weniger darum, die Identität des Programmierers verifizierbar zu machen, als vielmehr um die fälschungssichere Bindung der Apps an die zugeteilten Rechte.

Apples Sicherheitskonzept sieht zwar ebenfalls eine Isolierung der Apps und Prozesse mittels einer Mandatory Access Control voneinander vor, das iPhone-Betriebssystem setzt dies offenbar nicht so streng durch wie Android. In der Vergangenheit stellte sich immer wieder heraus, dass trotz Sandboxing Apps zumindest lesend auf Konfigurationsdateien des Systems und anderer Apps zugreifen können. Das liegt unter anderem daran, dass die vom Mac OS X abgeschauten Zugriffsregeln auf Basis von Regular Expression statisch und generisch definiert sind statt auf einzelne Apps abgestimmt. Im Unterschied zu Android läuft auf dem iPhone zudem nicht jeder Prozess mit einer eigenen Nutzerkennung: Systemdienste und einige Anwendungen arbeiten als „root“; die im Kontext des Anwenders als „mobile“. Über eine im Rahmen des Pwn2own-Wettbewerbs 2010 aufgedeckte Lücke in Safari (der als „mobile“ lief) ließ sich die SMS-Datenbank auslesen und auf den Webserver der Angreifer übertragen. Unter Android ist dies so nicht möglich, weil dort jeder Prozess eine eigene Kennung (UID) hat und die Zugriffskontrolle feiner abgestimmt ist.

Wie bei Android laufen auf dem iPhone ebenfalls nur digital signierte Anwendungen. Anders als bei Android dient dies in erster Linie dazu, nur von Apple freigegebene Anwendungen laufen zu lassen sowie die Herkunft der Apps nachvollziehen zu können. Entwickler für das iPhone müssen ihre Apps von Apple unterschreiben lassen oder können auf Wunsch ein von Apple ausgestelltes Code-Signing-Zertifikat zum eigenständigen Unterschreiben der Software erhalten.

Neben dem per Software implementierten Sandboxing und dem Code Signing bietet das iPhone noch einen hardwareseitigen Schutz: Der ARM-Prozessor unterstützt eine Datenausführungsverhinderung (DEP), die die Auswirkung von Buffer Overflows und Heap Overflows limitieren soll. Das „eXecute Never“-Flag (XN) verhindert, dass Angreifer etwa auf den Anwendungs-Stack geschleusten Code starten können. Raffiniertere Angriffe haben gezeigt, dass sich der Schutz durch sogenanntes Return-oriented Programming (ROP) umgehen lässt. Dabei schleusen Angreifer keinen eigenen Code auf den Stack, sondern rufen vorhandene Bibliotheks-Funktionen durch Manipulation von Rücksprungadressen und Parametern auf. Durch die geschickte Verknüpfung von Funktionen kann der Angreifer seinen Code quasi vor Ort zusammenbauen. Die von modernen Desktop-Betriebssystemen eingesetzte Speicherverwürfelung Address Space Layout Randomization (ASLR) kann solche Tricksereien erschweren, leider bringt das iPhone sie nicht mit. Googles Android nutzt weder die „eXecute Never“-Funktion des ARM-Prozessors noch verwürfelt es den Speicher. (dab)