Hardwareseitiger Schutz

Ein weiterer Bestandteil der Sicherheitsarchitektur von Android ist ein hardwareseitiger Schutz, um die Ausnutzung von Softwareschwachstellen zu erschweren. Mit Hilfe des sogenannten eXecute-Never Bit (XN Bit) des ARM-Prozessors markiert das Betriebssystem seit Android 2.3 auf unterstützten Geräten wie dem Nexus S bestimmte Speicherbereiche wie Stack und Heap hardwareseitig als nicht ausführbar. Darüber hinaus stellt das XN Bit sicher, dass keine Speicherseiten gleichzeitig Berechtigungen zum Lesen, Schreiben und Ausführen besitzen. Dies bietet einen wirksamen Schutz gegen Code Injection und verhindert das Einschleusen von Programmcode.

Unter Zuhilfenahme der "Return Oriented Programming"-Technik (ROP) ist die Ausnutzung von Softwareschwachstellen aber dennoch möglich. Bei dieser Technik wird nicht versucht, eigenen Programmcode in den Speicher einzuschleusen, sondern auf die bereits im Speicher vorhandenen Instruktionen zurückzugreifen und aus diesen den Exploit-Code zusammenzustellen. Um die vorhandenen Instruktionen anspringen zu können, muss ein Schadcode allerdings deren Speicheradressen kennen. Linux erschwert die die Vorhersage von Speicheradressen seit Kernel durch eine Speicherverwürfelung (Address Space Layout Randomization, ASLR). Bei dieser Technik vergibt der Kernel beim Laden eines Prozesses die Adressbereiche von Bibliotheken und Programmen im Speicher zufällig, wodurch ein Schadcode die Speicheradressen der erforderlichen Instruktionen nicht mehr vorhersagen kann. Wie die Ausgabe von sysctl -a in Listing 8 zeigt, ist ASLR auch unter Android augenscheinlich aktiviert.

root@android # sysctl -a
...
kernel.ngroups_max = 65536
kernel.randomize_va_space = 1
kernel.max_lock_depth = 1024
...

Listing 8: ASLR unter Android

Android nutzt allerdings kein vollständiges ASLR (kernel.randomize_va_space = 1), sondern die konservative Methode ohne eine zufällige Adressvergabe für den dynamischen Speicher (Heap). Darüber hinaus startet Android wie oben beschrieben alle Applikationen aus Effizienzgründen als Fork von Zygote und vererbt ihnen dessen Speicherlayout. Aus Performance-Gründen verwendet Android zudem in der Regel Bibliotheken mit fest codierten Speicheradressen. In Kombination mit weiteren Limitierungen der Plattform kann ein Angreifer die Speicherverwürfelung von Android daher zuverlässig aushebeln.

Für einen erfolgreichen Datendiebstahl ist es für einen Angreifer aber gar nicht notwendig Softwareschwachstellen auszunutzen. Vielmehr programmiert er eine augenscheinlich interessante Applikationen und stellt diese im Android Market zum Download bereit. Begleitet mit der Aufforderung, vorher den root-Account freizuschalten. Schließlich macht ein Besitzer sein Gerät damit noch leistungsfähiger und kann es nach Belieben modifizieren. Da es sich dabei im Wesentlichen um die Freischaltung des root-Zugangs handelt, wird dieser Vorgang unter Android als Rooting bezeichnet. Erstaunlicherweise gibt es im Android Market zahlreiche Applikationen, die im Kontext des root-Benutzers ausgeführt werden wollen. Hat ein Anwender sein Android-Gerät "gerootet" und installiert auf diesem Applikationen mit root-Berechtigungen, haben diese die volle Kontrolle über das System. Die Möglichkeiten für schadhafte Applikationen reichen vom Diebstahl der gespeicherten Daten über das Mitschneiden von Eingaben auf der virtuellen Tastatur bis hin zum Missbrauch als Wanze.

Dies erweist sich insbesondere im Unternehmensumfeld als Herausforderung, da ein Anwender durch das Rooting das Sicherheitsmodell von Android unterwandert und die gespeicherten Unternehmensdaten einem höheren Risiko aussetzt. Administratoren können "gerootete" Geräte teilweise über Mobile Device Management Produkte wie Sybase Afaria detektieren und entsprechende Maßnahmen einleiten. Dazu gehört beispielsweise die Benachrichtigung des Benutzers oder die Sperrung des Zugangs zum Firmennetz.

Die für eine zentrale Verwaltung erforderliche "Device Administration"-Schnittstelle stellt Android seit der Betriebssystemversion 2.2 zur Verfügung. Diese Schnittstelle erlaubt es Administratoren, Sicherheitsrichtlinien von zentraler Stelle aus umzusetzen. Die Konfigurationseinstellungen sind derzeit allerdings im Wesentlichen auf die Umsetzung von Passwortrichtlinien für den Zugriffsschutz begrenzt. Bei einem Verlust der Geräte können Administratoren alle gespeicherten Benutzerdaten löschen und die Geräte in den Werkszustand zurücksetzen. Hersteller von Mobile Device Management Lösungen bieten darüber hinaus die Möglichkeit, Informationen wie beispielsweise die aktuelle Betriebssystemversion oder eine Liste der installierten Anwendungen von den Android-Geräten abzufragen.

Eine weitere Herausforderung für Administratoren stellt die starke Fragmentierung dar. Zum einen im Hinblick auf die Bereitstellung von Betriebssystemaktualisierungen zum anderen aber auch im Zusammenhang mit der zentralen Verwaltung der Android-Geräte. Letzteres wird erst seit Version 2.2 unterstützt, die derzeit auf vielen Geräten noch nicht verfügbar ist. Dies wiederum ist dem langwierigen Update-Prozess der Hersteller geschuldet. Auch in Zukunft wird es Erweiterungen geben, die nur auf der aktuellsten Betriebssystemversion verfügbar sind. Kleiner Trost ist die bei den meisten Geräten verfügbare, automatische Systemaktualisierung über die Luftschnittstelle (OTA), die nach Bestätigung der Anwender direkt auf dem Android-Gerät durchgeführt wird. Unternehmen sind dennoch gut beraten, auf einen oder wenige Hersteller zu setzen und vorher in Erfahrung zu bringen, ob und in welcher Häufigkeit dieser Aktualisierungen bereitstellen wird.