Sicherheit implementieren

Das Android-Sicherheitsteam erhält regelmäßig Informationsanfragen zur Vermeidung potenzieller Sicherheitsprobleme auf Android-Geräten. Gelegentlich überprüfen wir Geräte auch stichprobenartig und informieren Gerätehersteller und betroffene Partner über mögliche Probleme.

Auf dieser Seite finden Sie Best Practices für die Sicherheit, die auf unseren Erfahrungen basieren. Sie erweitern die von uns für Entwickler bereitgestellte Dokumentation „Designing for Security“ und enthalten spezielle Details zum Erstellen oder Installieren von Software auf Systemebene auf Geräten.

Um die Übernahme dieser Best Practices zu erleichtern, integriert das Android-Sicherheitsteam nach Möglichkeit Tests in die Android Compatibility Test Suite (CTS) und Android Lint . Wir ermutigen Geräteimplementierer, Tests beizusteuern, die anderen Android-Benutzern helfen können (sicherheitsbezogene Tests finden Sie unter root/cts/tests/tests/security/src/android/security/cts ).

Entwicklungsprozess

Nutzen Sie die folgenden Best Practices in Ihren Entwicklungsprozessen und Ihrer Entwicklungsumgebung.

Überprüfung des Quellcodes

Durch die Überprüfung des Quellcodes kann ein breites Spektrum an Sicherheitsproblemen aufgedeckt werden, darunter auch die in diesem Dokument genannten. Android empfiehlt dringend sowohl die manuelle als auch die automatisierte Überprüfung des Quellcodes. Empfohlene Vorgehensweise:

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

Verwendung automatisierter Tests

Durch automatisierte Tests kann ein breites Spektrum an Sicherheitsproblemen erkannt werden, darunter auch mehrere im Folgenden besprochene Probleme. Empfohlene Vorgehensweise:

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

Signieren von Systembildern

Die Signatur des Systemabbilds ist entscheidend für die Bestimmung der Integrität des Geräts. Empfohlene Vorgehensweise:

• Geräte dürfen nicht mit einem öffentlich bekannten Schlüssel signiert werden.
• Schlüssel, die zum Signieren von Geräten verwendet werden, sollten in einer Weise verwaltet werden, die den Branchenstandardpraktiken für den Umgang mit vertraulichen Schlüsseln entspricht, einschließlich eines Hardware-Sicherheitsmoduls (HSM), das begrenzten, überprüfbaren Zugriff bietet.

Signieren von Anwendungen (APKs)

Anwendungssignaturen spielen eine wichtige Rolle bei der Gerätesicherheit und werden für Berechtigungsprüfungen sowie Software-Updates verwendet. Bei der Auswahl eines Schlüssels zum Signieren von Anwendungen ist es wichtig zu berücksichtigen, ob eine Anwendung nur auf einem einzelnen Gerät verfügbar ist oder auf mehreren Geräten gleich ist. Empfohlene Vorgehensweise:

• Bewerbungen dürfen nicht mit einem öffentlich bekannten Schlüssel signiert werden.
• Schlüssel, die zum Signieren von Anwendungen verwendet werden, sollten in einer Weise verwaltet werden, die den Branchenstandardpraktiken für den Umgang mit vertraulichen Schlüsseln entspricht, einschließlich eines HSM, das begrenzten, überprüfbaren Zugriff bietet.
• Anwendungen sollten nicht mit dem Plattformschlüssel signiert werden.
• Anwendungen mit demselben Paketnamen sollten nicht mit unterschiedlichen Schlüsseln signiert werden. Dies tritt häufig auf, wenn eine Anwendung für verschiedene Geräte erstellt wird, insbesondere wenn der Plattformschlüssel verwendet wird. Wenn die Anwendung geräteunabhängig ist, verwenden Sie auf allen Geräten denselben Schlüssel. Wenn die Anwendung gerätespezifisch ist, erstellen Sie eindeutige Paketnamen pro Gerät und Schlüssel.

Anwendungen veröffentlichen

Google Play bietet Geräteherstellern die Möglichkeit, Anwendungen zu aktualisieren, ohne eine vollständige Systemaktualisierung durchzuführen. Dies kann die Reaktion auf Sicherheitsprobleme und die Bereitstellung neuer Funktionen beschleunigen und eine Möglichkeit bieten, sicherzustellen, dass Ihre Anwendung einen eindeutigen Paketnamen hat. Empfohlene Vorgehensweise:

• Laden Sie Ihre Anwendungen auf Google Play hoch, um automatische Updates zu ermöglichen, ohne dass ein vollständiges Over-the-Air-Update (OTA) erforderlich ist. Hochgeladene, aber unveröffentlichte Anwendungen können von Benutzern nicht direkt heruntergeladen werden, die Anwendungen werden jedoch weiterhin aktualisiert. Benutzer, die die App bereits installiert haben, können sie erneut installieren und/oder auf anderen Geräten installieren.
• Erstellen Sie einen Anwendungspaketnamen, der eindeutig mit Ihrem Unternehmen verknüpft ist, beispielsweise durch die Verwendung einer Unternehmensmarke.
• Von Geräteherstellern veröffentlichte Anwendungen sollten im Google Play Store hochgeladen werden, um eine Identitätsfälschung des Paketnamens durch Drittbenutzer zu vermeiden. Wenn ein Gerätehersteller eine App auf einem Gerät installiert, ohne die App 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 Benutzer präsentiert wird, können diese nicht zusammenhängenden Metadaten zu Verwirrung führen.

Auf Vorfälle reagieren

Externe Parteien müssen die Möglichkeit haben, Gerätehersteller zu gerätespezifischen Sicherheitsproblemen zu kontaktieren. Wir empfehlen die Einrichtung einer öffentlich zugänglichen E-Mail-Adresse zur Verwaltung von Sicherheitsvorfällen. Empfohlene Vorgehensweise:

• Erstellen Sie eine Adresse security@your-company.com oder eine ähnliche Adresse und veröffentlichen Sie diese.
• Wenn Sie auf ein Sicherheitsproblem aufmerksam werden, das Android-Betriebssysteme oder Android-Geräte mehrerer Gerätehersteller betrifft, sollten Sie sich an das Android-Sicherheitsteam wenden, indem Sie einen Sicherheitsfehlerbericht einreichen.

Produktimplementierung

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

Root-Prozesse isolieren

Root-Prozesse sind das häufigste Ziel von Angriffen zur Rechteausweitung. Daher verringert die Reduzierung der Anzahl der Root-Prozesse das Risiko einer Rechteausweitung. CTS umfasst einen Informationstest, der Root-Prozesse auflistet. Empfohlene Vorgehensweise:

• Geräte sollten den minimal erforderlichen Code als Root ausführen. Verwenden Sie nach Möglichkeit einen regulären Android-Prozess anstelle eines Root-Prozesses. Das ICS Galaxy Nexus verfügt nur über sechs Root-Prozesse: vold, inetd, zygote, tf_daemon, ueventd und init. Wenn ein Prozess als Root auf einem Gerät ausgeführt werden muss, dokumentieren Sie den Prozess in einer AOSP-Funktionsanforderung, damit er öffentlich überprüft werden kann.
• Wo möglich, sollte der Root-Code von nicht vertrauenswürdigen Daten isoliert und über IPC zugänglich gemacht werden. Reduzieren Sie beispielsweise die Root-Funktionalität auf einen kleinen Dienst, auf den über Binder zugegriffen werden kann, und stellen Sie den Dienst mit Signaturberechtigung einer Anwendung mit geringen oder keinen Berechtigungen zur Verarbeitung des Netzwerkverkehrs zur Verfügung.
• Root-Prozesse dürfen nicht auf einem Netzwerk-Socket lauschen.
• Root-Prozesse dürfen keine allgemeine Laufzeit für Anwendungen (z. B. eine Java VM) bereitstellen.

System-Apps isolieren

Im Allgemeinen sollten vorinstallierte Apps nicht mit der gemeinsamen System-UID ausgeführt werden. Wenn es jedoch erforderlich ist, dass eine App die gemeinsame UID des Systems oder eines anderen privilegierten Dienstes verwendet, sollte die App keine Dienste, Rundfunkempfänger oder Inhaltsanbieter exportieren, auf die von Benutzern installierte Drittanbieter-Apps zugreifen können. Empfohlene Vorgehensweise:

• Geräte sollten den minimal erforderlichen Code als System ausführen. Verwenden Sie nach Möglichkeit einen Android-Prozess mit eigener UID, anstatt die System-UID wiederzuverwenden.
• Wenn möglich, sollte der Systemcode von nicht vertrauenswürdigen Daten isoliert werden und IPC nur anderen vertrauenswürdigen Prozessen zugänglich gemacht werden.
• Systemprozesse dürfen nicht auf einem Netzwerk-Socket lauschen.

Prozesse isolieren

Die Android Application Sandbox bietet Anwendungen mit der Erwartung, dass sie von anderen Prozessen im System, einschließlich Root-Prozessen und Debuggern, isoliert sind. Sofern das Debuggen nicht ausdrücklich von der Anwendung und dem Benutzer aktiviert wird, sollte keine Anwendung diese Erwartung verletzen. Empfohlene Vorgehensweise:

• Root-Prozesse dürfen nicht auf Daten in einzelnen Anwendungsdatenordnern zugreifen, es sei denn, sie verwenden eine dokumentierte Android-Debugging-Methode.
• Root-Prozesse dürfen nicht auf den Speicher von Anwendungen zugreifen, es sei denn, sie verwenden eine dokumentierte Android-Debugging-Methode.
• Geräte dürfen keine Anwendung enthalten, die auf Daten oder Speicher anderer Anwendungen oder Prozesse zugreift.

SUID-Dateien sichern

Neue setuid-Programme sollten nicht für nicht vertrauenswürdige Programme zugänglich sein. Setuid-Programme weisen häufig Schwachstellen auf, die für den Root-Zugriff genutzt werden können. Bemühen Sie sich daher, die Verfügbarkeit des Setuid-Programms für nicht vertrauenswürdige Anwendungen zu minimieren. Empfohlene Vorgehensweise:

• SUID-Prozesse dürfen keine Shell oder Hintertür bereitstellen, die zur Umgehung des Android-Sicherheitsmodells verwendet werden kann.
• SUID-Programme dürfen von keinem Benutzer beschreibbar sein.
• SUID-Programme sollten nicht weltweit lesbar oder ausführbar sein. Erstellen Sie eine Gruppe, beschränken Sie den Zugriff auf die SUID-Binärdatei auf Mitglieder dieser Gruppe und platzieren Sie alle Anwendungen, die das SUID-Programm ausführen können sollen, in dieser Gruppe.
• SUID-Programme sind eine häufige Quelle für das Rooten von Geräten durch Benutzer. Um dieses Risiko zu verringern, sollten SUID-Programme vom Shell-Benutzer nicht ausführbar sein.

Der CTS-Verifizierer umfasst einen Informationstest, der SUID-Dateien auflistet. Einige Setuid-Dateien sind gemäß CTS-Tests nicht zulässig.

Sicherung von Hörsteckdosen

CTS-Tests schlagen fehl, wenn ein Gerät an einem beliebigen Port und einer beliebigen Schnittstelle lauscht. Im Falle eines Fehlers überprüft Android, ob die folgenden Best Practices angewendet werden:

• Auf dem Gerät sollten keine Überwachungsports vorhanden sein.
• Abhörports müssen ohne OTA deaktiviert werden können. Dabei kann es sich entweder um eine Änderung der Server- oder Benutzergerätekonfiguration handeln.
• Root-Prozesse dürfen keinen Port überwachen.
• Prozesse, die der System-UID gehören, dürfen keinen Port überwachen.
• Für lokale IPCs, die Sockets verwenden, müssen Anwendungen einen UNIX-Domänen-Socket verwenden, dessen Zugriff auf eine Gruppe beschränkt ist. Erstellen Sie einen Dateideskriptor für den IPC und machen Sie ihn zu +RW für eine bestimmte UNIX-Gruppe. Alle Clientanwendungen müssen sich innerhalb dieser UNIX-Gruppe befinden.
• Einige Geräte mit mehreren Prozessoren (z. B. ein vom Anwendungsprozessor getrenntes Funkgerät/Modem) verwenden Netzwerk-Sockets für die Kommunikation zwischen Prozessoren. In solchen Fällen muss der für die Kommunikation zwischen Prozessoren verwendete Netzwerk-Socket eine isolierte Netzwerkschnittstelle verwenden, um den Zugriff durch nicht autorisierte Anwendungen auf das Gerät zu verhindern (d. h. iptables verwenden, um den Zugriff durch andere Anwendungen auf dem Gerät zu verhindern).
• Daemons, die Überwachungsports verwalten, müssen robust gegenüber fehlerhaften Daten sein. Google führt möglicherweise Fuzz-Tests für den Port mithilfe eines nicht autorisierten Clients und, sofern möglich, eines autorisierten Clients durch. Alle Abstürze werden als Fehler mit einem entsprechenden Schweregrad protokolliert.

Daten protokollieren

Die Protokollierung von Daten erhöht das Risiko der Offenlegung dieser Daten und verringert die Systemleistung. Aufgrund der Protokollierung vertraulicher Benutzerdaten durch standardmäßig auf Android-Geräten installierte Anwendungen kam es zu mehreren Vorfällen im Bereich der öffentlichen Sicherheit. Empfohlene Vorgehensweise:

• Anwendungen oder Systemdienste sollten keine von Drittanbieteranwendungen bereitgestellten Daten protokollieren, die möglicherweise vertrauliche Informationen enthalten.
• Anwendungen dürfen im Rahmen des normalen Betriebs keine personenbezogenen Daten (PII) protokollieren.

CTS umfasst Tests, die das Vorhandensein potenziell vertraulicher Informationen in den Systemprotokollen prüfen.

Beschränken des Verzeichniszugriffs

Von allen Benutzern beschreibbare Verzeichnisse können Sicherheitslücken mit sich bringen und es einer Anwendung ermöglichen, vertrauenswürdige Dateien umzubenennen, Dateien zu ersetzen oder Symlink-basierte Angriffe durchzuführen (Angreifer können einen Symlink zu einer Datei verwenden, um ein vertrauenswürdiges Programm dazu zu verleiten, Aktionen auszuführen, die es nicht ausführen sollte). Beschreibbare Verzeichnisse können auch verhindern, dass bei der Deinstallation einer Anwendung alle mit einer Anwendung verknüpften Dateien ordnungsgemäß bereinigt werden.

Als Best Practice gilt, dass vom System oder Root-Benutzern erstellte Verzeichnisse nicht für alle Benutzer beschreibbar sein sollten. CTS-Tests helfen dabei, diese Best Practice durchzusetzen, indem sie bekannte Verzeichnisse testen.

Konfigurationsdateien sichern

Viele Treiber und Dienste basieren auf Konfigurations- und Datendateien, die in Verzeichnissen wie /system/etc und /data gespeichert sind. Wenn diese Dateien von einem privilegierten Prozess verarbeitet werden und weltweit beschreibbar sind, ist es für eine App möglich, eine Schwachstelle im Prozess auszunutzen, indem sie schädliche Inhalte in der weltweit beschreibbaren Datei erstellt. Empfohlene Vorgehensweise:

• Konfigurationsdateien, die von privilegierten Prozessen verwendet werden, sollten nicht weltweit lesbar sein.
• Konfigurationsdateien, die von privilegierten Prozessen verwendet werden, dürfen nicht weltweit beschreibbar sein.

Speichern nativer Codebibliotheken

Jeglicher Code, der von Prozessen privilegierter Gerätehersteller verwendet wird, muss sich in /vendor oder /system befinden; Diese Dateisysteme werden beim Booten schreibgeschützt gemountet. Als Best Practice sollten sich Bibliotheken, die von System- oder anderen hochprivilegierten Apps verwendet werden, die auf dem Gerät installiert sind, ebenfalls in diesen Dateisystemen befinden. Dies kann eine Sicherheitslücke verhindern, die es einem Angreifer ermöglichen könnte, den Code zu kontrollieren, den ein privilegierter Prozess ausführt.

Beschränken des Zugriffs auf Gerätetreiber

Nur vertrauenswürdiger Code sollte direkten Zugriff auf Treiber haben. Wenn möglich, besteht die bevorzugte Architektur darin, einen Einzweck-Daemon bereitzustellen, der Aufrufe an den Treiber weiterleitet und den Treiberzugriff auf diesen Daemon einschränkt. Als bewährte Methode sollten Treibergeräteknoten nicht weltweit lesbar oder beschreibbar sein. CTS-Tests tragen zur Durchsetzung dieser Best Practice bei, indem sie nach bekannten Instanzen offengelegter Treiber suchen.

ADB deaktivieren

Android Debug Bridge (ADB) ist ein wertvolles Entwicklungs- und Debugging-Tool, ist jedoch für den Einsatz in kontrollierten, sicheren Umgebungen konzipiert und sollte nicht für den allgemeinen Gebrauch aktiviert werden. Empfohlene Vorgehensweise:

• ADB muss standardmäßig deaktiviert sein.
• ADB muss vom Benutzer die Aktivierung erfordern, bevor Verbindungen akzeptiert werden.

Bootloader entsperren

Viele Android-Geräte unterstützen das Entsperren, sodass der Gerätebesitzer die Systempartition ändern und/oder ein benutzerdefiniertes Betriebssystem installieren kann. Zu den häufigsten Anwendungsfällen gehören die Installation eines Drittanbieter-ROMs und die Durchführung einer Entwicklung auf Systemebene auf dem Gerät. Beispielsweise kann ein Besitzer eines Google Nexus-Geräts fastboot oem unlock ausführen, um den Entsperrvorgang zu starten, wodurch dem Benutzer die folgende Meldung angezeigt wird:

Als Best Practice gilt, dass entsperrbare Android-Geräte vor dem Entsperren alle Benutzerdaten sicher löschen müssen. Wenn beim Entsperren nicht alle Daten ordnungsgemäß gelöscht werden, kann ein Angreifer in der Nähe unbefugten Zugriff auf vertrauliche Android-Benutzerdaten erhalten. Um die Offenlegung von Benutzerdaten zu verhindern, muss ein Gerät, das die Entsperrung unterstützt, diese ordnungsgemäß implementieren (wir haben zahlreiche Fälle gesehen, in denen Gerätehersteller die Entsperrung nicht ordnungsgemäß implementiert haben). Ein ordnungsgemäß durchgeführter Entsperrvorgang weist folgende Eigenschaften auf:

• Wenn der Entsperrbefehl vom Benutzer bestätigt wird, muss das Gerät eine sofortige Datenlöschung starten. Das Flag unlocked darf erst nach Abschluss des sicheren Löschvorgangs gesetzt werden.
• Wenn ein sicherer Löschvorgang nicht abgeschlossen werden kann, muss das Gerät im gesperrten Zustand bleiben.
• Wenn vom zugrunde liegenden Blockgerät unterstützt, sollte ioctl(BLKSECDISCARD) oder ein gleichwertiges Produkt verwendet werden. Bei eMMC-Geräten bedeutet dies die Verwendung eines Secure Erase- oder Secure Trim-Befehls. Für eMMC 4.5 und höher bedeutet dies die Verwendung eines normalen Erase- oder Trim-Vorgangs, gefolgt von einem Sanitize-Vorgang.
• 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 das Überschreiben der Blockgeräte mit ausschließlich Nullen akzeptabel.
• Ein Endbenutzer muss die Möglichkeit haben, zu verlangen, dass Benutzerdaten vor dem Flashen einer Partition gelöscht werden. Auf Nexus-Geräten erfolgt dies beispielsweise über den Befehl fastboot oem lock .
• Ein Gerät kann über Efuses oder ähnliche Mechanismen aufzeichnen, ob ein Gerät entsperrt und/oder wieder gesperrt wurde.

Diese Anforderungen stellen sicher, dass alle Daten nach Abschluss eines Entsperrvorgangs zerstört werden. Das Versäumnis, diese Schutzmaßnahmen zu implementieren, wird als Sicherheitslücke mittlerer Stufe betrachtet.

Ein entsperrtes Gerät kann anschließend mit dem Befehl fastboot oem lock wieder gesperrt werden. Das Sperren des Bootloaders bietet mit dem neuen benutzerdefinierten Betriebssystem denselben Schutz für Benutzerdaten wie mit dem ursprünglichen Betriebssystem des Geräteherstellers (z. B. werden Benutzerdaten gelöscht, wenn das Gerät erneut entsperrt wird).