Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Sicherheitsupdates und Ressourcen

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

Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Recherchen und reagiert auch auf Fehler, die von Dritten gemeldet wurden. Zu den Ursachen für externe Fehler zählen Probleme, die über die Vorlage für Android-Sicherheitsprobleme gemeldet wurden, veröffentlichte und vorveröffentlichte akademische Forschungsergebnisse, vorgelagerte Open-Source-Projektbetreuer, Benachrichtigungen unserer Partner von Geräteherstellern und öffentlich bekannt gegebene Probleme, die in Blogs oder sozialen Medien veröffentlicht wurden.

Sicherheitsprobleme melden

Jeder Entwickler, Android-Benutzer oder Sicherheitsforscher kann das Android-Sicherheitsteam über das Formular zur Meldung von Sicherheitslücken über potenzielle Sicherheitsprobleme informieren.

Als Sicherheitsprobleme gekennzeichnete Fehler sind von außen nicht sichtbar, können jedoch eventuell sichtbar gemacht werden, nachdem das Problem bewertet oder behoben wurde. Wenn Sie einen Patch oder einen CTS-Test (Compatibility Test Suite) einreichen möchten, um ein Sicherheitsproblem zu beheben, fügen Sie ihn dem Fehlerbericht hinzu und warten Sie auf eine Antwort, bevor Sie den Code auf AOSP hochladen.

Triaging Bugs

Die erste Aufgabe bei der Behandlung einer Sicherheitslücke besteht darin, die Schwere des Fehlers und die betroffene Komponente von Android 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 für Benutzer bereitgestellt wird.

Prozesstypen

Diese Tabelle enthält die Definitionen der Prozesstypen. Der Prozesstyp kann durch den Typ der App oder des Prozesses oder den Bereich definiert werden, in dem er ausgeführt wird. Diese Tabelle ist von den am wenigsten privilegierten geordnet.

Prozessart Typdefinition
Eingeschränkter Prozess Ein Prozess, der in einer stark eingeschränkten SELinux-Domäne ausgeführt wird.
ODER
Ein Prozess, der wesentlich eingeschränkter ist als eine normale App.
Unprivilegierter Prozess Eine Anwendung oder ein Prozess, der in einer SELinux-Domäne mit dem Attribut untrusted_app_all wird oder entsprechend eingeschränkt ist.
Privilegierter Prozess Eine App oder ein Prozess mit Funktionen, die von der SELinux-Domäne untrusted_app verboten wären.
ODER
Eine App oder ein Prozess mit wichtigen Berechtigungen, die eine Drittanbieter-App nicht erhalten kann.
ODER
Eine integrierte Hardwarekomponente auf dem Gerät, die nicht Teil der Trusted Computing Base (TCB) ist.
Trusted Computing Base (TCB) Funktionen, die Teil des Kernels sind, im selben CPU-Kontext wie der Kernel ausgeführt werden (z. B. Gerätetreiber), direkten Zugriff auf den Kernelspeicher (z. B. Hardwarekomponenten auf dem Gerät) und Skripte in eine Kernelkomponente laden können (z. Beispiel: eBPF), der Basisbandprozessor, oder einer von wenigen Benutzerdiensten, die als Kernel-Äquivalent angesehen werden: init , ueventd und vold .
Bootloader 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 Kernel (z. B. TrustZone und Hypervisor) geschützt werden soll.
Sicheres Element (SE) Eine optionale Komponente, 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 .

Schwere

Die Schwere eines Fehlers spiegelt im Allgemeinen den potenziellen Schaden wider, der auftreten kann, wenn ein Fehler erfolgreich ausgenutzt wurde. Verwenden Sie die folgenden Kriterien, um den Schweregrad zu bestimmen.

Bewertung Folge erfolgreicher Ausbeutung
Kritisch
  • Nicht autorisierter Zugriff auf von der SE gesicherte Daten
  • Beliebige Codeausführung im TEE oder SE
  • Remote-Ausführung von beliebigem Code in einem privilegierten Prozess, Bootloader oder TCB
  • Permanenter permanenter Denial-of-Service (Geräteunfähigkeit: vollständig permanent oder erneutes Flashen des gesamten Betriebssystems oder Zurücksetzen auf die Werkseinstellungen)
  • Remote-Umgehung der Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Remote-Umgehung der Benutzerinteraktionsanforderungen für Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Remote Secure Boot Bypass
  • Umgehung von Sicherheitsmechanismen, die verhindern sollen, dass kritische Hardwarekomponenten fehlerhaft funktionieren (z. B. Wärmeschutz)
Hoch
  • Lokaler sicherer Boot-Bypass
  • Eine vollständige Umgehung einer zentralen Sicherheitsfunktion (wie SELinux, FDE oder seccomp)
  • Remote-Ausführung von beliebigem Code in einem nicht privilegierten Prozess
  • Lokale Ausführung von beliebigem Code in einem privilegierten Prozess, Bootloader oder TCB
  • Nicht autorisierter Zugriff auf vom TEE gesicherte Daten
  • Angriffe gegen eine SE, die zu einem Downgrade auf eine weniger sichere Implementierung führen
  • Lokale Umgehung der Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Fernzugriff auf geschützte Daten (Daten, die auf einen privilegierten Prozess beschränkt sind)
  • Lokaler permanenter Denial-of-Service (Geräteunfähigkeit: permanent oder erfordert ein erneutes Flashen des gesamten Betriebssystems oder Zurücksetzen auf die Werkseinstellungen)
  • Remote-Umgehung der Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, für die normalerweise entweder eine Benutzerinitiierung oder eine Benutzerberechtigung erforderlich ist)
  • Übertragen 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 wie WEP gilt).
  • Ein allgemeiner Bypass für eine Tiefenverteidigung oder die Nutzung der Schadensbegrenzungstechnologie im Bootloader, TEE oder SE
  • Ein allgemeiner Bypass für den Betriebssystemschutz, der App-Daten oder Benutzerprofile voneinander isoliert
  • Lokale Umgehung der Benutzerinteraktionsanforderungen für Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Kryptografische Sicherheitsanfälligkeit in Standard Transport Layer Security (TLS), die Angriffe auf dem Pfad ermöglicht
  • Sperrbildschirm-Bypass
  • Bypass des Geräteschutzes / Werksreset-Schutz / Trägerbeschränkungen
  • Gezielte Verhinderung des Zugangs zu Rettungsdiensten
  • Umgehung der Benutzerinteraktionsanforderungen, die vom TEE gesichert werden
Mäßig
  • Remote-Ausführung von beliebigem Code in einem eingeschränkten Prozess
  • Denial-of-Service für temporäre Remote-Geräte (Remote-Hang oder Neustart)
  • Lokale Ausführung von beliebigem Code in einem nicht privilegierten Prozess
  • Ein allgemeiner Bypass für eine Tiefenverteidigung oder die Nutzung der Schadensbegrenzungstechnologie in einem privilegierten Prozess oder dem TCB
  • Umgehung von Einschränkungen für einen eingeschränkten Prozess
  • Fernzugriff auf ungeschützte Daten (Daten, auf die normalerweise eine lokal installierte App zugreifen kann)
  • Lokaler Zugriff auf geschützte Daten (Daten, die auf einen privilegierten Prozess beschränkt sind)
  • Lokale Umgehung der Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, für die normalerweise entweder eine Benutzerinitiierung oder eine Benutzerberechtigung erforderlich ist)
  • Kryptografische Sicherheitsanfälligkeit in Standard-Krypto-Grundelementen, die das Durchsickern von Klartext ermöglicht (keine in TLS verwendeten Grundelemente)
  • Umgehen der Wi-Fi-Verschlüsselung oder -Authentifizierung
Niedrig
  • Lokale Ausführung von beliebigem Code in einem eingeschränkten Prozess
  • Kryptografische Sicherheitsanfälligkeit bei nicht standardmäßiger Verwendung
  • Eine allgemeine Umgehung für eine Tiefenverteidigung auf Benutzerebene oder die Nutzung der Schadensbegrenzungstechnologie in einem nicht privilegierten Prozess
Vernachlässigbare Auswirkungen auf die Sicherheit (NSI)
  • Eine Sicherheitsanfälligkeit, deren Auswirkungen durch einen oder mehrere Bewertungsmodifikatoren oder versionenspezifische Architekturen gemindert wurden, ändert sich so, dass der effektive Schweregrad unter "Niedrig" liegt, obwohl das zugrunde liegende Codeproblem möglicherweise bestehen bleibt
  • Jede Sicherheitsanfälligkeit, die ein fehlerhaftes Dateisystem erfordert, wenn dieses Dateisystem vor der Verwendung immer übernommen / verschlüsselt wird .

Bewertungsmodifikatoren

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

Grund Bewirken
Erfordert die Ausführung als privilegierter Prozess, um den Angriff auszuführen -1 Schweregrad
Anfälligkeitsspezifische Details begrenzen die Auswirkungen des Problems -1 Schweregrad
Umgehung der biometrischen Authentifizierung, für die biometrische Informationen direkt vom Gerätebesitzer benötigt werden -1 Schweregrad
Compiler- oder Plattformkonfigurationen verringern eine Sicherheitsanfälligkeit im Quellcode Moderater Schweregrad, wenn die zugrunde liegende Sicherheitsanfälligkeit mittel oder höher ist
Erfordert physischen Zugriff auf Geräteinternale und ist weiterhin möglich, wenn das Telefon ausgeschaltet ist oder seit dem Einschalten nicht entsperrt wurde -1 Schweregrad
Erfordert physischen Zugriff auf Geräteinternale, während das Telefon eingeschaltet ist und zuvor entsperrt wurde -2 Schweregrad
Ein lokaler Angriff, bei dem der Bootloader entsperrt werden muss Nicht höher als niedrig
Ein lokaler Angriff, bei dem der Entwicklermodus oder dauerhafte Einstellungen für den Entwicklermodus derzeit auf dem Gerät aktiviert sein müssen (und kein Fehler im Entwicklermodus selbst ist). Nicht höher als niedrig
Wenn keine SELinux-Domain den Vorgang unter der von Google bereitgestellten SEPolicy durchführen kann Vernachlässigbare Auswirkungen auf die Sicherheit

Lokal versus Proximal versus Remote

Ein Remote-Angriffsvektor zeigt an, dass der Fehler ohne Installation einer App oder ohne physischen Zugriff auf ein Gerät ausgenutzt werden kann. Dies schließt Fehler ein, die ausgelöst werden können, indem Sie zu einer Webseite navigieren, eine E-Mail lesen, eine SMS-Nachricht empfangen oder eine Verbindung zu einem feindlichen Netzwerk herstellen. Für die Zwecke unserer Schweregrade betrachtet das Android-Sicherheitsteam auch "proximale" 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, bei dem fehlerhafte Wi-Fi- oder Bluetooth-Pakete gesendet werden müssen. Das Android-Sicherheitsteam betrachtet NFC-basierte Angriffe als proximal und daher remote.

Bei lokalen Angriffen muss das Opfer eine App ausführen, indem es entweder eine App installiert und ausführt oder der Ausführung einer Sofort-App zustimmt. Für die Bewertung des Schweregrads betrachtet das Android-Sicherheitsteam auch physische Angriffsmethoden 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 ein Fehler, bei dem ein USB-Kabel angeschlossen werden muss. Beachten Sie, dass Angriffe, für die eine USB-Verbindung erforderlich ist, denselben Schweregrad haben, unabhängig davon, ob das Gerät entsperrt werden muss oder nicht. Es ist üblich, dass Geräte entsperrt werden, während sie an USB angeschlossen sind.

Wi-Fi-Sicherheit

Android geht davon aus, dass alle Netzwerke feindlich eingestellt sind und Angriffe auslösen oder den Datenverkehr ausspionieren können. Während die Sicherheit auf Verbindungsebene (z. B. Wi-Fi-Verschlüsselung) die Kommunikation zwischen einem Gerät und dem Wi-Fi-Zugangspunkt, mit dem es verbunden ist, sichert, werden die verbleibenden Verbindungen in der Kette zwischen dem Gerät und den Servern, mit denen es kommuniziert, nicht gesichert .

Im Gegensatz dazu schützt HTTPS in der Regel die gesamte Kommunikation von Ende zu Ende, verschlüsselt die Daten an ihrer Quelle und entschlüsselt und überprüft sie erst, wenn sie ihr endgültiges Ziel erreicht haben. Aus diesem Grund werden Schwachstellen, die die Wi-Fi-Sicherheit 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 ein herausfordernder Bereich, und selbst die besten Systeme können durch eine nahezu übereinstimmende Darstellung getäuscht werden. Diese Schweregrade unterscheiden zwischen zwei Angriffsklassen und sollen das tatsächliche Risiko für den Endbenutzer widerspiegeln.

Die erste Klasse von Angriffen ermöglicht die verallgemeinerbare Umgehung der biometrischen Authentifizierung ohne hochwertige biometrische Daten des Eigentümers. Wenn ein Angreifer beispielsweise ein Stück Gummi auf einen Fingerabdrucksensor legen kann und auf der Grundlage der auf dem Sensor verbleibenden Rückstände Zugriff auf das Gerät gewährt, ist dies ein einfacher Angriff, der auf jedem anfälligen Gerät ausgeführt werden kann. Es erfordert keine Kenntnis des Gerätebesitzers. Da dieser Angriff verallgemeinerbar ist und möglicherweise eine größere Anzahl von Benutzern betrifft, erhält er den vollen Schweregrad (z. B. Hoch für einen Lockscreen-Bypass).

Bei der anderen Angriffsklasse handelt es sich im Allgemeinen um ein Präsentationsangriffsinstrument (Parodie), das auf dem Gerätebesitzer basiert. Manchmal ist es relativ einfach, diese biometrischen Informationen abzurufen (wenn beispielsweise das Profilbild einer Person in sozialen Medien ausreicht, um die biometrische Authentifizierung zu täuschen, erhält ein biometrischer Bypass den vollen Schweregrad). Wenn ein Angreifer jedoch biometrische Daten direkt vom Gerätebesitzer abrufen müsste (z. B. einen Infrarot-Scan seines Gesichts), ist dies eine ausreichend große Barriere, um die Anzahl der von dem Angriff betroffenen Personen zu begrenzen. Daher gibt es einen Modifikator -1 .

Betroffene Komponente

Das Entwicklungsteam, das für die Behebung des Fehlers verantwortlich ist, hängt davon ab, in welcher Komponente sich der Fehler befindet. Dies kann eine Kernkomponente der Android-Plattform, ein Kerneltreiber eines Originalgeräteherstellers (OEM) oder eine der vorinstallierten Apps auf Pixel-Geräten sein .

Fehler im AOSP-Code werden vom Android-Engineering-Team behoben. Fehler mit niedrigem Schweregrad, Fehler in bestimmten Komponenten oder bereits öffentlich bekannte Fehler können direkt in der öffentlich verfügbaren AOSP-Hauptniederlassung 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 OTA-Firmware-Update (Over-the-Air), das jeder OEM pushen muss. Ein Fehler in einer in Google Play veröffentlichten App oder Bibliothek (z. B. Google Mail, 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 Security Bulletin behoben wird, benachrichtigen wir Android-Partner über Problemdetails und stellen Patches bereit. Die Liste der von 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.

Freigabe des Codes an AOSP

Wenn sich der Sicherheitsfehler in einer AOSP-Komponente befindet, wird der Fix an AOSP gesendet, nachdem der OTA für Benutzer freigegeben wurde. Korrekturen für Probleme mit geringem Schweregrad können direkt an die AOSP-Hauptniederlassung gesendet werden, bevor Geräte über eine OTA eine Lösung erhalten.

Android-Updates erhalten

Updates für das Android-System werden in der Regel über OTA-Update-Pakete an Geräte gesendet. Diese Updates können vom OEM stammen, der das Gerät hergestellt hat, oder vom Netzbetreiber, der das Gerät bedient. Google Pixel-Geräteaktualisierungen stammen vom Google Pixel-Team, nachdem ein TA-Testverfahren (Carrier Technical Acceptance) durchgeführt wurde. Google veröffentlicht auch Pixel Factory-Bilder , die seitlich auf Geräte geladen werden können.

Google-Dienste aktualisieren

Zusätzlich zur 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, einen Sicherheitsfehler auszunutzen. Bei Apps, die von außerhalb von Google Play installiert wurden, verwenden Geräte mit Google Play Services möglicherweise auch die Funktion " Apps überprüfen", um Benutzer vor Apps zu warnen, die möglicherweise schädlich sind.

Andere Ressourcen

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

Sicherheitsinformationen sind auf allen Android Open Source- und Entwickler-Websites vorhanden. Gute Startpunkte:

Berichte

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