Sicherheitsupdates und Ressourcen

Das Android-Sicherheitsteam ist für die Verwaltung von Sicherheitslücken zuständig, die die Android-Plattform und viele der Android-Kernanwendungen auf Android-Geräten.

Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Forschung und auf Fehler reagieren, die von Dritten gemeldet wurden. Quellen für externe Fehler sind beispielsweise gemeldete Probleme über die Formular zu Sicherheitslücken, veröffentlichte und vorveröffentlichte akademische Forschung, vorgelagerte Open-Source-Projektmanager Benachrichtigungen von unseren Geräteherstellern und öffentlich gemeldete Probleme, die auf Blogs oder soziale Medien.

Sicherheitsprobleme melden

Alle Entwickler, Android-Nutzer und Sicherheitsforscher können das Android-Sicherheitsteam über potenzielle Sicherheitsprobleme durch die Formular zu Sicherheitslücken.

Programmfehler, die als Sicherheitsprobleme gekennzeichnet sind, sind extern nicht sichtbar, können aber trotzdem auftreten. nach der Überprüfung oder Behebung des Problems sichtbar. Wenn du vorhast, ein Patch oder CTS-Test (Compatibility Test Suite) zur Behebung eines Sicherheitsproblems (bitte an den Fehler anhängen) und warten Sie auf eine Antwort, bevor Sie den Code in AOSP hochladen.

Fehler analysieren

Die erste Aufgabe beim Umgang mit einer Sicherheitslücke besteht darin, welche Android-Komponente betroffen ist. Der Schweregrad bestimmt, wie das Problem priorisiert wird, und die Komponente bestimmt, wer den Fehler behebt, wer benachrichtigt wird und wie die Korrektur bereitgestellt wird. für Nutzende zu machen.

Kontexttypen

Diese Tabelle enthält die Definitionen von Hardware- und Software-Sicherheitskontexten. Der Kontext kann durch die Vertraulichkeit der Daten, die in der Regel verarbeitet werden, oder den Bereich, in dem sie ausgeführt wird, definiert wird. Nicht dass alle Sicherheitskontexte auf alle Systeme anwendbar sind. Diese Tabelle ist vom niedrigsten zum größten Wert geordnet privilegiert sind.

Kontexttyp Typdefinition
Eingeschränkter Kontext Eine eingeschränkte Ausführungsumgebung, in der nur die geringstmöglichen Berechtigungen vorhanden sind bereitgestellt.

Beispiel: vertrauenswürdige Anwendungen, die nicht vertrauenswürdige Daten innerhalb einer Sandbox verarbeiten. zu verbessern.
Nicht privilegierter Kontext Eine typische Ausführungsumgebung, die von nicht privilegiertem Code erwartet wird.

Beispiel: Eine Android-Anwendung, die in einer SELinux-Domain mit dem untrusted_app_all-Attribut.
Privilegierter Kontext Eine privilegierte Ausführungsumgebung, die Zugriff auf erweiterte Berechtigungen, Aliasse hat und/oder die Systemintegrität gewahrt.

Beispiel: Eine Android-App mit Funktionen, die laut SELinux untrusted_app-Domain oder mit Zugriff auf privileged|signature-Berechtigungen.
Betriebssystem-Kernel Funktionen, die:
  • gehört zum Kernel
  • wird im selben CPU-Kontext wie der Kernel ausgeführt (z. B. Gerätetreiber)
  • direkten Zugriff auf den Kernel-Arbeitsspeicher hat (z. B. auf die Hardwarekomponenten auf dem Gerät)
  • kann Skripts in eine Kernel-Komponente (z. B. eBPF) laden.
  • ist einer der wenigen Nutzerdienste, die als Kernel-Äquivalent gelten (z. B. apexd, bpfloader, init, ueventd, und vold).
Vertrauenswürdige Hardware-Basis (THB) Diskrete Hardwarekomponenten, in der Regel auf dem SoC, bieten wichtige Funktionen auf die wichtigsten Anwendungsfälle des Geräts (z. B. Mobilfunk-Basisbänder, DSPs, GPUs und ML) ausgerichtet sind. Prozessoren).
Bootloader-Kette Eine Komponente, die das Gerät beim Starten konfiguriert und dann die Steuerung an das Android-Betriebssystem übergibt.
Vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) Eine Komponente, die so konzipiert ist, dass sie auch vor einem feindlichen Betriebssystem-Kernel (z. B. TrustZone und Hypervisoren wie pKVM, die virtuelle Maschinen vor dem Betriebssystem schützen Kernel) enthält.
Secure Enclave / Secure Element (SE) Eine optionale Hardwarekomponente, die vor allen anderen Komponenten auf der Gerät und vor einem physischen Angriff, wie in den Einführung in Secure Elements

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

Wichtigkeit

Der Schweregrad eines Fehlers spiegelt im Allgemeinen den potenziellen Schaden wider, der auftreten könnte, wenn ein Fehler erfolgreich ausgenutzt werden. Legen Sie den Schweregrad anhand der folgenden Kriterien fest.

Bewertung Folgen einer erfolgreichen Ausnutzung
Kritisch
  • Ausführung beliebiger Codes im TEE oder SE
  • Umgehung von Softwaremechanismen, die dazu dienen, sicherheitsrelevante Software oder Hardware zu verhindern Fehlfunktionskomponenten (z. B. Überhitzungsschutz)
  • Remotezugriff auf vertrauliche Anmeldedaten für die Remote-Dienstauthentifizierung (für z. B. Kontopasswörter oder Inhabertokens)
  • Ausführung von beliebigem Code aus der Ferne innerhalb des Basisbandkontexts ohne Nutzer Interaktion (z. B. Ausnutzung eines Fehlers im Mobilfunkdienst)
  • Remote-Ausführung von beliebigem Code in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem Betriebssystem-Kernel
  • Umgehen der Anforderungen an die Nutzerinteraktion bei der Paketinstallation oder vergleichbaren Paketen aus der Ferne Verhalten
  • Umgehen der Anforderungen an die Nutzerinteraktion für Kernentwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Remote-Persistent Denial of Service (permanent, erfordert es, den gesamten Betriebssystem oder das Zurücksetzen auf die Werkseinstellungen)
  • Umgehung für sicheren Start per Fernzugriff
  • Unbefugter Zugriff auf Daten, die durch den SE gesichert sind, einschließlich Zugriff, der durch schwache Schlüssel in der SE.
Hoch
  • Eine vollständige Umgehung einer zentralen Sicherheitsfunktion (z. B. SELinux, FBE oder seccomp)
  • Eine allgemeine Umgehung für gestaffelte Sicherheitsebenen oder Exploits Bootloader-Kette, TEE oder SE
  • Allgemeine Umgehung des Betriebssystemschutzes, mit dem Arbeitsspeicher- oder Dateiinhalte offengelegt werden über App-, Nutzer- oder Profilgrenzen hinweg
  • Angriffe auf einen SE, die zu einem Downgrade auf eine weniger sichere Implementierung führen
  • Pivoting von per Fernzugriff erreichbarer, manipulierter Bare-Metal-Firmware (z.B. Baseband, CP/Kommunikationsprozessor) in den AP-Kernel (Application Processor) ein oder aus Mechanismen zur Isolierung der Bare-Metal-Firmware vom AP-Kernel.
  • Umgehung des Geräteschutzes/Schutzes für das Zurücksetzen auf Werkseinstellungen/Einschränkungen des Mobilfunkanbieters
  • Umgehung der Anforderungen an die Nutzerinteraktion, die durch das TEE gesichert sind
  • Kryptografische Sicherheitslücke, die Angriffe auf End-to-End-Protokolle ermöglicht, einschließlich Angriffen gegen Transport Layer Security (TLS) und Bluetooth (BT).
  • Lokaler Zugriff auf vertrauliche Anmeldedaten für die Remote-Dienstauthentifizierung (für z. B. Kontopasswörter oder Inhabertokens)
  • Lokale Ausführung von beliebigem Code in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem Betriebssystem-Kernel
  • Lokaler Secure Boot-Umgehung
  • Sperrbildschirm umgehen
  • Lokale Umgehung der Anforderungen an die Nutzerinteraktion für wichtige Entwickler, Sicherheit oder Datenschutz Einstellungen
  • Lokale Umgehung der Anforderungen an die Nutzerinteraktion bei der Paketinstallation oder äquivalenten Einstellungen Verhalten
  • Lokaler dauerhafter Denial of Service (dauerhaft, das Aktualisieren des gesamten Betriebssystems oder das Zurücksetzen auf die Werkseinstellungen)
  • Remotezugriff auf geschützte Daten, d. h. Daten, die auf eine privilegierte Person beschränkt sind Kontext)
  • Ausführung von beliebigem Code aus der Ferne in einem nicht privilegierten Kontext
  • Verhindern des Zugriffs auf Mobilfunk- oder WLAN-Dienste per Fernzugriff ohne Nutzerinteraktion (für Beispiel: Absturz des Mobilfunkdienstes mit einem fehlerhaften Paket)
  • Umgehen der Anforderungen an die Nutzerinteraktion (Zugriff auf Funktionen oder Daten, die sollte entweder eine Nutzerinitiierung oder eine Nutzerberechtigung erfordern.)
  • Der Zugriff auf Rettungsdienste wird gezielt verhindert
  • Übertragung vertraulicher Daten über ein unsicheres Netzwerkprotokoll (z. B. HTTP und unverschlüsseltes Bluetooth), wenn der Anforderer eine sichere Übertragung erwartet. Hinweis dass dies nicht auf WLAN-Verschlüsselung (z. B. WEP) zutrifft
  • Unbefugter Zugriff auf Daten, die vom TEE gesichert wurden, einschließlich Zugriff, der durch schwache Schlüssel ermöglicht wird im T-Shirt
Mäßig
  • Allgemeine Umgehung für gestaffelte Sicherheitsebenen oder Exploits privilegierter Kontext, THB oder den Kernel des Betriebssystems
  • Eine allgemeine Umgehung der Betriebssystemschutzfunktionen, die den Prozessstatus oder Metadaten über App-, Nutzer- oder Profilgrenzen hinweg
  • Umgehen der WLAN-Verschlüsselung oder -Authentifizierung
  • Kryptografische Sicherheitslücke in standardmäßigen kryptografischen Primitiven, die den Datenlecks Klartext (keine Primitive, die in TLS verwendet werden)
  • 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 der Anforderungen an die Nutzerinteraktion (Zugriff auf Funktionen oder Daten, die erfordert normalerweise eine Nutzerinitiierung oder eine Nutzerberechtigung.)
  • Remotezugriff auf ungeschützte Daten (d. h. Daten, die normalerweise lokal zugänglich sind) installierte App)
  • Ausführung von beliebigem Code aus der Ferne in einem eingeschränkten Kontext
  • Vorübergehender Denial-of-Service-Angriff auf ein Remote-Gerät (Remote-Hängen oder Neustart)
Niedrig
  • Eine allgemeine Umgehung für gestaffelte Sicherheitsebenen oder Exploits einem nicht privilegierten Kontext
  • Normale umgehen Schutzniveau Berechtigung
  • Kryptografische Sicherheitslücke bei nicht standardmäßiger Nutzung
  • 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
  • Systemdefinierter Text, der eine irreführende Beschreibung enthält, die einen falschen Sicherheitserwartung
Vernachlässigbare Sicherheitsauswirkungen (NSI)
  • Eine Sicherheitslücke, deren Auswirkungen durch einen oder mehrere Bewertungsmodifikatoren oder versionspezifische Architekturänderungen vornehmen, sodass der effektive Schweregrad unter „Niedrig“ liegt, Das zugrunde liegende Codeproblem kann jedoch
  • Jede Schwachstelle, die ein fehlerhaftes Dateisystem erfordert, wenn dieses Dateisystem immer akzeptiert/verschlüsselt.
  • Lokaler temporärer Denial-of-Service, z. B. wenn das Problem durch einen Neustart des Geräts oder eine Deinstallation behoben werden kann der auslösenden App.

Modifikatoren für Bewertungen

Der Schweregrad von Sicherheitslücken ist oft leicht zu erkennen, die Altersfreigaben können sich jedoch ändern je nach Situation.

Grund Effekt
Erfordert das Ausführen des Angriffs als privilegierter Kontext (gilt nicht für TEE, SE, und Hypervisoren wie pKVM) -1 Schweregrad
Details zu Sicherheitslücken begrenzen die Auswirkungen des Problems -1 Schweregrad
Umgehung der biometrischen Authentifizierung, bei der biometrische Informationen direkt vom Geräteeigentümer -1 Schweregrad
Compiler- oder Plattformkonfigurationen verringern eine Sicherheitslücke im Quellcode Mittelmäßiger Schweregrad, wenn die zugrunde liegende Sicherheitslücke mäßig oder höher ist
Erfordert physischen Zugriff auf das interne Gerät und ist weiterhin möglich, wenn das Gerät ausgeschaltet oder wurde seit dem Einschalten nicht entsperrt -1 Schweregrad
Erfordert physischen Zugriff auf das interne Gerät, während das Gerät eingeschaltet und zuvor wurde entsperrt -2 Schweregrad
Lokaler Angriff, bei dem die Bootloader-Kette entsperrt werden muss Nicht höher als niedrig
Ein lokaler Angriff, für den der Entwicklermodus oder persistente Entwicklermoduseinstellungen erforderlich sind, auf dem Gerät aktiviert sein (und im Entwicklermodus selbst kein Fehler 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, proximal und remote im Vergleich

Ein Remote-Angriffsvektor deutet darauf hin, dass der Fehler ausgenutzt werden kann, ohne eine App zu installieren oder ohne physischen Zugriff auf ein Gerät. Dazu gehören auch Fehler, die durch das Aufrufen eines eine E-Mail lesen, eine SMS empfangen oder sich mit einem feindlichen Netzwerk verbinden.

Proximale Angriffsvektoren gelten als remote. Dazu gehören auch Fehler, die nur ausgenutzt werden können. die sich in der Nähe des Zielgeräts befinden, wie z. B. ein Fehler, Es werden fehlerhafte WLAN- oder Bluetooth-Pakete gesendet. Wir verwenden Ultrabreitband (UWB) und NFC proximal und daher remote angreifen.

Bei lokalen Angriffen muss der Angreifer Zugriff auf das Opfer haben. In einer hypothetischen Beispiel: Eine schädliche App, die das Opfer installiert hat, oder eine Instant-App, die sie haben zugestimmt haben.

Geräte, die erfolgreich gekoppelt wurden, z. B. Bluetooth-Begleitgeräte, gelten als lokal. Mi. zwischen einem gekoppelten Gerät und einem Gerät unterscheiden, das an einer Kopplung beteiligt ist Ablauf.

  • Fehler, die es dem Nutzer erschweren, das gekoppelte Gerät zu identifizieren (z.B. Authentifizierung) werden als proximal und daher als remote betrachtet.
  • Fehler, die während des Kopplungsvorgangs auftreten, aber vor der Zustimmung des Nutzers (d.h. der Autorisierung) werden als proximal und daher als extern eingestuft.
  • Fehler, die nach dem Einrichten der Nutzereinwilligung auftreten, gelten als lokal, auch wenn schlägt schließlich fehl.

Körperliche Angriffsvektoren gelten als lokal. Dazu gehören auch Fehler, die nur von Angreifer, die physischen Zugriff auf das Gerät haben, z. B. einen Programmfehler in einem Sperrbildschirm für die ein USB-Kabel erforderlich ist. Da es üblich ist, dass Geräte entsperrt werden, an einem USB-Anschluss angeschlossen sind, haben Angriffe, die eine USB-Verbindung erfordern, den gleichen Schweregrad ob das Gerät entsperrt werden muss oder nicht

Netzwerksicherheit

Bei Android wird davon ausgegangen, dass alle Netzwerke feindselig sind und daher Angriffe oder Ausspionieren einschleusen könnten. Zugriffe. Link-Layer-Sicherheit (z. B. WLAN-Verschlüsselung) schützt die Kommunikation zwischen dem Gerät und dem Zugangspunkt, mit dem es verbunden ist, verbleibenden Verbindungen zwischen dem Gerät und den Servern, mit denen es kommuniziert.

Im Gegensatz dazu schützt HTTPS in der Regel die gesamte Ende-zu-Ende-Kommunikation und verschlüsselt die Daten an seiner Quelle an und entschlüsseln und verifizieren sie erst, wenn sie ihr endgültiges Ziel erreicht haben. Aus diesem Grund werden Sicherheitslücken, die die Netzwerksicherheit der Linkschicht gefährden, weniger bewertet. schwerer als Schwachstellen in HTTPS/TLS: Die WLAN-Verschlüsselung allein reicht für die meisten Kommunikation im Internet.

Biometrische Authentifizierung

Die biometrische Authentifizierung ist ein herausfordernder Bereich, und selbst die besten Systeme lassen sich durch eine beinahe Übereinstimmung (siehe Blog für Android-Entwickler: Verbesserungen beim Sperrbildschirm und der Authentifizierung in Android 11 Diese Schweregradbewertungen unterscheiden zwischen zwei Angriffsklassen und zielen darauf ab, das tatsächliche Risiko für die Endanwendenden widerspiegeln.

Bei der ersten Art von Angriffen ist es möglich, die biometrische Authentifizierung auf generalisierbare Weise zu umgehen. ohne qualitativ hochwertige biometrische Daten vom Inhaber. Wenn ein Angreifer beispielsweise Kaugummi auf einem Fingerabdrucksensor, der den Zugriff auf das Gerät ermöglicht ist das ein einfacher Angriff, der auf jedem anfälligen Gerät durchgeführt werden kann. Es erfordert keine Kenntnis des Geräteeigentümers. Da sie generalisierbar ist und potenziell mehr Nutzer betroffen sind, erhält dieser Angriff den vollen Schweregrad (z. B. „Hoch“, um den Sperrbildschirm zu umgehen).

Bei der anderen Art von Angriffen handelt es sich in der Regel um einen Präsentations-Angriffsinstrumente (Spoof), der auf . Manchmal sind diese biometrischen Daten relativ leicht zu erhalten (für Wenn beispielsweise das Profilbild einer Person in den sozialen Medien ausreicht, würde eine biometrische Umgehung den vollen Schweregrad erhalten). Würde ein Angreifer jedoch um biometrische Daten direkt vom Eigentümer des Geräts zu erhalten (z. B. einen Infrarotscan von ist ein so großes Hindernis, dass es die Anzahl der betroffenen Menschen durch den Angriff, also gibt es einen -1-Modifikator.

SYSTEM_ALERT_WINDOW und Tapjacking

Informationen zu unseren Richtlinien in Bezug auf SYSTEM_ALERT_WINDOW und mobiles Bezahlen siehe die SYSTEM_ALERT_WINDOW-Sicherheitslücke bei Tapjacking/Overlay auf einem nicht sicherheitskritischen Bildschirm. der BugHunter University Fehler ohne Auswirkungen auf die Sicherheit Seite.

Sicherheit für mehrere Nutzer in Android Automotive OS

Android Automotive OS verwendet ein Sicherheitsmodell für mehrere Nutzer die sich von den anderen Formfaktoren unterscheiden. Jeder Android-Nutzer soll von einem anderen eine physische Person. Beispielsweise kann ein temporärer Gastnutzer einem Freund zugewiesen werden, vom Eigentümer des Autos ab. Um diesen Anwendungsfällen gerecht zu werden, müssen Nutzer Zugriff auf notwendige Komponenten wie WLAN und Mobilfunknetz, die für die Nutzung des Fahrzeugs erforderlich sind Einstellungen.

Betroffene Komponente

Welches Entwicklungsteam für die Behebung des Fehlers verantwortlich ist, hängt davon ab, in welcher Komponente sich der Fehler befindet. Es könnte eine Kernkomponente der Android-Plattform sein, ein Kernel-Treiber, der von einem Hersteller (OEM) oder eine der vorinstallierten Apps auf Pixel-Geräten.

Fehler im AOSP-Code werden vom Android-Entwicklerteam behoben. Geringfügige Fehler, Programmfehler in oder bereits öffentlich bekannten Fehler können direkt im öffentlich verfügbarer AOSP-Hauptzweig andernfalls werden sie in unseren internen Repositories .

Die Komponente ist auch ein Faktor dafür, wie Nutzende Updates erhalten. Fehler im Framework oder Kernel erfordert ein OTA-Firmwareupdate (Over The Air), das jeder OEM bereitstellen muss. Ein Fehler in einer App oder in Google Play veröffentlichte Bibliotheken (z. B. Gmail, Google Play-Dienste oder WebView) als Update von Google Play an Android-Nutzer gesendet.

Partner benachrichtigen

Wenn eine Sicherheitslücke in AOSP in einem Android-Sicherheitsbulletin behoben wird, benachrichtigen wir Sie Android-Partner für Problemdetails und stellen Patches zur Verfügung. Die Liste der von Backport unterstützten Versionen ändert sich mit jeder neuen Android-Version. Wenden Sie sich an den Hersteller Ihres Geräts, unterstützten Geräten.

Code für AOSP freigeben

Befindet sich der Sicherheitsfehler in einer AOSP-Komponente, wird die Korrektur an AOSP weitergegeben, nachdem das OTA-Update abgeschlossen wurde. für Nutzer freigegeben. Korrekturen von niedrigem Schweregrad können direkt an die AOSP-Hauptseite gesendet werden. bevor eine Korrektur für Geräte über ein OTA-Update verfügbar ist.

Android-Updates erhalten

Updates für das Android-System werden in der Regel als OTA-Update-Pakete an die Geräte übermittelt. Diese Updates können von dem OEM stammen, der das Gerät hergestellt hat, oder vom Mobilfunkanbieter, der das Gerät anbietet. auf das Gerät übertragen. Updates für Google Pixel-Geräte kommen vom Google Pixel-Team, über ein technisches Akzeptanztestverfahren (Trade-Testing) des Netzbetreibers durchgeführt werden. Google veröffentlicht auch Pixel-Werkseinstellungen, die Sie auf Ihrem Pixel per Sideload auf Geräte übertragen.

Google-Dienste aktualisieren

Neben der Bereitstellung von Patches für Sicherheitslücken überprüft das Android-Sicherheitsteam auch die um festzustellen, ob es andere Möglichkeiten zum Schutz der Nutzer gibt. Google Play scannt beispielsweise alle und entfernt alle Apps, die versuchen, einen Sicherheitsfehler auszunutzen. Für Apps, die über auf Geräten mit Google Play-Diensten Funktion Apps überprüfen, um zu warnen über Apps informieren, die potenziell schädlich sein könnten.

Weitere Informationen

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

Sicherheitsinformationen sind auf allen Open-Source- und Entwickler-Websites von Android verfügbar. Gut sollten Sie anfangen:

Berichte

Manchmal veröffentlicht das Android Security-Team Berichte oder Whitepapers. Weitere Informationen finden Sie unter Sicherheitsberichte.