Das Android-Sicherheitsteam ist für die Verwaltung von Sicherheitslücken verantwortlich, die in der Android-Plattform und vielen der Kern-Android-Apps entdeckt wurden, die mit Android-Geräten gebündelt sind.
Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Recherchen und reagiert auch auf von Drittanbietern gemeldete Fehler. Zu den Quellen externer Fehler zählen Probleme, die über das Schwachstellenformular gemeldet wurden, veröffentlichte und vorveröffentlichte wissenschaftliche Forschung, vorgelagerte Open-Source-Projektbetreuer, Benachrichtigungen von unseren Geräteherstellerpartnern und öffentlich bekannt gegebene Probleme, die in Blogs oder sozialen Medien gepostet wurden.
Melden von Sicherheitsproblemen
Jeder Entwickler, Android-Benutzer oder Sicherheitsforscher kann das Android-Sicherheitsteam über das Schwachstellenformular über potenzielle Sicherheitsprobleme informieren.
Als Sicherheitsprobleme gekennzeichnete Fehler sind extern nicht sichtbar, aber sie können schließlich sichtbar gemacht werden, nachdem das Problem bewertet oder behoben wurde. Wenn Sie planen, einen Patch oder Compatibility Test Suite (CTS)-Test einzureichen, um ein Sicherheitsproblem zu beheben, hängen Sie ihn bitte an den Fehlerbericht an und warten Sie auf eine Antwort, bevor Sie den Code auf AOSP hochladen.
Triaging von Fehlern
Die erste Aufgabe beim Umgang mit einer Sicherheitslücke besteht darin, den Schweregrad des Fehlers und die betroffene Komponente von Android zu identifizieren. Der Schweregrad bestimmt, wie das Problem priorisiert wird, und die Komponente bestimmt, wer den Fehler behebt, wer benachrichtigt wird und wie der Fix den Benutzern bereitgestellt wird.
Kontexttypen
Diese Tabelle enthält die Definitionen von Hardware- und Software-Sicherheitskontexten. Der Kontext kann durch die Sensibilität der typischerweise verarbeiteten Daten oder den Bereich, in dem er ausgeführt wird, definiert werden. Nicht alle Sicherheitskontexte sind auf alle Systeme anwendbar. Diese Tabelle ist von den am wenigsten zu den am meisten privilegierten geordnet.
| Kontexttyp | Typdefinition |
|---|---|
| Eingeschränkter Kontext | Eine eingeschränkte Ausführungsumgebung, in der nur die minimalsten Berechtigungen erteilt werden. Zum Beispiel vertrauenswürdige Anwendungen, die nicht vertrauenswürdige Daten in einer Sandbox-Umgebung verarbeiten. |
| Unprivilegierter Kontext | Eine typische Ausführungsumgebung, die von nicht privilegiertem Code erwartet wird. Beispielsweise eine Android-Anwendung, die in einer SELinux-Domäne mit dem untrusted_app_all Attribut ausgeführt wird. |
| Privilegierter Kontext | Eine privilegierte Ausführungsumgebung, die möglicherweise Zugriff auf erhöhte Berechtigungen hat, mehrere Benutzer-PII verarbeitet und/oder die Systemintegrität aufrechterhält. Beispielsweise eine Android-Anwendung mit Funktionen, die von der SELinux-Domain untrusted_app verboten wären, oder mit Zugriff auf privileged|signature . |
| OS-Kernel | Funktionalität, die:
|
| Trusted Hardware Base (THB) | Diskrete Hardwarekomponenten, im Allgemeinen auf dem SoC, die Funktionen bereitstellen, die für die Kernanwendungsfälle des Geräts entscheidend sind (z. B. Mobilfunkbasisbänder, DSPs, GPUs und ML-Prozessoren). |
| Bootloader-Kette | Eine Komponente, die das Gerät beim Booten konfiguriert und dann die Steuerung an das Android-Betriebssystem übergibt. |
| Vertrauenswürdige Ausführungsumgebung (TEE) | Eine Komponente, die so konzipiert ist, dass sie selbst vor einem feindlichen Betriebssystemkernel geschützt ist (z. B. TrustZone und Hypervisoren wie pKVM, die virtuelle Maschinen vor dem Betriebssystemkernel schützen). |
| Sichere Enklave / Sicheres Element (SE) | Eine optionale Hardwarekomponente, die so konzipiert ist, dass sie vor allen anderen Komponenten auf dem Gerät und vor physischen Angriffen geschützt ist, wie in Einführung in Secure Elements definiert. Dazu gehört der Titan-M-Chip, der in einigen Android-Geräten vorhanden ist. |
Schwere
Der Schweregrad eines Fehlers spiegelt im Allgemeinen den potenziellen Schaden wider, der auftreten könnte, wenn ein Fehler erfolgreich ausgenutzt würde. Verwenden Sie die folgenden Kriterien, um den Schweregrad zu bestimmen.
| Bewertung | Folge einer erfolgreichen Verwertung |
|---|---|
| Kritisch |
|
| Hoch |
|
| Mäßig |
|
| Niedrig |
|
| Vernachlässigbare Sicherheitsauswirkung (NSI) |
|
Bewertungsmodifikatoren
Während der Schweregrad von Sicherheitslücken oft leicht zu erkennen ist, können sich die Bewertungen je nach den Umständen ändern.
| Grund | Wirkung |
|---|---|
| Ausführung als privilegierter Kontext erforderlich, um den Angriff auszuführen (gilt nicht für TEE, SE und Hypervisoren wie pKVM) | -1 Schweregrad |
| Schwachstellenspezifische Details begrenzen die Auswirkungen des Problems | -1 Schweregrad |
| Umgehung der biometrischen Authentifizierung, die biometrische Informationen direkt vom Gerätebesitzer erfordert | -1 Schweregrad |
| Compiler- oder Plattformkonfigurationen mindern eine Schwachstelle im Quellcode | Mittlerer Schweregrad, wenn die zugrunde liegende Schwachstelle mäßig oder höher ist |
| Erfordert physischen Zugriff auf Geräteinterna und ist weiterhin möglich, wenn das Gerät ausgeschaltet ist oder seit dem Einschalten nicht entsperrt wurde | -1 Schweregrad |
| Erfordert physischen Zugriff auf das Geräteinnere, während das Gerät eingeschaltet ist und zuvor entsperrt wurde | -2 Schweregrad |
| Ein lokaler Angriff, bei dem die Bootloader-Kette entsperrt werden muss | Nicht höher als Niedrig |
| Ein lokaler Angriff, der erfordert, dass der Entwicklermodus oder dauerhafte Entwicklermoduseinstellungen derzeit auf dem Gerät aktiviert sind (und kein Fehler im Entwicklermodus selbst ist). | Nicht höher als Niedrig |
| Wenn keine SELinux-Domäne den Vorgang unter der von Google bereitgestellten SEPolicy ausführen kann | Vernachlässigbare Auswirkungen auf die Sicherheit |
Lokal versus proximal versus entfernt
Ein Remote-Angriffsvektor weist darauf hin, dass der Fehler ohne Installation einer App oder ohne physischen Zugriff auf ein Gerät ausgenutzt werden kann. Dazu gehören Fehler, die durch das Surfen auf einer Webseite, das Lesen einer E-Mail, das Empfangen einer SMS-Nachricht oder das Verbinden mit einem feindlichen Netzwerk ausgelöst werden können. Zum Zwecke unserer Bewertung des Schweregrads betrachten wir auch "nahe" Angriffsvektoren als entfernt. Dazu gehören Fehler, die nur von einem Angreifer ausgenutzt werden können, der sich physisch in der Nähe des Zielgeräts befindet, z. B. ein Fehler, der das Senden fehlerhafter Wi-Fi- oder Bluetooth-Pakete erfordert. Wir betrachten Ultrabreitband- (UWB) und NFC-basierte Angriffe als nahe und daher entfernt.
Bei lokalen Angriffen muss das Opfer eine App ausführen, indem es entweder eine App installiert und ausführt oder der Ausführung einer Instant-App zustimmt . Gekoppelte Begleitgeräte werden als lokal betrachtet. Zum Zweck der Bewertung des Schweregrads betrachtet das Android-Sicherheitsteam auch physische Angriffsvektoren als lokal. Dazu gehören Fehler, die nur von einem Angreifer ausgenutzt werden können, der physischen Zugriff auf das Gerät hat, z. B. ein Fehler in einem Sperrbildschirm oder einer, der das Einstecken eines USB-Kabels erfordert.
Netzwerksicherheit
Android geht davon aus, dass alle Netzwerke feindlich sind und Angriffe einschleusen oder den Datenverkehr ausspionieren könnten. Während die Link-Layer-Sicherheit (z. B. Wi-Fi-Verschlüsselung) die Kommunikation zwischen einem Gerät und dem Access Point sichert, mit dem es verbunden ist, schützt es nicht die verbleibenden Verbindungen in der Kette zwischen dem Gerät und den Servern, mit denen es kommuniziert.
Im Gegensatz dazu schützt HTTPS normalerweise die gesamte Kommunikation von Anfang bis Ende, verschlüsselt die Daten an ihrer Quelle und entschlüsselt und verifiziert sie erst, wenn sie ihr endgültiges Ziel erreicht haben. Aus diesem Grund werden Schwachstellen, die die Netzwerksicherheit auf Verbindungsebene gefährden, als weniger schwerwiegend eingestuft als Schwachstellen in HTTPS/TLS: Die WLAN-Verschlüsselung allein reicht für die meisten Kommunikationsvorgänge im Internet nicht aus.
Biometrische Authentifizierung
Die biometrische Authentifizierung ist ein herausfordernder Bereich, und selbst die besten Systeme können durch eine Beinahe-Übereinstimmung getäuscht werden (siehe Android Developers Blog: Lockscreen and Authentication Improvements in Android 11 ). Diese Schweregrade unterscheiden zwischen zwei Klassen von Angriffen und sollen das tatsächliche Risiko für den Endbenutzer widerspiegeln.
Die erste Klasse von Angriffen ermöglicht die Umgehung der biometrischen Authentifizierung auf verallgemeinerbare Weise, ohne dass hochwertige biometrische Daten des Eigentümers vorliegen. Wenn ein Angreifer beispielsweise ein Stück Kaugummi auf einen Fingerabdrucksensor legen kann und dieser Zugriff auf das Gerät gewährt, basierend auf Rückständen auf dem Sensor, ist dies ein einfacher Angriff, der auf jedem anfälligen Gerät durchgeführt werden könnte. Es erfordert keine Kenntnis des Gerätebesitzers. Da er verallgemeinerbar ist und möglicherweise eine größere Anzahl von Benutzern betrifft, erhält dieser Angriff die volle Bewertung des Schweregrads (z. B. „Hoch“ für eine Umgehung des Sperrbildschirms).
Bei der anderen Angriffsklasse handelt es sich im Allgemeinen um ein Präsentationsangriffsinstrument (Spoof), das auf dem Gerätebesitzer basiert. Manchmal sind diese biometrischen Informationen relativ einfach zu erhalten (wenn beispielsweise das Profilbild einer Person in den sozialen Medien ausreicht, um die biometrische Authentifizierung zu täuschen, würde eine biometrische Umgehung die volle Bewertung des Schweregrads erhalten). Aber wenn ein Angreifer biometrische Daten direkt vom Gerätebesitzer erhalten müsste (z. B. einen Infrarotscan seines Gesichts), ist das eine ausreichend große Barriere, um die Anzahl der von dem Angriff betroffenen Personen zu begrenzen, also gibt es einen Modifikator von -1 .
SYSTEM_ALERT_WINDOW und Tapjacking
Informationen zu unseren Richtlinien in Bezug auf SYSTEM_ALERT_WINDOW und Tapjacking finden Sie im Abschnitt „ Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen “ auf der Seite Bugs with no security impact der BugHunter University.
Mehrbenutzersicherheit in Android Automotive OS
Android Automotive OS verwendet ein Mehrbenutzer-Sicherheitsmodell, das sich von den anderen Formfaktoren unterscheidet. Jeder Android-Benutzer soll von einer anderen natürlichen Person verwendet werden. Beispielsweise kann ein temporärer Gastnutzer einem Freund zugewiesen werden, der sich das Fahrzeug vom Autobesitzer ausleiht. Um Anwendungsfällen wie diesem gerecht zu werden, haben Benutzer standardmäßig Zugriff auf notwendige Komponenten, die zur Nutzung des Fahrzeugs erforderlich sind, wie z. B. Wi-Fi- und Mobilfunknetzeinstellungen.
Betroffene Komponente
Das für die Behebung des Fehlers zuständige Entwicklungsteam hängt davon ab, in welcher Komponente sich der Fehler befindet. Dies kann eine Kernkomponente der Android-Plattform, ein von einem Originalgerätehersteller (OEM) bereitgestellter Kernel-Treiber oder eine der vorinstallierten Apps auf Pixel-Geräten sein .
Fehler im AOSP-Code werden vom Android-Engineering-Team behoben. Bugs mit niedrigem Schweregrad, Bugs in bestimmten Komponenten oder Bugs, die bereits öffentlich bekannt sind, können direkt im öffentlich verfügbaren AOSP-Master-Zweig behoben werden; Andernfalls werden sie zuerst in unseren internen Repositories behoben.
Die Komponente ist auch ein Faktor dafür, wie Benutzer Updates erhalten. Ein Fehler im Framework oder Kernel erfordert ein Over-the-Air (OTA)-Firmware-Update, das jeder OEM pushen muss. Ein Fehler in einer in Google Play veröffentlichten App oder Bibliothek (z. B. Gmail, Google Play Services oder WebView) kann als Update von Google Play an Android-Nutzer gesendet werden.
Partner benachrichtigen
Wenn eine Sicherheitslücke in AOSP in einem Android Security Bulletin behoben wird, benachrichtigen wir Android-Partner über Details zum Problem und stellen Patches bereit. Die Liste der Backport-unterstützten Versionen ändert sich mit jeder neuen Android-Version. Wenden Sie sich an Ihren Gerätehersteller, um eine Liste der unterstützten Geräte zu erhalten.
Freigeben von Code an AOSP
Wenn sich der Sicherheitsfehler in einer AOSP-Komponente befindet, wird der Fix an AOSP weitergegeben, nachdem das OTA für Benutzer freigegeben wurde. Korrekturen für Probleme mit niedrigem Schweregrad können direkt an den AOSP-Master-Zweig übermittelt werden, bevor eine Korrektur für Geräte über ein OTA verfügbar ist.
Empfangen von Android-Updates
Updates für das Android-System werden im Allgemeinen über OTA-Updatepakete an Geräte geliefert. Diese Updates können von dem OEM stammen, der das Gerät hergestellt hat, oder von dem Spediteur, der den Service für das Gerät bereitstellt. Google Pixel-Geräteaktualisierungen kommen vom Google Pixel-Team, nachdem sie ein Testverfahren für die technische Abnahme (TA) des Trägers durchlaufen haben. Google veröffentlicht auch Pixel-Factory-Bilder , die seitlich auf Geräte geladen werden können.
Aktualisieren von Google-Diensten
Neben der Bereitstellung von Patches für Sicherheitsfehler überprüft das Android-Sicherheitsteam Sicherheitsfehler, um festzustellen, ob es andere Möglichkeiten gibt, Benutzer zu schützen. Beispielsweise scannt Google Play alle Apps und entfernt alle Apps, die versuchen, einen Sicherheitsfehler auszunutzen. Für Apps, die von außerhalb von Google Play installiert wurden, können Geräte mit Google Play-Diensten auch die Funktion „Apps überprüfen“ verwenden, um Benutzer vor potenziell schädlichen Apps zu warnen.
Andere Ressourcen
Informationen für Entwickler von Android-Apps: https://developer.android.com
Sicherheitsinformationen sind überall auf den Android Open Source- und Entwicklerseiten vorhanden. Gute Anlaufstellen:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Berichte
Manchmal veröffentlicht das Android-Sicherheitsteam Berichte oder Whitepaper. Weitere Einzelheiten finden Sie unter Sicherheitsberichte .