Sicherheitsupdates und -ressourcen

Das Android-Sicherheitsteam ist für die Verwaltung von Sicherheitslücken verantwortlich, die in der Android-Plattform und vielen der wichtigsten Android-Apps gefunden wurden, die im Lieferumfang von Android-Geräten enthalten sind.

Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Recherchen und reagiert auch auf von Dritten gemeldete Fehler. Zu den externen Fehlern gehören Probleme, die über das Formular für Sicherheitslücken gemeldet wurden, veröffentlichte und vorveröffentlichte akademische Forschung, Upstream-Open-Source-Projektleiter, Benachrichtigungen von unseren Geräteherstellerpartnern und öffentlich bekannt gegebene Probleme, die in Blogs oder sozialen Medien gepostet wurden.

Sicherheitsprobleme melden

Entwickler, Android-Nutzer und Sicherheitsforscher können das Android-Sicherheitsteam über das Formular für Sicherheitslücken über potenzielle Sicherheitsprobleme informieren.

Als Sicherheitsprobleme gekennzeichnete Bugs sind extern nicht sichtbar, können aber nach der Bewertung oder Behebung des Problems sichtbar gemacht werden. Wenn Sie einen Patch oder einen CTS-Test (Compatibility Test Suite) zur Behebung eines Sicherheitsproblems einreichen möchten, hängen Sie ihn bitte an den Fehlerbericht an und warten Sie auf eine Antwort, bevor Sie den Code in AOSP hochladen.

Fehler priorisieren

Die erste Aufgabe beim Umgang mit einer Sicherheitslücke besteht darin, den Schweregrad des Fehlers und die betroffene Android-Komponente zu ermitteln. Anhand der Schwere wird die Priorität des Problems festgelegt. Die Komponente bestimmt, wer den Fehler behebt, wer benachrichtigt wird und wie die Fehlerbehebung für Nutzer bereitgestellt wird.

Kontexttypen

In dieser Tabelle finden Sie die Definitionen für Hardware- und Softwaresicherheitskontexte. Der Kontext kann durch die Sensibilität der Daten, die in der Regel verarbeitet werden, oder durch den Bereich, in dem sie ausgeführt wird, definiert werden. Nicht alle Sicherheitskontexte gelten für alle Systeme. Diese Tabelle ist von der niedrigsten bis zur höchsten Berechtigung sortiert.

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

Beispielsweise vertrauenswürdige Apps, die nicht vertrauenswürdige Daten in einer Sandbox-Umgebung verarbeiten.
Kontext ohne Berechtigungen Eine typische Ausführungsumgebung, die von nicht privilegiertem Code erwartet wird.

Beispiel: Eine Android-App, die in einer SELinux-Domain mit dem Attribut untrusted_app_all ausgeführt wird.
Kontext mit erhöhten Berechtigungen Eine privilegierte Ausführungsumgebung, die möglicherweise Zugriff auf erweiterte Berechtigungen hat, personenbezogene Daten mehrerer Nutzer verarbeitet und/oder die Systemintegrität aufrechterhält.

Beispiel: Eine Android-App mit Funktionen, die von der SELinux-Domain untrusted_app verboten sind, oder mit Zugriff auf privileged|signature-Berechtigungen.
Betriebssystemkernel Funktionen, die:
  • ist Teil des Kernels
  • im selben CPU-Kontext wie der Kernel ausgeführt wird (z. B. Gerätetreiber)
  • hat direkten Zugriff auf den Kernel-Speicher (z. B. Hardwarekomponenten auf dem Gerät)
  • Scripts in eine Kernelkomponente (z. B. eBPF) laden kann
  • ist einer von wenigen Nutzerdiensten, die als Kernel-Äquivalent gelten (z. B. apexd, bpfloader, init, ueventd und vold).
Trusted Hardware Base (THB) Discrete Hardwarekomponenten, in der Regel auf dem SoC, die für die Hauptanwendungsfälle des Geräts wichtige Funktionen bereitstellen (z. B. Mobilfunk-Basisband, DSPs, GPUs und ML-Prozessoren).
Bootloader-Kette Eine Komponente, die das Gerät beim Starten konfiguriert und dann die Kontrolle an das Android-Betriebssystem weitergibt.
Vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) Eine Komponente, die vor einem feindseligen Betriebssystemkern geschützt ist (z. B. TrustZone und Hypervisoren wie pKVM, die virtuelle Maschinen vor dem Betriebssystemkern schützen).
Secure Enclave / Secure 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 der Einführung in Secure Elements definiert.

Dazu gehört auch der Titan M-Chip, der in einigen Android-Geräten vorhanden ist.

Schweregrad

Der Schweregrad eines Bugs spiegelt in der Regel den potenziellen Schaden wider, der entstehen könnte, wenn ein Bug erfolgreich ausgenutzt wird. Verwenden Sie die folgenden Kriterien, um den Schweregrad zu bestimmen.

Bewertung Folge einer erfolgreichen Ausnutzung
Kritisch
  • Beliebige Codeausführung im TEE oder SE
  • Umgehen von Softwaremechanismen, die verhindern sollen, dass sicherheitsrelevante Software- oder Hardwarekomponenten ausfallen (z. B. thermische Schutzmechanismen)
  • Remotezugriff auf vertrauliche Anmeldedaten, die für die Authentifizierung von Remotediensten verwendet werden (z. B. Kontopasswörter oder Inhabertokens)
  • Ausführen beliebigen Codes per Fernzugriff im Kontext des Mobilfunk-Basebands ohne Nutzerinteraktion (z. B. Ausnutzen eines Bugs im Mobilfunkdienst)
  • Ausführen beliebigen Codes aus der Ferne in einem privilegierten Kontext, der Bootloader-Kette, dem THB oder dem Betriebssystemkernel
  • Remote-Umgehung der Anforderungen an die Nutzerinteraktion bei der Paketinstallation oder entsprechendes Verhalten
  • Remote-Umgehung der Anforderungen an die Nutzerinteraktion für wichtige Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Dauerhafter Remote-Denial-of-Service-Angriff (dauerhaft, erfordert das Neuflashen des gesamten Betriebssystems oder ein Zurücksetzen auf die Werkseinstellungen)
  • Remote Secure Boot-Umgehung
  • Unbefugter Zugriff auf Daten, die durch die SE geschützt sind, einschließlich Zugriff, der durch schwache Schlüssel in der SE ermöglicht wird.
Hoch
  • Eine vollständige Umgehung einer wichtigen Sicherheitsfunktion (z. B. SELinux, FBE oder seccomp)
  • Eine allgemeine Umgehung einer Defense-in-Depth- oder Exploit-Mitigationstechnologie in der Bootloader-Kette, dem TEE oder der SE
  • Eine allgemeine Umgehung von Betriebssystemschutzmaßnahmen, die Speicher- oder Dateiinhalte über App-, Nutzer- oder Profilgrenzen hinweg offenlegen
  • Angriffe auf eine SE, die zu einem Downgrade auf eine weniger sichere Implementierung führen
  • Umschalten von der aus der Ferne erreichbaren manipulierten Bare-Metal-Firmware (z. B. Baseband, Kommunikationsprozessor (CP)) zum App-Prozessor-Kernel oder Umgehen von Mechanismen, die die Bare-Metal-Firmware vom App-Prozessor-Kernel isolieren
  • Umgehung des Geräteschutzes, des Schutzes vor Zurücksetzen auf die Werkseinstellungen oder der Einschränkungen des Mobilfunkanbieters
  • Umgehung der Anforderungen an die Nutzerinteraktion, die durch die TEE gesichert sind
  • Kryptograpische Sicherheitslücke, die Angriffe auf End-to-End-Protokolle ermöglicht, einschließlich Angriffe auf TLS (Transport Layer Security) und Bluetooth (BT).
  • Lokaler Zugriff auf vertrauliche Anmeldedaten, die für die Authentifizierung von Remote-Diensten verwendet werden (z. B. Kontopasswörter oder Inhabertokens)
  • Lokale Ausführung beliebigen Codes in einem privilegierten Kontext, der Bootloader-Kette, dem THB oder dem Betriebssystemkernel
  • Bypass für lokalen Secure Boot
  • Sperrbildschirm umgehen
  • Lokale Umgehung der Anforderungen an die Nutzerinteraktion für wichtige Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Lokale Umgehung der Anforderungen an die Nutzerinteraktion bei der Paketinstallation oder entsprechendes Verhalten
  • Lokaler dauerhafter Denial-of-Service-Angriff (dauerhaft, erfordert das Neuflashen des gesamten Betriebssystems oder das Zurücksetzen auf die Werkseinstellungen)
  • Remotezugriff auf geschützte Daten (d. h. Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Ausführen beliebigen Codes per Fernzugriff in einem nicht privilegierten Kontext
  • Remote-Verhinderung des Zugriffs auf Mobilfunk- oder WLAN-Dienste ohne Nutzerinteraktion (z. B. Absturz des Mobilfunkdienstes durch ein fehlerhaftes Paket)
  • Remote-Umgehung der Anforderungen an die Nutzerinteraktion (Zugriff auf Funktionen oder Daten, für die entweder eine Nutzerinitiierung oder eine Nutzerberechtigung erforderlich sein sollte)
  • Zielgerichtete Verhinderung des Zugriffs auf den Rettungsdienst
  • Übertragung sensibler Informationen über ein unsicheres Netzwerkprotokoll (z. B. HTTP und unverschlüsseltes Bluetooth), wenn der Anfragende eine sichere Übertragung erwartet. Hinweis: Dies gilt nicht für die WLAN-Verschlüsselung (z. B. WEP).
  • Unbefugter Zugriff auf Daten, die durch die TEE geschützt sind, einschließlich Zugriff, der durch schwache Schlüssel in der TEE aktiviert wird
Mäßig
  • Eine allgemeine Umgehung einer mehrschichtigen Verteidigung oder einer Technologie zur Ausnutzungsminderung in einem privilegierten Kontext, THB oder dem Betriebssystemkernel
  • Eine allgemeine Umgehung von Betriebssystemschutzmaßnahmen, die den Prozessstatus oder Metadaten über App-, Nutzer- oder Profilgrenzen hinweg offenlegen
  • Umgehung der WLAN-Verschlüsselung oder -Authentifizierung
  • Kryptograpische Sicherheitslücke in Standardkrypto-Primitiven, die das Auslaufen 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 beliebigen Codes in einem nicht privilegierten Kontext
  • Lokale Umgehung der Anforderungen an die Nutzerinteraktion (Zugriff auf Funktionen oder Daten, für die normalerweise eine Nutzerinitiierung oder Nutzerberechtigung erforderlich ist)
  • Remotezugriff auf ungeschützte Daten (d. h. Daten, auf die normalerweise jede lokal installierte App zugreifen kann)
  • Ausführen beliebigen Codes per Fernzugriff in einem eingeschränkten Kontext
  • Remoter vorübergehender Geräte-Denial-of-Service (Remote-Sperrung oder -Neustart)
Niedrig
  • Eine allgemeine Umgehung einer mehrschichtigen Verteidigung auf Nutzerebene oder einer Technologie zur Ausnutzungsminderung in einem nicht privilegierten Kontext
  • Umgehung einer normalen Berechtigung für das Schutzniveau
  • Kryptograpische Sicherheitslücke bei nicht standardmäßiger Verwendung
  • Allgemeine Umgehung von personalisierten Funktionen auf dem Gerät wie Voice Match oder Face Match
  • Falsche Dokumentation, die zu einer Sicherheitslücke führen kann
  • Lokale Ausführung beliebigen Codes in einem eingeschränkten Kontext
  • Systemdefinierter Text mit einer irreführenden Beschreibung, die falsche Sicherheitserwartungen weckt
Negligible Security Impact (NSI)
  • Eine Sicherheitslücke, deren Auswirkungen durch einen oder mehrere Bewertungsmodifikatoren oder versionspezifische Architekturänderungen so abgemildert wurden, dass die effektive Schwere unter „Niedrig“ liegt, obwohl das zugrunde liegende Codeproblem möglicherweise weiterhin besteht
  • Alle Sicherheitslücken, für die ein fehlerhaftes Dateisystem erforderlich ist, wenn dieses Dateisystem vor der Verwendung immer angepasst/verschlüsselt wird.
  • Lokaler vorübergehender Dienstausfall, z. B. wenn das Problem durch einen Neustart des Geräts oder das Deinstallieren der auslösenden App behoben werden kann.

Preismodifikatoren

Der Schweregrad von Sicherheitslücken lässt sich zwar oft leicht erkennen, die Bewertung kann sich jedoch je nach Umständen ändern.

Grund Effekte
Erfordert die Ausführung als privilegierter Kontext, um den Angriff auszuführen (nicht zutreffend für TEE, SE und Hypervisoren wie pKVM) -1 Schweregrad
Sicherheitslückenspezifische Details begrenzen die Auswirkungen des Problems -1 Schweregrad
Umgehung der biometrischen Authentifizierung, für die biometrische Daten direkt vom Geräteeigentümer erforderlich sind -1 Schweregrad
Compiler- oder Plattformkonfigurationen mindern eine Sicherheitslücke im Quellcode „Mittel“, wenn die zugrunde liegende Sicherheitslücke „Mittel“ oder höher ist
Erfordert physischen Zugriff auf die internen Komponenten des Geräts und ist auch möglich, wenn das Gerät ausgeschaltet ist oder seit dem Einschalten nicht entsperrt wurde. -1 Schweregrad
Erfordert physischen Zugriff auf die internen Komponenten des Geräts, während es eingeschaltet und zuvor entsperrt wurde -2 Schweregrad
Ein lokaler Angriff, für den die Bootloader-Kette entsperrt werden muss Nicht höher als „Niedrig“
Ein lokaler Angriff, für den der Entwicklermodus oder dauerhafte Einstellungen des Entwicklermodus derzeit auf dem Gerät aktiviert sein müssen (kein Fehler im Entwicklermodus selbst). Nicht höher als „Niedrig“
Wenn keine SELinux-Domain den Vorgang gemäß der von Google bereitgestellten SEPolicy ausführen kann Geringfügige Auswirkungen auf die Sicherheit

Lokal, proximal und fern

Ein Remote-Angriffsvektor gibt an, dass der Fehler ausgenutzt werden kann, ohne eine App zu installieren oder physischen Zugriff auf ein Gerät zu haben. Dazu gehören auch Fehler, die durch das Aufrufen einer Webseite, das Lesen einer E-Mail, den Empfang einer SMS oder die Verbindung zu einem feindseligen Netzwerk ausgelöst werden können.

Proximale Angriffsvektoren gelten als remote. Dazu gehören auch 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, für den fehlerhafte WLAN- oder Bluetooth-Pakete gesendet werden müssen. Wir betrachten Ultrabreitband- (UWB-) und NFC-basierte Angriffe als räumlich nah und daher als unwahrscheinlich.

Bei lokalen Angriffen muss der Angreifer bereits Zugriff auf das Opfer haben. In einem hypothetischen Beispiel, das sich nur auf Software bezieht, könnte dies über eine schädliche App erfolgen, die das Opfer installiert hat, oder über eine Instant App, für deren Ausführung es seine Einwilligung gegeben hat.

Geräte, die erfolgreich gekoppelt wurden (z. B. Bluetooth-Zubehör), gelten als lokal. Wir unterscheiden zwischen einem gekoppelten Gerät und einem Gerät, das an einem Kopplungsvorgang teilnimmt.

  • Fehler, die die Fähigkeit des Nutzers beeinträchtigen, das andere Gerät zu identifizieren, mit dem gekoppelt wird (d.h. Authentifizierung), gelten als proximär und daher als unwahrscheinlich.
  • Fehler, die während des Kopplungsvorgangs auftreten, aber vor der Nutzereinwilligung (d.h. Autorisierung) auftreten, gelten als proximär und daher als unwahrscheinlich.
  • Fehler, die nach der Einwilligung des Nutzers auftreten, gelten als lokal, auch wenn die Kopplung letztendlich fehlschlägt.

Physische Angriffsvektoren gelten 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 auf dem Sperrbildschirm oder ein Fehler, für den ein USB-Kabel angeschlossen werden muss. Da Geräte häufig entsperrt sind, wenn sie an ein USB-Gerät angeschlossen sind, sind Angriffe, für die eine USB-Verbindung erforderlich ist, unabhängig davon, ob das Gerät entsperrt werden muss oder nicht, gleich schwerwiegend.

Netzwerksicherheit

Android geht davon aus, dass alle Netzwerke feindlich sind und Angriffe ausführen oder den Traffic ausspionieren könnten. Die Sicherheit auf der Sicherungsschicht (z. B. WLAN-Verschlüsselung) schützt zwar die Kommunikation zwischen einem Gerät und dem Zugangspunkt, mit dem es verbunden ist, aber nicht die verbleibenden Glieder in der Kette zwischen dem Gerät und den Servern, mit denen es kommuniziert.

Im Gegensatz dazu schützt HTTPS in der Regel die gesamte Kommunikation Ende-zu-Ende, indem die Daten an der Quelle verschlüsselt und erst dann entschlüsselt und überprüft werden, wenn sie ihr Ziel erreicht haben. Aus diesem Grund werden Sicherheitslücken, die die Netzwerksicherheit der Sicherungsschicht beeinträchtigen, als weniger schwerwiegend eingestuft als Sicherheitslücken in HTTPS/TLS: Die WLAN-Verschlüsselung allein reicht für die meisten Kommunikationsformen im Internet nicht aus.

Biometrische Authentifizierung

Die biometrische Authentifizierung ist eine Herausforderung und selbst die besten Systeme können durch eine ähnliche Übereinstimmung getäuscht werden (siehe Android Developers Blog: Lockscreen and authentication improvements in Android 11). Diese Schweregrade unterscheiden zwischen zwei Angriffsklassen und sollen das tatsächliche Risiko für den Endnutzer widerspiegeln.

Die erste Angriffsklasse ermöglicht es, die biometrische Authentifizierung auf generalisierbare Weise zu umgehen, ohne hochwertige biometrische Daten des Eigentümers. Wenn ein Angreifer beispielsweise einen Kaugummi auf einen Fingerabdrucksensor legen kann, der dann aufgrund der Rückstände auf dem Sensor Zugriff auf das Gerät gewährt, ist das ein einfacher Angriff, der auf jedem anfälligen Gerät ausgeführt werden kann. Es sind keine Kenntnisse zum Eigentümer des Geräts erforderlich. Da er generalisierbar ist und sich potenziell auf eine größere Anzahl von Nutzern auswirken kann, erhält dieser Angriff die volle Bewertung der Schwere (z. B. „Hoch“ für einen Bypass des Sperrbildschirms).

Die andere Art von Angriffen umfasst in der Regel ein Präsentationsangriffsinstrument (Spoof), das auf dem Geräteinhaber basiert. Manchmal sind diese biometrischen Informationen relativ leicht zu erhalten. Wenn beispielsweise das Profilbild einer Person in den sozialen Medien ausreicht, um die biometrische Authentifizierung zu täuschen, erhält ein biometrischer Bypass die höchste Bewertung. Wenn ein Angreifer jedoch biometrische Daten direkt vom Geräteeigentümer abrufen muss (z. B. einen Infrarotscan seines Gesichts), ist das eine so große Hürde, dass die Anzahl der vom Angriff betroffenen Personen begrenzt ist. Daher wird der Wert um -1 korrigiert.

SYSTEM_ALERT_WINDOW und Tapjacking

Informationen zu unseren Richtlinien zu SYSTEM_ALERT_WINDOW und Tapjacking finden Sie auf der Seite Bugs ohne Sicherheitsrisiko der BugHunter University im Abschnitt Tapjacking/Overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen (Sicherheitsrisikofreies Systemfenster für Tapjacking/Overlay).

Sicherheit für mehrere Nutzer in Android Automotive OS

Android Automotive OS verwendet ein Sicherheitsmodell für mehrere Nutzer, das sich von den anderen Formfaktoren unterscheidet. Jeder Android-Nutzer soll von einer anderen natürlichen Person verwendet werden. Beispielsweise kann ein vorübergehender Gastnutzer einem Freund zugewiesen werden, der sich das Fahrzeug vom Eigentümer leiht. Für solche Anwendungsfälle haben Nutzer standardmäßig Zugriff auf die für die Nutzung des Fahrzeugs erforderlichen Komponenten, z. B. die WLAN- und Mobilfunkeinstellungen.

Betroffene Komponente

Das Entwicklungsteam, das für die Behebung des Fehlers verantwortlich ist, hängt davon ab, in welcher Komponente sich der Fehler befindet. Es kann sich um eine Kernkomponente der Android-Plattform, einen Kerneltreiber eines OEMs oder eine der vorinstallierten Apps auf Pixel-Geräten handeln.

Fehler im AOSP-Code werden vom Android-Entwicklerteam in unseren internen Repositories behoben.

Die Komponente ist auch ein Faktor dafür, wie Nutzer Updates erhalten. Ein Fehler im Framework oder Kernel erfordert ein Over-the-Air-Firmwareupdate (OTA), das von jedem OEM bereitgestellt werden muss. Ein Fehler in einer bei Google Play veröffentlichten App oder Bibliothek (z. B. Gmail, Google Play-Dienste oder WebView) kann Android-Nutzern als Update von Google Play gesendet werden.

Partner benachrichtigen

Wenn eine Sicherheitslücke in AOSP in einem Android-Sicherheitsbulletin behoben wird, benachrichtigen wir Android-Partner über die Details des Problems und stellen Patches bereit. Die Liste der unterstützten Backport-Versionen ändert sich mit jedem neuen Android-Release. Eine Liste der unterstützten Geräte erhalten Sie vom Gerätehersteller.

Code in AOSP veröffentlichen

Wenn sich der Sicherheitsfehler in einer AOSP-Komponente befindet, wird die Korrektur an AOSP gesendet, nachdem das OTA für Nutzer freigegeben wurde.

Android-Updates erhalten

Updates für das Android-System werden in der Regel über OTA-Update-Pakete auf Geräte übertragen. Diese Updates können vom OEM stammen, der das Gerät hergestellt hat, oder vom Mobilfunkanbieter, der den Dienst für das Gerät bereitstellt. Google Pixel-Geräteupdates stammen vom Google Pixel-Team, nachdem sie ein TA-Prüfverfahren (Technical Acceptance) des Mobilfunkanbieters durchlaufen haben. Google veröffentlicht auch Pixel-Factory-Images, die auf Geräten per Sideload installiert werden können.

Google-Dienste aktualisieren

Neben der Bereitstellung von Patches für Sicherheitslücken prüft das Android-Sicherheitsteam Sicherheitslücken, um festzustellen, ob es andere Möglichkeiten gibt, Nutzer zu schützen. Google Play scannt beispielsweise alle Apps und entfernt alle Apps, die versuchen, einen Sicherheitsfehler auszunutzen. Bei Apps, die nicht über Google Play installiert wurden, können Geräte mit Google Play-Diensten auch die Funktion Apps überprüfen verwenden, um Nutzer vor potenziell schädlichen Apps zu warnen.

Weitere Informationen

Informationen für Android-App-Entwickler: https://developer.android.com

Sicherheitsinformationen finden Sie auf den Android Open Source- und Entwicklerwebsites. Gute Ausgangspunkte:

Berichte

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