Sicherheit implementieren

Das Android-Sicherheitsteam erhält regelmäßig Anfragen zu Informationen zum Verhindern potenzieller Sicherheitsprobleme auf Android-Geräten. Gelegentlich führen wir auch Stichprobenprüfungen von Geräten durch und informieren Gerätehersteller und betroffene Partner über potenzielle Probleme.

Auf dieser Seite finden Sie Best Practices für die Sicherheit, die auf unseren Erfahrungen basieren. Sie ergänzen die Dokumentation Designing for Security, die wir für Entwickler bereitgestellt haben, und enthalten Details, die speziell für das Erstellen oder Installieren von Software auf Systemebene auf Geräten gelten.

Um die Umsetzung dieser Best Practices zu erleichtern, integriert das Android-Sicherheitsteam nach Möglichkeit Tests in die Android Compatibility Test Suite (CTS) und Android Lint. Wir empfehlen Geräteimplementierern, Tests zu erstellen, die anderen Android-Nutzern helfen können. Sicherheitsbezogene Tests finden Sie unter root/cts/tests/tests/security/src/android/security/cts.

Entwicklungsablauf

Wenden Sie die folgenden Best Practices in Ihren Entwicklungsprozessen und ‑umgebungen an.

Quellcode prüfen

Durch die Überprüfung des Quellcodes können eine Vielzahl von Sicherheitsproblemen erkannt werden, einschließlich der in diesem Dokument aufgeführten. Android empfiehlt sowohl die manuelle als auch die automatische Überprüfung des Quellcodes. Best Practices:

• Führen Sie Android Lint mit dem Android SDK auf dem gesamten App-Code aus und beheben Sie alle erkannten Probleme.
• Nativer Code sollte mit einem automatisierten Tool analysiert werden, das Probleme mit der Speicherverwaltung wie Pufferüberläufe und Off-by-One-Fehler erkennen kann.
• Das Android-Buildsystem unterstützt viele der LLVM-Sanitizer, z. B. AddressSanitizer und UndefinedBehaviorSanitizer, die für diesen Zweck verwendet werden können.

Automatisierte Tests verwenden

Mit automatisierten Tests können eine Vielzahl von Sicherheitsproblemen erkannt werden, darunter auch einige der unten aufgeführten. Best Practices:

• Die CTS wird regelmäßig mit Sicherheitstests aktualisiert. Führen Sie die neueste Version der CTS aus, um die Kompatibilität zu prüfen.
• Führen Sie die CTS regelmäßig während des gesamten Entwicklungsprozesses durch, um Probleme frühzeitig zu erkennen und die Zeit bis zur Fehlerbehebung zu verkürzen. Android verwendet CTS als Teil der kontinuierlichen Integration in unserem automatisierten Build-Prozess, der mehrmals täglich ausgeführt wird.
• Gerätehersteller sollten Sicherheitstests von Schnittstellen automatisieren, einschließlich Tests mit fehlerhaften Eingaben (Fuzz-Tests).

Bilder von Beschilderungen

Die Signatur des System-Images ist entscheidend für die Bestimmung der Integrität des Geräts. Best Practices:

• Geräte dürfen nicht mit einem öffentlich bekannten Schlüssel signiert sein.
• Schlüssel, die zum Signieren von Geräten verwendet werden, sollten gemäß den Branchenstandards für den Umgang mit sensiblen Schlüsseln verwaltet werden, einschließlich eines Hardwaresicherheitsmoduls (HSM), das eingeschränkten, auditierbaren Zugriff bietet.

Apps (APKs) signieren

App-Signaturen spielen eine wichtige Rolle bei der Gerätesicherheit und werden sowohl für Berechtigungsprüfungen als auch für Softwareupdates verwendet. Bei der Auswahl eines Schlüssels für die App-Signatur ist es wichtig zu berücksichtigen, ob eine App nur auf einem einzelnen Gerät oder auf mehreren Geräten verfügbar sein soll. Best Practices:

• Apps dürfen nicht mit einem öffentlich bekannten Schlüssel signiert sein.
• Schlüssel, die zum Signieren von Apps verwendet werden, sollten gemäß den branchenüblichen Praktiken für den Umgang mit sensiblen Schlüsseln verwaltet werden, einschließlich eines HSM, das eingeschränkten, auditierbaren Zugriff bietet.
• Apps dürfen nicht mit dem Plattformschlüssel signiert sein.
• Apps mit demselben Paketnamen dürfen nicht mit unterschiedlichen Schlüsseln signiert sein. Das tritt häufig beim Erstellen einer App für verschiedene Geräte auf, insbesondere wenn der Plattformschlüssel verwendet wird. Wenn die App geräteunabhängig ist, verwenden Sie auf allen Geräten denselben Schlüssel. Wenn die App gerätespezifisch ist, erstellen Sie eindeutige Paketnamen pro Gerät und Schlüssel.

Apps veröffentlichen

Google Play bietet Geräteherstellern die Möglichkeit, Apps zu aktualisieren, ohne ein vollständiges Systemupdate durchzuführen. So können Sicherheitsprobleme schneller behoben und neue Funktionen schneller bereitgestellt werden. Außerdem können Sie so dafür sorgen, dass Ihre App einen eindeutigen Paketnamen hat. Best Practices:

• Laden Sie Ihre Apps zu Google Play hoch, um automatische Updates zu ermöglichen, ohne dass ein vollständiges Over-the-Air-Update (OTA-Update) erforderlich ist. Apps, die hochgeladen, aber nicht veröffentlicht wurden, können von Nutzern nicht direkt heruntergeladen werden. Sie werden aber trotzdem aktualisiert. Nutzer, die die App bereits installiert haben, können sie neu installieren und/oder auf anderen Geräten installieren.
• Erstellen Sie einen App-Paketnamen, der eindeutig mit Ihrem Unternehmen in Verbindung steht, z. B. durch Verwendung einer Unternehmensmarke.
• Von Geräteherstellern veröffentlichte Apps sollten in den Google Play Store hochgeladen werden, um Identitätsdiebstahl durch Drittanbieter zu vermeiden. Wenn ein Gerätehersteller eine App auf einem Gerät installiert, ohne sie im Play Store zu veröffentlichen, könnte ein anderer Entwickler dieselbe App hochladen, denselben Paketnamen verwenden und die Metadaten für die App ändern. Wenn die App dem Nutzer präsentiert wird, könnten diese nicht zugehörigen Metadaten zu Verwirrung führen.

Auf Vorfälle reagieren

Externe Parteien müssen die Möglichkeit haben, sich bei gerätespezifischen Sicherheitsproblemen an Gerätehersteller zu wenden. Wir empfehlen, eine öffentlich zugängliche E-Mail-Adresse für die Verwaltung von Sicherheitsvorfällen zu erstellen. Best Practices:

• Erstellen Sie eine E-Mail-Adresse wie sicherheit@IhrUnternehmen.de und machen Sie sie öffentlich bekannt.
• Wenn Sie auf ein Sicherheitsproblem stoßen, das das Android-Betriebssystem oder Android-Geräte verschiedener Hersteller betrifft, sollten Sie sich an das Android-Sicherheitsteam wenden. Reichen Sie dazu einen Sicherheitsfehlerbericht ein.

Produkte implementieren

Beachten Sie bei der Implementierung eines Produkts die folgenden Best Practices.

Root-Prozesse isolieren

Root-Prozesse sind das häufigste Ziel von Angriffen auf die Rechteausweitung. Wenn Sie die Anzahl der Root-Prozesse reduzieren, verringern Sie das Risiko der Rechteausweitung. CTS enthält einen informativen Test, in dem Root-Prozesse aufgelistet werden. Best Practices:

• Auf Geräten sollte der erforderliche Code mindestens als Root ausgeführt werden. Verwenden Sie nach Möglichkeit einen regulären Android-Prozess anstelle eines Root-Prozesses. Das ICS Galaxy Nexus hat nur sechs Root-Prozesse: vold, inetd, zygote, tf_daemon, ueventd und init. Wenn ein Prozess auf einem Gerät als Root ausgeführt werden muss, dokumentieren Sie den Prozess in einer AOSP-Funktionsanfrage, damit er öffentlich überprüft werden kann.
• Wenn möglich, sollte Root-Code von nicht vertrauenswürdigen Daten getrennt werden und der Zugriff über IPC erfolgen. Sie können beispielsweise die Root-Funktionen auf einen kleinen Dienst beschränken, der über Binder zugänglich ist, und den Dienst mit einer Signaturberechtigung für eine App mit wenigen oder keinen Berechtigungen für die Verarbeitung von Netzwerkverkehr freigeben.
• Root-Prozesse dürfen nicht auf einem Netzwerk-Socket warten.
• Root-Prozesse dürfen keine allgemeine Laufzeit für Apps bereitstellen (z. B. eine Java-VM).

System-Apps isolieren

Vorinstallierte Apps sollten im Allgemeinen nicht mit der freigegebenen System-UID ausgeführt werden. Wenn eine App jedoch die freigegebene UID des Systems oder eines anderen privilegierten Dienstes verwenden muss, darf sie keine Dienste, Broadcast-Empfänger oder Inhaltsanbieter exportieren, auf die von Nutzern installierte Drittanbieter-Apps zugreifen können. Best Practices:

• Auf Geräten sollte der erforderliche Mindestcode als System ausgeführt werden. Verwenden Sie nach Möglichkeit einen Android-Prozess mit einer eigenen UID, anstatt die System-UID wiederzuverwenden.
• Systemcode sollte nach Möglichkeit von nicht vertrauenswürdigen Daten isoliert und die IPC nur für andere vertrauenswürdige Prozesse freigegeben werden.
• Systemprozesse dürfen keinen Netzwerk-Socket überwachen.

Prozesse isolieren

Die Android-Anwendungs-Sandbox bietet Apps eine gewisse Isolation von anderen Prozessen im System, einschließlich Root-Prozessen und Debuggern. Sofern das Debuggen nicht ausdrücklich von der App und dem Nutzer aktiviert wurde, sollte keine App gegen diese Erwartung verstoßen. Best Practices:

• Root-Prozesse dürfen nicht auf Daten in einzelnen App-Datenordnern zugreifen, es sei denn, eine dokumentierte Android-Debugging-Methode wird verwendet.
• Root-Prozesse dürfen nicht auf den Arbeitsspeicher von Apps zugreifen, es sei denn, eine dokumentierte Android-Debugging-Methode wird verwendet.
• Auf den Geräten dürfen keine Apps installiert sein, die auf Daten oder den Arbeitsspeicher anderer Apps oder Prozesse zugreifen.

SUID-Dateien schützen

Neue setuid-Programme sollten nicht von nicht vertrauenswürdigen Programmen zugänglich sein. Setuid-Programme sind häufig die Quelle von Sicherheitslücken, die zum Erlangen des Root-Zugriffs genutzt werden können. Versuchen Sie daher, die Verfügbarkeit des Setuid-Programms für nicht vertrauenswürdige Apps zu minimieren. Best Practices:

• SUID-Prozesse dürfen keine Shell oder Backdoor bereitstellen, mit der das Android-Sicherheitsmodell umgangen werden kann.
• SUID-Programme dürfen von keinem Nutzer beschreibbar sein.
• SUID-Programme sollten nicht allgemein lesbar oder ausführbar sein. Erstellen Sie eine Gruppe, beschränken Sie den Zugriff auf die SUID-Binärdatei auf Mitglieder dieser Gruppe und fügen Sie alle Apps, die das SUID-Programm ausführen können sollen, dieser Gruppe hinzu.
• SUID-Programme sind eine häufige Quelle für das Rooten von Geräten durch Nutzer. Um dieses Risiko zu verringern, sollten SUID-Programme nicht vom Shell-Nutzer ausführbar sein.

Der CTS-Verifier enthält einen informativen Test, in dem SUID-Dateien aufgeführt sind. Einige setuid-Dateien sind gemäß CTS-Tests nicht zulässig.

Sichere Listener-Sockets

CTS-Tests schlagen fehl, wenn ein Gerät an einem beliebigen Port und einer beliebigen Schnittstelle lauscht. Bei einem Fehler prüft Android, ob die folgenden Best Practices angewendet werden:

• Es sollten keine Ports zum Zuhören auf dem Gerät vorhanden sein.
• Überwachungsports müssen ohne Over-the-air-Aktualisierung deaktiviert werden können. Dies kann eine Änderung der Server- oder Nutzergerätekonfiguration sein.
• Root-Prozesse dürfen keinen Port überwachen.
• Prozesse, deren Eigentümer die System-UID ist, dürfen keinen Port beobachten.
• Für die lokale IPC mit Sockets müssen Apps einen UNIX-Domain-Socket mit Zugriffsbeschränkung auf eine Gruppe verwenden. Erstellen Sie einen Dateideskriptor für die IPC und weisen Sie ihm die Zugriffsrechte „Lesen/Schreiben“ für eine bestimmte UNIX-Gruppe zu. Alle Client-Anwendungen müssen zu dieser UNIX-Gruppe gehören.
• Einige Geräte mit mehreren Prozessoren (z.B. ein Funkschnittstellen-/Modem, das vom App-Prozessor getrennt ist) verwenden Netzwerk-Sockets, um zwischen den Prozessoren zu kommunizieren. In solchen Fällen muss der für die Kommunikation zwischen den Prozessoren verwendete Netzwerk-Socket eine isolierte Netzwerkschnittstelle verwenden, um den Zugriff von nicht autorisierten Apps auf dem Gerät zu verhindern. Verwenden Sie also iptables, um den Zugriff anderer Apps auf dem Gerät zu verhindern.
• Daemons, die überwachte Ports verarbeiten, müssen robust gegen fehlerhafte Daten sein. Google kann Fuzz-Tests für den Port mit einem nicht autorisierten und, sofern möglich, mit einem autorisierten Client durchführen. Alle Abstürze werden als Fehler mit dem entsprechenden Schweregrad gemeldet.

Protokolldaten

Das Protokollieren von Daten erhöht das Risiko einer Offenlegung dieser Daten und verringert die Systemleistung. Es gab mehrere öffentliche Sicherheitsvorfälle, die auf das Protokollieren vertraulicher Nutzerdaten durch Apps zurückzuführen sind, die standardmäßig auf Android-Geräten installiert sind. Best Practices:

• Apps oder Systemdienste dürfen keine Daten von Drittanbieter-Apps protokollieren, die vertrauliche Informationen enthalten könnten.
• Apps dürfen im Rahmen des normalen Betriebs keine personenidentifizierbaren Informationen erfassen.

CTS umfasst Tests, bei denen geprüft wird, ob in den Systemprotokollen potenziell vertrauliche Informationen vorhanden sind.

Zugriff auf das Verzeichnis einschränken

Ordner, die von allen Nutzern beschreibbar sind, können Sicherheitslücken verursachen und es einer App ermöglichen, vertrauenswürdige Dateien umzubenennen, zu ersetzen oder Symlink-basierte Angriffe durchzuführen. Angreifer können einen Symlink zu einer Datei verwenden, um ein vertrauenswürdiges Programm dazu zu bringen, Aktionen auszuführen, die es nicht tun sollte. Schreibbare Verzeichnisse können auch verhindern, dass beim Deinstallieren einer App alle mit der App verknüpften Dateien ordnungsgemäß bereinigt werden.

Verzeichnisse, die vom System oder Root-Nutzer erstellt wurden, sollten nach Möglichkeit nicht von allen Nutzern beschreibbar sein. CTS-Tests tragen dazu bei, diese Best Practice durch das Testen bekannter Verzeichnisse durchzusetzen.

Sichere Konfigurationsdateien

Viele Treiber und Dienste benötigen Konfigurations- und Datendateien, die in Verzeichnissen wie /system/etc und /data gespeichert sind. Wenn diese Dateien von einem privilegierten Prozess verarbeitet werden und für alle Nutzer beschreibbar sind, kann eine App eine Sicherheitslücke im Prozess ausnutzen, indem sie schädliche Inhalte in die Datei schreibt. Best Practices:

• Konfigurationsdateien, die von privilegierten Prozessen verwendet werden, sollten nicht von allen Nutzern lesbar sein.
• Konfigurationsdateien, die von privilegierten Prozessen verwendet werden, dürfen nicht für alle beschreibbar sein.

Native Code-Bibliotheken speichern

Jeglicher Code, der von privilegierten Prozessen des Geräteherstellers verwendet wird, muss sich in /vendor oder /system befinden. Diese Dateisysteme werden beim Starten nur schreibgeschützt bereitgestellt. Als Best Practice sollten sich auch Bibliotheken, die vom System oder anderen auf dem Gerät installierten Apps mit hohen Berechtigungen verwendet werden, in diesen Dateisystemen befinden. So lässt sich eine Sicherheitslücke verhindern, durch die ein Angreifer den Code steuern könnte, der von einem privilegierten Prozess ausgeführt wird.

Zugriff für Gerätetreiber einschränken

Nur vertrauenswürdiger Code sollte direkten Zugriff auf Treiber haben. Nach Möglichkeit wird ein spezieller Daemon bereitgestellt, der Aufrufe an den Treiber weiterleitet und den Treiberzugriff auf diesen Daemon einschränkt. Als Best Practice sollten Treibergeräteknoten nicht für alle lesbar oder beschreibbar sein. CTS-Tests tragen dazu bei, diese Best Practice durch die Prüfung auf bekannte Instanzen freigegebener Treiber durchzusetzen.

ADB deaktivieren

Android Debug Bridge (adb) ist ein wertvolles Entwicklungs- und Debugging-Tool, das jedoch für die Verwendung in kontrollierten, sicheren Umgebungen entwickelt wurde und nicht für die allgemeine Nutzung aktiviert werden sollte. Best Practices:

• ADB muss standardmäßig deaktiviert sein.
• ADB muss den Nutzer dazu auffordern, es zu aktivieren, bevor Verbindungen akzeptiert werden.

Bootloader entsperren

Viele Android-Geräte unterstützen das Entsperren, sodass der Geräteinhaber die Systempartition ändern und/oder ein benutzerdefiniertes Betriebssystem installieren kann. Gängige Anwendungsfälle sind die Installation eines ROMs von Drittanbietern und die Entwicklung auf Systemebene auf dem Gerät. Ein Google Nexus-Geräteeigentümer kann beispielsweise fastboot oem unlock ausführen, um den Entsperrvorgang zu starten. Daraufhin wird dem Nutzer die folgende Meldung angezeigt:

Als Best Practice sollten alle Nutzerdaten auf entsperrbaren Android-Geräten vor der Entsperrung sicher gelöscht werden. Wenn nicht alle Daten beim Entsperren ordnungsgemäß gelöscht werden, kann ein Angreifer, der sich in der Nähe des Geräts befindet, unbefugten Zugriff auf vertrauliche Android-Nutzerdaten erhalten. Um die Offenlegung von Nutzerdaten zu verhindern, muss die Entsperrung auf einem Gerät, das diese Funktion unterstützt, ordnungsgemäß implementiert sein. Wir haben bereits zahlreiche Fälle gesehen, in denen die Entsperrung von Geräteherstellern nicht ordnungsgemäß implementiert wurde. Ein ordnungsgemäß implementierter Entsperrvorgang hat die folgenden Eigenschaften:

• Wenn der Befehl zum Entsperren vom Nutzer bestätigt wurde, muss das Gerät sofort mit dem Löschen der Daten beginnen. Das Flag unlocked darf erst gesetzt werden, wenn das sichere Löschen abgeschlossen ist.
• Wenn das sichere Löschen nicht abgeschlossen werden kann, muss das Gerät gesperrt bleiben.
• Wenn vom zugrunde liegenden Blockgerät unterstützt, sollte ioctl(BLKSECDISCARD) oder ein vergleichbarer Wert verwendet werden. Bei eMMC-Geräten bedeutet dies, dass der Befehl „Secure Erase“ oder „Secure Trim“ verwendet werden muss. Bei eMMC 4.5 und höher bedeutet das, dass ein normaler Lösch- oder Trimmvorgang auf einen Vorgang zum Bereinigen folgt.
• Wenn BLKSECDISCARD vom zugrunde liegenden Blockgerät nicht unterstützt wird, muss stattdessen ioctl(BLKDISCARD) verwendet werden. Auf eMMC-Geräten ist dies ein normaler Trim-Vorgang.
• Wenn BLKDISCARD nicht unterstützt wird, ist es zulässig, die Blockgeräte mit Nullen zu überschreiben.
• Endnutzer müssen die Möglichkeit haben, zu verlangen, dass Nutzerdaten vor dem Flashen einer Partition gelöscht werden. Auf Nexus-Geräten geschieht dies beispielsweise über den Befehl fastboot oem lock.
• Ein Gerät kann über Efuses oder einen ähnlichen Mechanismus aufzeichnen, ob es entsperrt und/oder wieder gesperrt wurde.

So wird sichergestellt, dass alle Daten nach Abschluss eines Entsperrvorgangs gelöscht werden. Das Fehlen dieser Schutzmaßnahmen wird als Sicherheitslücke mittleren Risikos eingestuft.

Ein entsperrtes Gerät kann mit dem Befehl fastboot oem lock wieder gesperrt werden. Durch das Sperren des Bootloaders werden die Nutzerdaten mit dem neuen benutzerdefinierten Betriebssystem genauso geschützt wie mit dem ursprünglichen Betriebssystem des Geräteherstellers. Beispielsweise werden Nutzerdaten gelöscht, wenn das Gerät wieder entsperrt wird.