Gründe gibt es ganz verschiedene, um die volle Bandbreite an Systemrechten auf dem eigenen Geräten zu genießen. Nachdem verschiedene Exploits nach meinem Systemupdate auf Version 1.72.405.3 (basierend auf Android 2.2) nicht mehr funktionierten, bin ich erneut fündig geworden. Seinen erfolgreichen Dienst meldet der gefundene Exploit mit der Ausgabe „property service neutered“. Schauen wir uns doch mal an, wie dieser Exploit technisch funktioniert. Grundlage der Analyse ist der publizierte Exploit-Code. Er ist in C geschrieben und läßt sich mit dem GCC für dir ARM-Architektur übersetzen und anschließend auf dem Gerät ohne root-Rechte zur Ausführung bringen. Als Belohnung winken die vollen Zugriffsrechte.
Ansatzpunkt ist die Android Debug Bridge (adb) – ein hiflreicher Dienst im Gerät, der Entwicklern hilft, ihre Software über die USB-Schnittstelle zu debuggen. Über diese Schnittstelle ist es z.B. möglich, Dateien mit dem Gerät auszutauschen oder einen Shell-Zugriff zu erlangen und hierüber Befehle auf dem Gerät auszuführen. Während auf Systementwicklergeräten das Arbeiten mit root-Rechten ermöglicht wird, soll die Debug-Schnittstelle „eigentlich“ auf Endkundengeräten den Dienst mit vollen Rechten verweigern.
Der auf dem Gerät zuständige Android Debug Bridge Daemon (adbd) startet zunächst mit root-Rechten und macht vom Lesen der ro.secure-Property abhängig, ob er seine Privilegien abgibt oder nicht. Diese Systemeigenschaften werden über einem gemeinsam genutzten Speicherbereich ausgetauscht. Beim dem genutzten Anonymous Shared Memory (ASHMEM) handelt es sich um einen vom Betriebssystemkern verwalteten Speicherbereich, den sich Prozesse teilen, um Daten untereinander auszutauschen.
Wenn er die ro.secure-Property nicht lesen kann, behält er die root-Rechte unter der fälschlichen Annahme, die Property sei nicht gesetzt. Versehen oder Absicht? Eine mögliche Erklärung dafür ist der Wunsch des Systementwicklers, auf dem System auch dann mit vollen Rechten debuggen zu können, wenn das Speichermanagement z.B. durch Programmierfehler versagt.
Der Exploit zielt darauf ab, genau diesen Lesezugriff auf die Properties zu verhindern, so dass die Debug-Schnittstelle weiterhin mit root-Rechten ausgeführt wird. Wie wird das Lesen unmöglich gemacht?
ASHMEM erlaubt es, die Rechte für eine Speicherseite weiter einzuschränken. Der Exploit liest die Umgebungsvariable ANDROID_PROPERTY_WORKSPACE. Sie enthält Informationen, um den Speicherbereich zu finden und neu zu mappen. Die Zugriffsmaske für diesen Speicherbereich wird auf 0 gesetzt, so dass kein anderer Prozess, so auch adbd, diesen lesen kann. Nach dem Senden eines SIGTERM an den adbd-Prozess wird dieser beendet. Das ist möglich, da der Exploit-Prozess ja durch den adbd gestartet mit gleicher UID wurde. Der vom System automatisch neu ausgeführte adbd kann die System-Properties nicht mehr lesen und behält seine root-Rechte. Alle jetzt über die Android Debug Bridge gestarteten Befehle verfügen über root-Rechte. Tobt man sich nicht alzusehr aus, sind nach einem Neustart des Gerätes die Rechte wieder beim alten. Man spricht auch vom „temporären Rooten“.
Der Exploit hat allerdings Seiteneffekte: Andere Android Dienste können die Properties ebenfalls nicht lesen und funktionieren wohl möglich nicht mehr, bis das gesamte System neu gestartet wird – so z.B. DNS. Zur Einsicht in die Android System-Protokolle und was die eine odere andere Anwendung an Datenspuren hinterläßt, reicht das aber aus.
Noch eine Anmerkung für besorgte Nichtentwickler: Für diesen Exploit muss das Android Gerät erst per USB-Kabel mit Rechner verbunden und die Debug-Schnittstelle aktiviert sein.
Update (21. Mai 2011):
Nach einem Systemupdate auf die Software-Version 2.36.405.8 (Android 2.3.3), funktioniert dieser Exploit beim HTC Desire HD nicht mehr. Es können die Rechte für die Memory-Page nicht gesetzt werden, so dass die Meldung
„Failed to set prot mask (Inappropriate ioctl for device)“
erscheint. Diese Meldung suggeriert, dass der ioctl-Befehlscode ASHMEM_SET_PROT_MASK für den Property Workspace unbekannt ist. Nachvollziehen kann ich das (noch) nicht, da die Befehlskodierung für ioctl() identisch zur Vorgängerversion zu sein scheinen. In den HTC-Quellen für den Kernel 2.6.35 (HTC Desire HD) ist der entsprechende ioctl-Handler sogar identisch wie beim Kernel 2.6.32 implementiert und es gibt keine bedingte Kompilierung, welche die entsprechenden Code-Zeilen von der Übersetzung ausnehmen.
Neueste Kommentare