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:
|
| 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 |
|
| Hoch |
|
| Mäßig |
|
| Niedrig |
|
| Vernachlässigbare Sicherheitsauswirkungen (NSI) |
|
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 in Bezug auf SYSTEM_ALERT_WINDOW und Tapjacking finden Sie im Abschnitt „ Tapjacking/Overlay SYSTEM_ALERT_WINDOW-Schwachstelle auf einem nicht sicherheitskritischen Bildschirm “ auf der Seite „Fehler 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:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Berichte
Manchmal veröffentlicht das Android-Sicherheitsteam Berichte oder Whitepapers. Weitere Einzelheiten finden Sie unter Sicherheitsberichte .
,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:
|
| 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 |
|
| Hoch |
|
| Mäßig |
|
| Niedrig |
|
| Vernachlässigbare Sicherheitsauswirkungen (NSI) |
|
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). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.
SYSTEM_ALERT_WINDOW and Tapjacking
For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.
Multi-user security in Android Automotive OS
Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.
Affected component
The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.
Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.
The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.
Notifying partners
When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.
Releasing code to AOSP
If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.
Receiving Android updates
Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.
Updating Google services
In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.
Other resources
Information for Android app developers: https://developer.android.com
Security information exists throughout the Android Open Source and Developer sites. Good places to start:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Reports
Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.