Sicherheitsupdates und Ressourcen

Das Android-Sicherheitsteam ist für die Verwaltung von Sicherheitslücken verantwortlich, die in der Android-Plattform und vielen der mit Android-Geräten gebündelten Kern-Android-Apps entdeckt wurden.

Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Recherchen und reagiert auch auf von Dritten gemeldete Fehler. Zu den Quellen externer Fehler gehören Probleme, die über das Schwachstellenformular gemeldet werden, veröffentlichte und vorveröffentlichte akademische Forschungsergebnisse, vorgelagerte Open-Source-Projektbetreuer, Benachrichtigungen von unseren Geräteherstellerpartnern und öffentlich bekannt gegebene Probleme, die in Blogs oder sozialen Medien veröffentlicht werden.

Sicherheitsprobleme melden

Jeder Entwickler, Android-Benutzer oder Sicherheitsforscher kann das Android-Sicherheitsteam über das Schwachstellenformular über potenzielle Sicherheitsprobleme informieren.

Als Sicherheitsprobleme gekennzeichnete Fehler sind von außen nicht sichtbar, können aber nach der Bewertung oder Lösung des Problems sichtbar gemacht werden. Wenn Sie planen, einen Patch oder einen Compatibility Test Suite (CTS)-Test einzureichen, um ein Sicherheitsproblem zu beheben, fügen Sie ihn bitte dem Fehlerbericht bei und warten Sie auf eine Antwort, bevor Sie den Code auf AOSP hochladen.

Triagieren von Fehlern

Die erste Aufgabe bei der Behandlung einer Sicherheitslücke besteht darin, den Schweregrad des Fehlers und die betroffene Android-Komponente zu ermitteln. 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 Softwaresicherheitskontexten. Der Kontext kann durch die Sensibilität der Daten definiert werden, die typischerweise verarbeitet werden, oder durch den Bereich, in dem er ausgeführt wird. Nicht alle Sicherheitskontexte sind auf alle Systeme anwendbar. Diese Tabelle ist von den geringsten bis zu den höchsten Privilegien geordnet.

Kontexttyp Typdefinition
Eingeschränkter Kontext Eine eingeschränkte Ausführungsumgebung, in der nur die minimalsten Berechtigungen bereitgestellt werden.

Beispielsweise verarbeiten vertrauenswürdige Anwendungen nicht vertrauenswürdige Daten in einer Sandbox-Umgebung.
Unprivilegierter Kontext Eine typische Ausführungsumgebung, die von unprivilegiertem Code erwartet wird.

Zum Beispiel eine Android-Anwendung, die in einer SELinux-Domäne mit dem Attribut untrusted_app_all 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.

Zum Beispiel eine Android-Anwendung mit Funktionen, die von der SELinux-Domäne untrusted_app verboten wären, oder mit Zugriff auf privileged|signature Berechtigungen.
Betriebssystemkernel Funktionalität, die:
  • ist Teil des Kernels
  • läuft im gleichen CPU-Kontext wie der Kernel (z. B. Gerätetreiber)
  • hat direkten Zugriff auf den Kernel-Speicher (z. B. Hardwarekomponenten auf dem Gerät)
  • verfügt über die Möglichkeit, Skripte in eine Kernel-Komponente (z. B. eBPF) zu laden.
  • ist einer von wenigen Benutzerdiensten, die als Kernel-Äquivalent gelten (z. B. apexd , bpfloader , init , ueventd und vold ).
Vertrauenswürdige Hardwarebasis (THB) Diskrete Hardwarekomponenten, im Allgemeinen auf dem SoC, die für die Kernanwendungsfälle des Geräts entscheidende Funktionen bereitstellen (z. B. Mobilfunk-Basisbä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 selbst vor einem feindlichen Betriebssystemkernel geschützt werden soll (z. B. TrustZone und Hypervisoren wie pKVM, die virtuelle Maschinen vor dem Betriebssystemkernel schützen).
Sichere Enklave / sicheres Element (SE) Eine optionale Hardwarekomponente, die vor allen anderen Komponenten auf dem Gerät und vor physischen Angriffen geschützt werden soll, wie in Einführung in sichere Elemente definiert.

Dazu gehört auch 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 entstehen könnte, wenn ein Fehler erfolgreich ausgenutzt würde. Verwenden Sie die folgenden Kriterien, um den Schweregrad zu bestimmen.

Bewertung Konsequenz erfolgreicher Ausbeutung
Kritisch
  • Beliebige Codeausführung im TEE oder SE
  • Umgehen von Softwaremechanismen, die Fehlfunktionen sicherheitsrelevanter Software- oder Hardwarekomponenten verhindern sollen (z. B. thermische Schutzvorrichtungen)
  • Fernzugriff auf vertrauliche Anmeldeinformationen, die für die Remote-Dienstauthentifizierung verwendet werden (z. B. Kontokennwörter oder Inhabertokens)
  • Remoteausführung beliebigen Codes im Mobilfunk-Basisbandkontext ohne Benutzerinteraktion (z. B. Ausnutzung eines Fehlers im Mobilfunkdienst)
  • Remoteausführung beliebigen Codes in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem Betriebssystemkernel
  • Remote-Umgehung von Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Remote-Umgehung von Benutzerinteraktionsanforderungen für wichtige Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Remote-Persistent-Denial-of-Service (permanent, erfordert ein erneutes Flashen des gesamten Betriebssystems oder ein Zurücksetzen auf die Werkseinstellungen)
  • Remote Secure Boot Bypass
  • Unbefugter Zugriff auf durch die SE gesicherte Daten, einschließlich Zugriff, der durch schwache Schlüssel in der SE ermöglicht wird.
Hoch
  • Eine vollständige Umgehung einer zentralen Sicherheitsfunktion (z. B. SELinux, FBE oder seccomp )
  • Eine allgemeine Umgehung für eine Tiefenverteidigung oder die Ausnutzung von Schadensbegrenzungstechnologien in der Bootloader-Kette, TEE oder SE
  • Eine allgemeine Umgehung des Betriebssystemschutzes, die Speicher- oder Dateiinhalte über App-, Benutzer- oder Profilgrenzen hinweg offenlegt
  • Angriffe gegen eine SE, die zu einem Downgrade auf eine weniger sichere Implementierung führen
  • Umgehung des Geräteschutzes/Werksreset-Schutzes/Netzbetreiberbeschränkungen
  • Umgehung von Benutzerinteraktionsanforderungen, die durch das TEE gesichert sind
  • Kryptografische Schwachstelle, die Angriffe auf End-to-End-Protokolle ermöglicht, einschließlich Angriffe auf Transport Layer Security (TLS) und Bluetooth (BT).
  • Lokaler Zugriff auf vertrauliche Anmeldeinformationen, die für die Remote-Service-Authentifizierung verwendet werden (z. B. Kontokennwörter oder Inhabertokens)
  • Lokale Ausführung willkürlichen Codes in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem Betriebssystemkernel
  • Lokale sichere Boot-Umgehung
  • Umgehung des Sperrbildschirms
  • Lokale Umgehung der Benutzerinteraktionsanforderungen für wichtige Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Lokale Umgehung von Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Lokaler dauerhafter Denial-of-Service (permanent, erfordert ein erneutes Flashen des gesamten Betriebssystems oder ein Zurücksetzen auf die Werkseinstellungen)
  • Fernzugriff auf geschützte Daten (d. h. Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Remote-Ausführung von beliebigem Code in einem unprivilegierten Kontext
  • Fernverhinderung des Zugriffs auf Mobilfunk- oder Wi-Fi-Dienste ohne Benutzerinteraktion (z. B. Absturz des Mobilfunkdienstes mit einem fehlerhaften Paket)
  • Remote-Umgehung von Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, die entweder eine Benutzerinitiierung oder eine Benutzerberechtigung erfordern sollten)
  • Gezielte Verhinderung des Zugangs zu Rettungsdiensten
  • Übertragung vertraulicher Informationen über ein unsicheres Netzwerkprotokoll (z. B. HTTP und unverschlüsseltes Bluetooth), wenn der Anforderer eine sichere Übertragung erwartet. Beachten Sie, dass dies nicht für die WLAN-Verschlüsselung (z. B. WEP) gilt.
  • Unbefugter Zugriff auf durch das TEE gesicherte Daten, einschließlich Zugriff, der durch schwache Schlüssel im TEE ermöglicht wird
Mäßig
  • Eine allgemeine Umgehung für eine Tiefenverteidigung oder die Ausnutzung von Schadensbegrenzungstechnologie in einem privilegierten Kontext, THB oder dem Betriebssystemkernel
  • Eine allgemeine Umgehung für Betriebssystemschutzmaßnahmen, die den Prozessstatus oder Metadaten über App-, Benutzer- oder Profilgrenzen hinweg offenlegen
  • Umgehen der WLAN-Verschlüsselung oder -Authentifizierung
  • Kryptografische Schwachstelle in Standard-Krypto-Grundelementen, die das Durchsickern von Klartext ermöglicht (nicht in TLS verwendete Grundelemente)
  • Lokaler Zugriff auf geschützte Daten (d. h. Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Lokale Ausführung willkürlichen Codes in einem unprivilegierten Kontext
  • Lokale Umgehung von Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, die normalerweise entweder eine Benutzerinitiierung oder eine Benutzerberechtigung erfordern würden)
  • Fernzugriff auf ungeschützte Daten (d. h. Daten, auf die normalerweise jede lokal installierte App zugreifen kann)
  • Remote-Ausführung von beliebigem Code in einem eingeschränkten Kontext
  • Temporäre Remote-Geräteverweigerung (Remote-Hang oder Neustart)
Niedrig
  • Eine allgemeine Umgehung für eine tiefgreifende Verteidigung auf Benutzerebene oder die Nutzung von Schadensbegrenzungstechnologie in einem nicht privilegierten Kontext
  • Umgehen einer normalen Schutzstufenberechtigung
  • Kryptografische Schwachstelle bei nicht standardmäßiger Verwendung
  • Allgemeine Umgehung von Personalisierungsfunktionen auf dem Gerät wie Voice Match oder Face Match
  • Falsche Dokumentation, die zu einer Sicherheitslücke führen kann
  • Lokale Ausführung willkürlichen Codes in einem eingeschränkten Kontext
  • Systemdefinierter Text, der eine irreführende Beschreibung enthält, die eine falsche Sicherheitserwartung weckt
Vernachlässigbare Sicherheitsauswirkungen (NSI)
  • Eine Schwachstelle, deren Auswirkungen durch einen oder mehrere Bewertungsmodifikatoren oder versionenspezifische Architekturänderungen abgeschwächt wurden, sodass der tatsächliche Schweregrad unter „Niedrig“ liegt, obwohl das zugrunde liegende Codeproblem bestehen bleiben kann
  • Jede Schwachstelle, die ein fehlerhaftes Dateisystem erfordert, wenn dieses Dateisystem vor der Verwendung immer übernommen/verschlüsselt wird.

Bewertungsmodifikatoren

Während der Schweregrad von Sicherheitslücken oft leicht zu erkennen ist, können sich die Bewertungen je nach Umständen ändern.

Grund Wirkung
Erfordert die Ausführung als privilegierter Kontext, 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 verringern eine Schwachstelle im Quellcode Mittlerer Schweregrad, wenn die zugrunde liegende Schwachstelle mittelmäßig oder höher ist
Erfordert physischen Zugriff auf das Innere des Geräts 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 Innere des Geräts, während das Gerät eingeschaltet ist und zuvor entsperrt wurde -2 Schweregrad
Ein lokaler Angriff, der das Entsperren der Bootloader-Kette erfordert Nicht höher als Niedrig
Ein lokaler Angriff, der erfordert, dass der Entwicklermodus oder dauerhafte Einstellungen des Entwicklermodus derzeit auf dem Gerät aktiviert sind (und kein Fehler im Entwicklermodus selbst ist). Nicht höher als Niedrig
Wenn keine SELinux-Domäne vorhanden ist, kann der Vorgang gemäß der von Google bereitgestellten SEPolicy durchgeführt werden Vernachlässigbare Auswirkungen auf die Sicherheit

Lokal versus Proximal versus Remote

Ein Remote-Angriffsvektor weist darauf hin, dass der Fehler ohne die 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, den Empfang einer SMS-Nachricht oder die Verbindung zu einem feindlichen Netzwerk ausgelöst werden können. Für unsere Schweregradeinstufungen betrachten wir auch „proximale“ Angriffsvektoren als entfernte Angriffsvektoren. Dazu gehören Fehler, die nur von einem Angreifer ausgenutzt werden können, der sich physisch in der Nähe des Zielgeräts befindet, beispielsweise ein Fehler, der das Senden fehlerhafter WLAN- oder Bluetooth-Pakete erfordert. Wir betrachten Ultrabreitband- (UWB) und NFC-basierte Angriffe als naheliegend und daher weit 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. Für die Bewertung des Schweregrads berücksichtigt 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, beispielsweise ein Fehler in einem Sperrbildschirm oder ein Fehler, der das Anschließen eines USB-Kabels erfordert.

Netzwerksicherheit

Android geht davon aus, dass alle Netzwerke feindselig 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, mit dem es verbunden ist, sichert, trägt sie nicht dazu bei, die verbleibenden Glieder in der Kette zwischen dem Gerät und den Servern, mit denen es kommuniziert, zu sichern.

Im Gegensatz dazu schützt HTTPS in der Regel die gesamte Kommunikation durchgängig, indem es die Daten an ihrer Quelle verschlüsselt und sie erst dann entschlüsselt und überprüft, wenn sie ihr endgültiges Ziel erreicht haben. Aus diesem Grund werden Schwachstellen, die die Netzwerksicherheit auf der Verbindungsschicht gefährden, als weniger schwerwiegend eingestuft als Schwachstellen in HTTPS/TLS: Die Wi-Fi-Verschlüsselung allein reicht für die meisten Kommunikationen im Internet nicht aus.

Biometrische Authentifizierung

Die biometrische Authentifizierung ist eine Herausforderung, und selbst die besten Systeme können durch eine Beinahe-Übereinstimmung getäuscht werden (siehe Android-Entwicklerblog: Sperrbildschirm- und Authentifizierungsverbesserungen in Android 11 ). Diese Schweregradbewertungen 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 vom Eigentümer erforderlich sind. Wenn ein Angreifer beispielsweise ein Stück Kaugummi auf einen Fingerabdrucksensor legen kann und dieser anhand der auf dem Sensor verbliebenen Rückstände Zugriff auf das Gerät gewährt, handelt es sich um einen einfachen Angriff, der auf jedes anfällige Gerät ausgeführt werden könnte. Es ist keine Kenntnis des Gerätebesitzers erforderlich. Da er verallgemeinerbar ist und möglicherweise eine größere Anzahl von Benutzern betrifft, erhält dieser Angriff die volle Schweregradbewertung (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 sozialen Medien ausreicht, um die biometrische Authentifizierung zu täuschen, würde eine biometrische Umgehung die volle Schweregradbewertung erhalten). Wenn ein Angreifer jedoch biometrische Daten direkt vom Gerätebesitzer erhalten müsste (z. B. einen Infrarot-Scan seines Gesichts), stellt dies eine ausreichend große Hürde dar, um die Anzahl der von dem Angriff betroffenen Personen zu begrenzen. Daher gibt es einen Modifikator von -1 .

SYSTEM_ALERT_WINDOW und Tapjacking

Informationen zu unseren Richtlinien bezüglich SYSTEM_ALERT_WINDOW und Tapjacking finden Sie im Abschnitt „ Tapjacking/Overlay SYSTEM_ALERT_WINDOW-Schwachstelle auf einem nicht sicherheitskritischen Bildschirm “ auf der Seite „Bugs ohne Auswirkungen auf die Sicherheit“ der BugHunter University.

Mehrbenutzersicherheit im 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 das Fahrzeug vom Autobesitzer leiht. Um solche Anwendungsfälle zu bewältigen, haben Benutzer standardmäßig Zugriff auf die für die Nutzung des Fahrzeugs erforderlichen Komponenten, wie z. B. WLAN 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. Dabei kann es sich um eine Kernkomponente der Android-Plattform, einen von einem Originalgerätehersteller (OEM) bereitgestellten Kerneltreiber oder eine der vorinstallierten Apps auf Pixel-Geräten handeln .

Fehler im AOSP-Code werden vom Android-Engineering-Team behoben. Fehler mit geringem Schweregrad, Fehler in bestimmten Komponenten oder Fehler, die bereits öffentlich bekannt sind, können direkt im öffentlich verfügbaren AOSP-Hauptzweig behoben werden; andernfalls werden sie zuerst in unseren internen Repositorys 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-Benutzer gesendet werden.

Partner benachrichtigen

Wenn eine Sicherheitslücke in AOSP in einem Android-Sicherheitsbulletin behoben wird, benachrichtigen wir Android-Partner über Problemdetails und stellen Patches bereit. Die Liste der Backport-unterstützten Versionen ändert sich mit jeder neuen Android-Version. Wenden Sie sich an den Hersteller Ihres Geräts, um eine Liste der unterstützten Geräte zu erhalten.

Code für AOSP freigeben

Wenn sich der Sicherheitsfehler in einer AOSP-Komponente befindet, wird der Fix an AOSP weitergegeben, nachdem der OTA für Benutzer freigegeben wurde. Korrekturen für Probleme mit geringem Schweregrad können direkt an die AOSP-Hauptniederlassung übermittelt werden, bevor eine Korrektur für Geräte über einen OTA verfügbar ist.

Empfangen von Android-Updates

Updates des Android-Systems werden im Allgemeinen über OTA-Updatepakete an Geräte geliefert. Diese Updates können vom OEM stammen, der das Gerät hergestellt hat, oder vom Netzbetreiber, der den Service für das Gerät bereitstellt. Updates für Google Pixel-Geräte stammen vom Google Pixel-Team, nachdem sie ein technisches Abnahmetestverfahren (Carrier Technical Acceptance, TA) 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 Sicherheitslücken überprüft das Android-Sicherheitsteam Sicherheitslücken, um festzustellen, ob es andere Möglichkeiten gibt, Benutzer zu schützen. Beispielsweise scannt Google Play alle Apps und entfernt alle Apps, die versuchen, eine Sicherheitslücke auszunutzen. Bei 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 Android-App-Entwickler: https://developer.android.com

Sicherheitsinformationen finden Sie auf den Android-Open-Source- und Entwickler-Websites. Gute Startpunkte:

Berichte

Manchmal veröffentlicht das Android-Sicherheitsteam Berichte oder Whitepapers. Weitere Einzelheiten finden Sie unter Sicherheitsberichte .