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 Android-Kernanwendungen entdeckt wurden.

Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Recherchen und reagiert auch auf Fehler, die von Dritten gemeldet werden. Quellen externer Fehler sind Probleme durch den berichteten Android Security Issue Template , veröffentlicht und vorveröffentlichten akademische Forschung, Upstream - Open - Source - Projekt - Maintainer, Meldungen unserer Gerätehersteller Partner und offenbarten Probleme öffentlich in Blogs oder Social Media geschrieben.

Sicherheitsprobleme melden

Jeder Entwickler, Android Benutzer oder Sicherheitsforscher kann das Android - Sicherheitsteam von möglichen Sicherheitsproblemen durch die benachrichtigen Sicherheitslücke Meldeformular .

Fehler, die als Sicherheitsprobleme gekennzeichnet sind, sind von außen nicht sichtbar, können jedoch nach der Bewertung oder Behebung des Problems möglicherweise sichtbar gemacht werden. Wenn Sie planen, einen Patch oder Compatibility Test Suite (CTS)-Test zur Behebung eines Sicherheitsproblems einzureichen, fügen Sie diesen bitte dem Fehlerbericht bei und warten Sie auf eine Antwort, bevor Sie den Code in AOSP hochladen.

Triagieren von Fehlern

Die erste Aufgabe bei der Behebung einer Sicherheitslücke besteht darin, den Schweregrad 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 den Benutzern bereitgestellt wird.

Kontexttypen

Diese Tabelle enthält die Definitionen von Hardware- und Softwaresicherheitskontexten. Der Kontext kann durch die Sensibilität der typischerweise verarbeiteten Daten oder den Bereich, in dem sie ausgeführt werden, definiert werden. Nicht alle Sicherheitskontexte sind auf alle Systeme anwendbar. Diese Tabelle ist von den am wenigsten bis zu den am meisten privilegierten geordnet.

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

Zum Beispiel Anwendungs-"Sandboxes", um nicht vertrauenswürdige Daten zu verarbeiten, ohne den Zugriff auf das zugrunde liegende System zu erlauben.
Unprivilegierter Kontext Eine typische Ausführungsumgebung, die von unprivilegiertem Code erwartet wird.

Zum Beispiel kann eine Android - Anwendung , die ausgeführt wird in einer SELinux Domäne mit dem untrusted_app_all Attribute.
Privilegierter Kontext Eine privilegierte Ausführungsumgebung, die Zugriff auf erhöhte Berechtigungen haben kann, mehrere Benutzer-PII verarbeitet und/oder die Systemintegrität aufrechterhält.

Eine Android - Anwendung mit Funktionen zum Beispiel der von der SELinux verboten würde untrusted_app Domain oder mit Zugang zur privileged|signature Berechtigungen.
Vertrauenswürdige Rechenbasis (TCB) Funktionalität, die Teil des Kernels ist, im selben CPU-Kontext wie der Kernel läuft (wie Gerätetreiber), hat direkten Zugriff auf Kernelspeicher (wie Hardwarekomponenten auf dem Gerät), hat die Fähigkeit, Skripte in eine Kernelkomponente zu laden ( beispielsweise EBPF), die Kommunikationsprozessoren oder ein von einer Handvoll von Benutzerdienste , die Kernel gleichwertig betrachtet wird: apexd , bpfloader , init , ueventd und vold .
Bootloader-Kette Eine Komponente, die das Gerät beim Booten konfiguriert und dann die Kontrolle an das Android-Betriebssystem übergibt.
Vertrauenswürdige Ausführungsumgebung (TEE) Eine Komponente, die selbst vor einem feindlichen Kernel geschützt werden soll (z. B. TrustZone und Hypervisor).
Sichere Enklave / Sicheres Element (SE) Eine optionale Hardwarekomponente entwickelt , um sich von allen anderen Komponenten des Gerätes und von der physischen Angriff geschützt werden, wie es in definiert Introduction to Secure Elements .

Dazu gehört der Titan-M-Chip, der in einigen Pixel-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 wurde. Verwenden Sie die folgenden Kriterien, um den Schweregrad zu bestimmen.

Bewertung Folge einer erfolgreichen Verwertung
Kritisch
  • Unbefugter Zugriff auf von der SE gesicherte Daten
  • Beliebige Codeausführung im TEE oder SE
  • Remote-Ausführung willkürlichen Codes in einem privilegierten Kontext, der Bootloader-Kette oder dem TCB
  • Persistenter Remote-Denial-of-Service (permanent oder erfordert einen Neustart des gesamten Betriebssystems oder ein Zurücksetzen auf die Werkseinstellungen)
  • Remote-Umgehung von Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Remote-Umgehung von Benutzerinteraktionsanforderungen für Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Remote Secure Boot Bypass
  • Umgehung von Mechanismen, die eine Fehlfunktion sicherheitsrelevanter Software- oder Hardwarekomponenten verhindern sollen (z. B. Thermoschutz)
  • Remote-Zugriff auf sensible Anmeldeinformationen, die für die Remote-Service-Authentifizierung verwendet werden (z. B. Kontokennwörter oder Inhaber-Token)
Hoch
  • Lokale sichere Boot-Umgehung
  • Eine vollständige Umgehung einer zentralen Sicherheitsfunktion (wie SELinux, FDE oder seccomp)
  • Remote-Ausführung willkürlichen Codes in einem unprivilegierten Kontext
  • Lokale Ausführung von beliebigem Code in einem privilegierten Kontext, der Bootloader-Kette oder dem TCB
  • Unbefugter Zugriff auf Daten, die durch den TEE gesichert sind
  • Angriffe gegen eine SE, die zu einer Herabstufung auf eine weniger sichere Implementierung führen
  • Lokale Umgehung von Benutzerinteraktionsanforderungen bei der Paketinstallation oder gleichwertigem Verhalten
  • Fernzugriff auf geschützte Daten (Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Lokaler dauerhafter Denial-of-Service (permanent oder erfordert ein erneutes Flashen des gesamten Betriebssystems oder Zurücksetzen auf die Werkseinstellungen)
  • Remote-Umgehung von Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, für die normalerweise entweder eine Benutzerinitiierung oder eine Benutzerberechtigung erforderlich wäre)
  • Übertragung sensibler 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)
  • Eine allgemeine Umgehung für eine Tiefenverteidigungs- oder Exploit-Mitigation-Technologie in der Bootloader-Kette, TEE oder SE
  • Eine allgemeine Umgehung für den Schutz von Betriebssystemen, die App-Daten oder Benutzerprofile voneinander isolieren
  • Lokale Umgehung von Benutzerinteraktionsanforderungen für Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Kryptografische Schwachstelle, die Angriffe gegen End-to-End-Protokolle ermöglicht, einschließlich Angriffe auf Transport Layer Security (TLS) und Bluetooth (BT).
  • Sperrbildschirm umgehen
  • Umgehung von Geräteschutz/Factory-Reset-Schutz/Trägereinschränkungen
  • Gezielte Verhinderung des Zugangs zu Rettungsdiensten
  • Umgehung von Benutzerinteraktionsanforderungen, die durch den TEE . abgesichert sind
  • Remote-Verhinderung des Zugriffs auf Mobilfunkdienste ohne Benutzerinteraktion (z. B. Absturz des Mobilfunkdienstes mit einem fehlerhaften Paket)
  • Lokaler Zugriff auf vertrauliche Anmeldeinformationen, die für die Remote-Service-Authentifizierung verwendet werden (z. B. Kontokennwörter oder Inhabertoken)
Mäßig
  • Remote-Ausführung willkürlichen Codes in einem eingeschränkten Kontext
  • Remote-Denial-of-Service für temporäre Geräte (Remote-Aufhängung oder Neustart)
  • Lokale Ausführung von beliebigem Code in einem unprivilegierten Kontext
  • Eine allgemeine Umgehung für eine Defense-in-Depth- oder Exploit-Mitigation-Technologie in einem privilegierten Kontext oder dem TCB
  • Umgehung von Einschränkungen eines eingeschränkten Prozesses
  • Fernzugriff auf ungeschützte Daten (Daten, die normalerweise für jede lokal installierte App zugänglich sind)
  • Lokaler Zugriff auf geschützte Daten (Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Lokale Umgehung von Benutzerinteraktionsanforderungen (Zugriff auf Funktionen oder Daten, die normalerweise entweder eine Benutzerinitiierung oder eine Benutzerberechtigung erfordern)
  • Kryptografische Schwachstelle in Standard-Kryptoprimitiven, die das Durchsickern von Klartext ermöglicht (keine in TLS verwendeten Primitive)
  • Umgehen der WLAN-Verschlüsselung oder -Authentifizierung
Niedrig
  • Lokale Ausführung von beliebigem Code in einem eingeschränkten Kontext
  • Kryptografische Schwachstelle bei nicht standardmäßiger Verwendung
  • Eine allgemeine Umgehung für eine tiefgreifende Verteidigung auf Benutzerebene oder eine Technologie zur Exploit-Abwehr in einem nicht privilegierten Kontext
  • Falsche Dokumentation, die zu einem sicherheitsrelevanten Missverständnis mit nachfolgenden Codefehlern führen kann
  • Allgemeine Bypass von On-Device - Personalisierungsfunktionen wie Voice - Spiel oder Gesicht Spiel
Vernachlässigbare Sicherheitsauswirkungen (NSI)
  • Eine Schwachstelle, deren Auswirkungen durch einen oder mehrere Bewertungsmodifikatoren oder versionsspezifische Architekturänderungen gemildert wurden, sodass der effektive Schweregrad unter Niedrig liegt, obwohl das zugrunde liegende Codeproblem möglicherweise bestehen bleibt
  • Jede Schwachstelle , die ein ungültiges Dateisystem erfordert, wenn das Dateisystem immer angenommen / verschlüsselte vor dem Gebrauch.

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 -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 Mäßiger 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 Geräteinterna, 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-Domain den Vorgang gemäß der von Google bereitgestellten SEPolicy durchführen kann Vernachlässigbare Sicherheitsauswirkungen

Lokal versus Proximal versus Remote

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, den Empfang einer SMS-Nachricht oder die Verbindung zu einem feindlichen Netzwerk ausgelöst werden können. Für unsere Schweregradbewertungen betrachten wir 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, beispielsweise ein Fehler, der das Senden fehlerhafter Wi-Fi- oder Bluetooth-Pakete erfordert. Wir betrachten Ultra-Wideband (UWB) und NFC-basierte Angriffe als proximal und daher entfernt.

Lokale Angriffe erfordern das Opfer , eine App zu laufen, entweder durch die Installation und eine App läuft oder durch zustimmenden eine ausführen Instant - App . Zum Zwecke der Schweregradbewertung betrachten wir 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 einer, der das Anschließen eines USB-Kabels erfordert. Beachten Sie, dass Angriffe, die eine USB-Verbindung erfordern, den gleichen Schweregrad aufweisen, 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.

Netzwerksicherheit

Android geht davon aus, dass alle Netzwerke feindlich sind und Angriffe injizieren 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, tut sie nichts, um die verbleibenden Links in der Kette zwischen dem Gerät und den Servern, mit denen es kommuniziert, zu schützen.

Im Gegensatz dazu schützt HTTPS normalerweise die gesamte Kommunikation Ende-zu-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 Verbindungsschicht gefährden, als weniger schwerwiegend eingestuft als Schwachstellen in HTTPS/TLS: Die WLAN-Verschlüsselung allein reicht für die meisten Kommunikationen im Internet nicht aus.

Biometrische Authentifizierung

Biometrische Authentifizierung ein herausfordernder Raum ist, und auch die besten Systeme können von einem nahen Spiel täuschen (siehe Android Developers Blog: Lockscreen und Authentifizierung Verbesserungen in Android 11 ). Diese Schweregradeinstufungen unterscheiden zwischen zwei Angriffsklassen und sollen das tatsächliche Risiko für den Endbenutzer widerspiegeln.

Die erste Klasse von Angriffen ermöglicht es, die biometrische Authentifizierung auf verallgemeinerbare Weise ohne hochwertige biometrische Daten des Besitzers zu umgehen. Wenn ein Angreifer beispielsweise ein Kaugummi auf einen Fingerabdrucksensor legen kann und dieser Zugriff auf das Gerät basierend auf Rückständen auf dem Sensor gewährt, ist dies ein einfacher Angriff, der auf jedem anfälligen Gerät ausgeführt werden könnte. Es erfordert keine Kenntnis des Besitzers des Geräts. Da er generalisierbar ist und potenziell eine größere Anzahl von Benutzern betrifft, erhält dieser Angriff die volle Schweregradbewertung (z. B. Hoch für eine Sperrbildschirmumgehung).

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 ein biometrischer Bypass die volle Schweregradbewertung erhalten). Wenn ein Angreifer jedoch biometrische Daten direkt vom Gerätebesitzer erhalten muss (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 von -1 .

SYSTEM_ALERT_WINDOW und Tapjacking

Weitere Informationen zu unseren Richtlinien in Bezug auf SYSTEM_ALERT_WINDOW und tapjacking finden Sie in der „Tapjacking / Overlay SYSTEM_ALERT_WINDOW Verwundbarkeit auf einer nicht-sicherheitskritischen Bildschirm“ Abschnitt BugHunter Universität Bugs ohne Auswirkungen auf die Sicherheit Seite.

Betroffene Komponente

Das für die Behebung des Fehlers verantwortliche Entwicklungsteam hängt davon ab, in welcher Komponente sich der Fehler befindet. Dies kann eine Kernkomponente der Android-Plattform, ein Kernel-Treiber 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 Fehler, die bereits öffentlich bekannt sind, können direkt im öffentlich verfügbaren AOSP-Master-Zweig 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-Dienste 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 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.

Code an AOSP freigeben

Wenn sich der Sicherheitsfehler in einer AOSP-Komponente befindet, wird der Fix an AOSP weitergegeben, nachdem der OTA für die Benutzer freigegeben wurde. Fixes für Probleme mit geringem Schweregrad können direkt an den AOSP-Master-Zweig gesendet werden, bevor ein Fix für Geräte über einen OTA verfügbar ist.

Empfangen von Android-Updates

Updates für das Android-System werden im Allgemeinen über OTA-Update-Pakete an Geräte geliefert. Diese Updates können von dem OEM stammen, der das Gerät hergestellt hat, oder von dem Netzbetreiber, der den Service für das Gerät bereitstellt. Updates für Google Pixel-Geräte stammen vom Google Pixel-Team, nachdem es ein Testverfahren zur technischen Abnahme durch den Mobilfunkanbieter durchlaufen hat. Google veröffentlicht auch Pixel Fabrik Bilder , die Seiten geladen Geräte sein kann.

Aktualisieren von Google-Diensten

Das Android-Sicherheitsteam stellt nicht nur Patches für Sicherheitsfehler bereit, sondern überprüft auch Sicherheitsfehler, um festzustellen, ob es andere Möglichkeiten zum Schutz der Benutzer gibt. Google Play scannt beispielsweise alle Apps und entfernt alle Apps, die versuchen, einen Sicherheitsfehler auszunutzen. Für Anwendungen außerhalb von Google Play installiert, Geräte mit Google Play - Dienste können auch die Verwendung Apps überprüfen Funktion , um Benutzer über Apps zu warnen , die möglicherweise schädlich sein kann.

Andere Ressourcen

Informationen für Android App - Entwickler: 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. Siehe Sicherheitsberichte für weitere Details.