{"id":214,"date":"2011-05-06T16:01:35","date_gmt":"2011-05-06T14:01:35","guid":{"rendered":"http:\/\/blog.thomasius.net\/?p=214"},"modified":"2011-05-06T16:01:35","modified_gmt":"2011-05-06T14:01:35","slug":"android-property-service-neutralisiert-eine-analyse","status":"publish","type":"post","link":"https:\/\/blog.embedded-system-design.de\/index.php\/2011\/05\/06\/android-property-service-neutralisiert-eine-analyse\/","title":{"rendered":"Android: „Property Service neutralisiert“ – Eine Analyse"},"content":{"rendered":"

Gr\u00fcnde gibt es ganz verschiedene, um die volle Bandbreite an Systemrechten auf dem eigenen Ger\u00e4ten zu genie\u00dfen. Nachdem verschiedene Exploits nach meinem Systemupdate auf Version 1.72.405.3 (basierend auf Android 2.2) nicht mehr funktionierten, bin ich erneut f\u00fcndig geworden. Seinen erfolgreichen Dienst meldet der gefundene Exploit mit der Ausgabe „property service neutered“<\/em>. 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\u00e4\u00dft sich mit dem GCC f\u00fcr dir ARM-Architektur \u00fcbersetzen und anschlie\u00dfend auf dem Ger\u00e4t ohne root-Rechte zur Ausf\u00fchrung bringen. Als Belohnung winken die vollen Zugriffsrechte.<\/p>\n

Ansatzpunkt ist die Android Debug Bridge (adb<\/em>) –\u00a0 ein hiflreicher Dienst im Ger\u00e4t, der Entwicklern hilft, ihre Software \u00fcber die USB-Schnittstelle zu debuggen. \u00dcber diese Schnittstelle ist es z.B. m\u00f6glich, Dateien mit dem Ger\u00e4t auszutauschen oder einen Shell-Zugriff zu erlangen und hier\u00fcber Befehle auf dem Ger\u00e4t auszuf\u00fchren. W\u00e4hrend auf Systementwicklerger\u00e4ten das Arbeiten mit root-Rechten erm\u00f6glicht wird, soll die Debug-Schnittstelle „eigentlich“ auf Endkundenger\u00e4ten den Dienst mit vollen Rechten verweigern.<\/p>\n

Der auf dem Ger\u00e4t zust\u00e4ndige Android Debug Bridge Daemon (adbd<\/em>) startet zun\u00e4chst mit root-Rechten und macht vom Lesen der ro.secure-Property abh\u00e4ngig, ob er seine Privilegien abgibt oder nicht. Diese Systemeigenschaften werden \u00fcber 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.<\/p>\n

Wenn er die ro.secure-Property nicht lesen kann, beh\u00e4lt er die root-Rechte unter der f\u00e4lschlichen Annahme, die Property sei nicht gesetzt. Versehen oder Absicht? Eine m\u00f6gliche Erkl\u00e4rung daf\u00fcr ist der Wunsch des Systementwicklers, auf dem System auch dann mit vollen Rechten debuggen zu k\u00f6nnen, wenn das Speichermanagement z.B. durch Programmierfehler versagt.<\/p>\n

Der Exploit zielt darauf ab, genau diesen Lesezugriff auf die Properties zu verhindern, so dass die Debug-Schnittstelle weiterhin mit root-Rechten ausgef\u00fchrt wird. Wie wird das Lesen unm\u00f6glich gemacht?<\/p>\n

ASHMEM erlaubt es, die Rechte f\u00fcr eine Speicherseite weiter einzuschr\u00e4nken. Der Exploit liest die Umgebungsvariable ANDROID_PROPERTY_WORKSPACE. Sie enth\u00e4lt Informationen, um den Speicherbereich zu finden und neu zu mappen. Die Zugriffsmaske f\u00fcr diesen Speicherbereich wird auf 0 gesetzt, so dass kein anderer Prozess, so auch adbd<\/em>,\u00a0 diesen lesen kann. Nach dem Senden eines SIGTERM an den adbd<\/em>-Prozess wird dieser beendet. Das ist m\u00f6glich, da der Exploit-Prozess ja durch den adbd<\/em> gestartet mit gleicher UID wurde. Der vom System automatisch neu ausgef\u00fchrte adbd<\/em> kann die System-Properties nicht mehr lesen und beh\u00e4lt seine root-Rechte. Alle jetzt \u00fcber die Android Debug Bridge gestarteten Befehle verf\u00fcgen \u00fcber root-Rechte. Tobt man sich nicht alzusehr aus, sind nach einem Neustart des Ger\u00e4tes die Rechte wieder beim alten. Man spricht auch vom „tempor\u00e4ren Rooten“<\/em>.<\/p>\n

Der Exploit hat allerdings Seiteneffekte: Andere Android Dienste k\u00f6nnen die Properties ebenfalls nicht lesen und funktionieren wohl m\u00f6glich 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\u00e4\u00dft, reicht das aber aus.<\/p>\n

Noch eine Anmerkung f\u00fcr besorgte Nichtentwickler: F\u00fcr diesen Exploit muss das Android Ger\u00e4t erst per USB-Kabel mit Rechner verbunden und die Debug-Schnittstelle aktiviert sein.<\/p>\n

Update (21. Mai 2011):<\/strong><\/p>\n

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\u00f6nnen die Rechte f\u00fcr die Memory-Page nicht gesetzt werden, so dass die Meldung<\/p>\n

„Failed to set prot mask (Inappropriate ioctl for device)“<\/p><\/blockquote>\n

erscheint. Diese Meldung suggeriert, dass der ioctl-Befehlscode ASHMEM_SET_PROT_MASK<\/em> f\u00fcr den Property Workspace unbekannt ist. Nachvollziehen kann ich das (noch) nicht, da die Befehlskodierung f\u00fcr ioctl()<\/em> identisch zur Vorg\u00e4ngerversion zu sein scheinen. In den HTC-Quellen f\u00fcr den Kernel 2.6.35<\/a> (HTC Desire HD) ist der entsprechende ioctl<\/em>-Handler sogar identisch wie beim Kernel 2.6.32 implementiert und es gibt keine bedingte Kompilierung, welche die entsprechenden Code-Zeilen von der \u00dcbersetzung ausnehmen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Gr\u00fcnde gibt es ganz verschiedene, um die volle Bandbreite an Systemrechten auf dem eigenen Ger\u00e4ten zu genie\u00dfen. Nachdem verschiedene Exploits nach meinem Systemupdate auf Version 1.72.405.3 (basierend auf Android 2.2) nicht mehr funktionierten, bin ich erneut f\u00fcndig geworden. Seinen erfolgreichen Dienst meldet der gefundene Exploit mit der Ausgabe „property service neutered“. Schauen wir uns doch … <\/p>\n

Weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1,5,7],"tags":[18,29],"_links":{"self":[{"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/posts\/214"}],"collection":[{"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/comments?post=214"}],"version-history":[{"count":0,"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/posts\/214\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/media?parent=214"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/categories?post=214"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.embedded-system-design.de\/index.php\/wp-json\/wp\/v2\/tags?post=214"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}