Sicherheitsupdates und Ressourcen

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:
  • ist Teil des Kernels
  • läuft im selben CPU-Kontext wie der Kernel (z. B. Gerätetreiber)
  • hat direkten Zugriff auf Kernelspeicher (z. B. Hardwarekomponenten auf dem Gerät)
  • hat die Fähigkeit, Skripte in eine Kernel-Komponente (z. B. eBPF) zu laden
  • ist einer von wenigen Benutzerdiensten, die als Kernel-Äquivalent betrachtet werden (z. B. apexd , bpfloader , init , ueventd und vold ).
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
  • Ausführung von beliebigem Code im TEE oder SE
  • Umgehung von Softwaremechanismen, die eine Fehlfunktion von sicherheitsrelevanten Software- oder Hardwarekomponenten verhindern sollen (z. B. Überhitzungsschutz)
  • Remote-Zugriff auf vertrauliche Anmeldeinformationen, die für die Remote-Service-Authentifizierung verwendet werden (z. B. Kontokennwörter oder Inhaber-Token)
  • Remote-Ausführung von beliebigem Code innerhalb des zellularen Basisbandkontexts ohne Benutzerinteraktion (z. B. Ausnutzen eines Fehlers im Mobilfunkdienst)
  • Remote-Ausführung von beliebigem Code in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem OS-Kernel
  • Remote-Umgehung von Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Remote-Umgehung von Benutzerinteraktionsanforderungen für grundlegende Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Persistenter Remote-Denial-of-Service (permanent, erfordert ein erneutes Flashen des gesamten Betriebssystems oder ein Zurücksetzen auf die Werkseinstellungen)
  • Umgehung des sicheren Remotestarts
  • Unbefugter Zugriff auf Daten, die durch die SE gesichert sind, 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 Defense-in-Depth- oder Exploit-Minderungstechnologie in der Bootloader-Kette, TEE oder SE
  • Eine allgemeine Umgehung für Betriebssystemschutzmaßnahmen, die Speicher- oder Dateiinhalte über Anwendungs-, Benutzer- oder Profilgrenzen hinweg offenlegen
  • Angriffe auf eine SE, die zu einer Herabstufung auf eine weniger sichere Implementierung führen
  • Umgehung des Geräteschutzes/Factory-Reset-Schutzes/Trägereinschrä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. Kontopasswörter oder Bearer-Token)
  • Lokale Ausführung von beliebigem Code in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem OS-Kernel
  • Umgehung des lokalen sicheren Starts
  • Sperrbildschirm umgehen
  • Lokale Umgehung der Benutzerinteraktionsanforderungen für grundlegende Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Lokale Umgehung der Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertiges Verhalten
  • Lokaler persistenter Denial-of-Service (permanent, erfordert erneutes Flashen des gesamten Betriebssystems oder 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 nicht privilegierten Kontext
  • Remote-Verhinderung 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 Benutzererlaubnis 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 Wi-Fi-Verschlüsselung (z. B. WEP) gilt.
  • Unbefugter Zugriff auf Daten, die durch das TEE gesichert sind, einschließlich des Zugriffs, der durch schwache Schlüssel im TEE ermöglicht wird
Mäßig
  • Eine allgemeine Umgehung für eine Tiefenverteidigungs- oder Exploit-Minderungstechnologie in einem privilegierten Kontext, THB oder dem OS-Kernel
  • Eine allgemeine Umgehung für Betriebssystemschutzmaßnahmen, die den Prozessstatus oder Metadaten über App-, Benutzer- oder Profilgrenzen hinweg offenlegen
  • Umgehen der Wi-Fi-Verschlüsselung oder -Authentifizierung
  • Kryptografische Schwachstelle in Standard-Krypto-Primitiven, die das Lecken von Klartext ermöglicht (keine in TLS verwendeten Primitiven)
  • Lokaler Zugriff auf geschützte Daten (d. h. Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Lokale Ausführung von beliebigem Code in einem nicht privilegierten Kontext
  • Lokale Umgehung von Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, die normalerweise entweder eine Benutzerinitiierung oder eine Benutzererlaubnis 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ärer Denial-of-Service des Remote-Geräts (Remote-Aufhängung oder -Neustart)
Niedrig
  • Eine allgemeine Umgehung für eine Tiefenverteidigung auf Benutzerebene oder eine Exploit-Minderungstechnologie in einem nicht privilegierten Kontext
  • Umgehung 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 von beliebigem Code in einem eingeschränkten Kontext
  • Vom System definierter Text, der eine irreführende Beschreibung enthält, die eine falsche Sicherheitserwartung schafft
Vernachlässigbare Sicherheitsauswirkung (NSI)
  • Eine Schwachstelle, deren Auswirkung durch einen oder mehrere Bewertungsmodifikatoren oder versionsspezifische Architekturänderungen gemildert wurde, sodass der effektive Schweregrad unter Niedrig liegt, obwohl das zugrunde liegende Codeproblem bestehen bleiben kann
  • Jede Schwachstelle, die ein fehlerhaftes Dateisystem erfordert, wenn dieses Dateisystem immer vor der Verwendung übernommen/verschlüsselt wird.

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:

Berichte

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