Insecurity by Obscurity: Ein unabänderliches Feature von Android

WARNUNG: Ich bin kein Android-App-Entwickler und habe das Papier nur schnell mal überflogen um hoffentlich zu verstehen, wie das funktioniert (weil es leider eben nicht im Artikel steht). Außerdem beziehe ich mich nur auf ein Detail des Papiers, nämlich der erhöhten Rechte. In dem Papier sind eine ganze Reihe von weiteren Angriffen beschrieben!

Das ist, wie es sich mir nun darstellt:

- Eine Activity einer App, die Sicherheitsrechte einfordert, wird aufgerufen
- Stattdessen schummelt sich eine Malware in den Vordergrund (und nutzt dafür ein grundlegendes Feature das z. B. auch zwingend von Sicherheitsapps benötigt wird um Sicherheitswarnungen anzuzeigen oder Sicherheitsabragen vorzuschalten)
- Die Malware reparentet dann die Activity der anderen App, sprich, weist diese Activity ihrem eigenen Task zu (das ist wiederum ein Standardverhalten von Android das die App hätte verhindern müssen, aber eben nicht tut) und verschwidet sofort wieder, womit die originale Activity angezeigt wird (der Nutzer merkt also nix von der Malware)
- Sobald die Activity der App dann die Rechte anfordert (was sie ja darf, die App zu der die Activity gehört hat die Rechte das anzufordern, während die Malware diese Rechte nicht hat), geschieht das für den aktuellen Task (also den der Malware zu dem die Activity jetzt gehört!) und nicht den Task der App.
- Der Task der Malware hat dann diese Erlaubnis, obwohl die Malware diese Rechte nicht im Manifest hat.

Warnung! Ich habe keine Ahnung ob ich das jetzt richtig verstanden habe! Aber das könnte die Erklärung für das beobachtete Verhalten sein. Aber wenn das so ist, ist das kein Fehler von Android, sondern ein Fehler der Defaulteinstellungen ein jeder Activity, die Sicherheitsrechte anfordert.

Im Gegenteil, das hier ausgenutzte Feature ist notwendig, um sichere Applikationen zu bauen! (Auf einem anderen Blatt steht, dass das anscheinend unter Android niemand tun will.) Auf diese Weise kann ich z. B. eine sichere Scan-App haben, die die Rechte für die Kamera überwacht, und trotzdem von einer anderen Applikation aus Scannen, die deshalb gar keine Zugriffsrechte auf die Kamera braucht. Da dann die Activity der Scan-App die Kamera verwaltet, kann diese die korrekte zulässige Nutzung der Kamera für die andere App vollständig überwachen. Ohne dieses (reparenting-)Feature wäre das nicht möglich, dann müsste die gesamte Funktionalität der anderen Applikation in die Scan-App selbst verlagert werden - was ja die Sicherheit unterminiert, da dann diese Barriere fehlt. Sicherheit erreicht man nicht durch Bloatware, sondern nur durch Konzentration auf das wesentliche!

Weitere Punkte:

0) Das verlinkte Papier ist interessant. Es erklärt (leider sehr verschleiert) einige Details, die man beim Bauen einer App unter Android besser beachten sollte. Leider erklärt das Papier aber NICHT, wie man (als App-Entwickler) diese Sicherheitsprobleme verhindert (es wird nur erklärt, was Android besser machen könnte, nicht aber, was der App-Entwickler beachten sollten). Aber das ist wenigstens mal ein Ansatz, um nachzuforschen, also etwas, das man auf seine TODO-Liste setzen sollte wenn man unter Android eine App entwickelt.

1) Diese "Sicherheitslücke in Android" ist in etwa so katastrophal, wie die Fähigkeit eines beliebigen OS, Programme oder Fenster in einem anderen Sicherheitskontext zu erlauben. Ja, richtig gelesen. Es handelt sich um ein sehr grundlegendes Feature von eben jedem Betriebssystem, das man eben nicht einfach so abschaffen kann, ohne dabei die gesamte Funktionalität zu zerstören. Das erklärt auch, warum das Papier schon 5 Jahre alt ist und sich "anscheinend" immer noch nichts getan hat.

2) Leider versteckt sich die Grundlage in einem Feature, über das 99,9% der App-Entwickler nicht wirklich Bescheid wissen dürften (allowTaskReparenting) und das halt, wenn man es falsch verwendet (so wie eigentlich jedes Feature das man falsch verwenden kann), eben ein Sicherheitsproblem darstellt. Ich kannte das auch vorher nicht (ich bin allerdings bisher auch bisher kein App-Entwickler einer App die irgendwelche Rechte oder Sicherheit einfordert). Das Feature ist in etwa vergleichbar mit dem Aspekt von getuid() und geteuid() unter Unix, der ebenfalls wohl 99% aller Programmentwickler vollkommen am Arsch verbeigehen dürfte, welches aber bei Nichtbeachtung ebenfalls extreme Sicherheitsprobleme bedeuten kann. Nur handelt es sich bei SUID halt um ein uraltes und deshalb extrem gut bekanntes sowie exzellent dokumentiertes Unix-Feature (das auch fester Bestandteil jeder Sicherheitsbetrachtung ist), das man eher niemals unabsichtlich verwendet, während sich der Sicherheitsstack von Android ständig schnell weiterentwickelt und so gesehen recht neu (und deshalb notorisch schlecht dokumentiert) ist, und außerdem wird solch ein Flag in den Acitivities eher seuchenhaft Verwendung finden dürfte als ein SUID-Vorgang unter Unix. Aber nichtsdestotrotz handelt es sich um ein standadisiertes vorgesehenes Verhalten von Android das hier ausgenutzt wird, und das bei korrekter Beachtung eben keinerlei Sicherheitsproblem darstellen würde. Und ich würde sogar weitergehen, dass es ein notwendiges Verhalten darstellt, ohne das Android wesentliche Usability einbüßt.

3) Mal profan gesagt: Wenn die App-Entwickler unter Android zu dämlich sind, das Sicherheitsmodell von Android vollständig zu begreifen und deshalb zu sorglos mit den Berechtigungen (z. B. einer Activity) umgehen (was der absolute Normalfall ist. Hier geht es übrigens nicht um die App-Berechtigungen, sondern die einer Activity, was wesentlich seltener auf dem Fokus sein dürfte), dann kommt es eben zu Problemen. So wie es immer zu Problemen kommt, wenn irgendein Programmierer zu sorglos unterwegs ist (https://xkcd.com/2030/). Und das trifft nun einmal auf vermutlich 99,9% aller Programmierer (auch mich) und 99,99% aller Apps zu. Sprich, wenn eine App allowTaskReparenting für die Activity nutzt, dann ist das in der Regel ein Fehler weil die Activity dann auch prüfen muss, ob der Task, für den sie die Rechte anfordert, auch wirklich zu dem eigenen Programm gehört. (Oder habe ich da etwas falsch verstanden? Sorry, ich bin kein Android-Entwickler!)

4) Punkt 3 diskreditiert nicht die Entwickler, sondern stellt eine Kritik an der viel zu ausufernden Komplexität des Android Sicherheitsmodells dar, bei dem es viel zu einfach gemacht wurde, gravierendste Fehler zu begehen. Um das Sicherheitsmodell von Android korrekt begreifen zu können muss man mindestens so genial sein wie Einstein, Rutherford und Heisenberg zusammen und mindestens so paranoid wie Howling Mad Murdock. Das dürfte eher auf wenige Leute zutreffen (weshalb 99,9% der Android-Entwickler, mich eingeschlossen, eben zu dämlich sind ..). Und sobald man es dann verstanden hat kommt eine neue Android-Version heraus, die alle Karten komplett neu mischt. Wash, rinse, repeat. Die wahre Sicherheitslücke ist die "Insecurity by Obscurity"-Designentscheidung von Android! Das ausgenutzte Feature hingegen ist keine Sicherheitslücke per se.

TL;DR

1) grep -r allowTaskReparenting

Und dann die Activities checken, die dieses Feature nicht disablen (Achtung! Der default steht wohl auf allow, sprich, Activities die das NICHT setzen sind ggf. verwundbar! Kann mich natürlich hier irren, weil ich keine Ahnung von Android habe, aber besser sich in diesem Aspekt zu irren als blauäugig anzunehmen, alles sei per-Default sicher.)

2) Note to Self:

Bevor ich eine Android-App baue, Papier nochmals vollständig durchlesen, insbesondere Sektion 4.5, um all den Task-Kram zu verstehen, der eine Gefahr für die App darstellen kann.

-Tino
Edit: Typo