Home / Android-Entwicklung / Android Developers Blog: Warteschlange der Verbesserungen

Android Developers Blog: Warteschlange der Verbesserungen

Gepostet von Jeff Vander Stoep, Android Security & Privacy Team und Chong Zhang, Android Media Team

 Verbessertes Heldenbild

Android Q Beta-Versionen sind jetzt öffentlich verfügbar. Unter den verschiedenen neuen Funktionen, die in Android Q eingeführt wurden, befinden sich einige wichtige sicherheitsrelevante Änderungen. Während in jeder Android-Version aufregende neue Sicherheitsfunktionen hinzugefügt werden, bezieht sich das Härten im Allgemeinen auf Sicherheitsverbesserungen an vorhandenen Komponenten.

Bei der Priorisierung der Plattformhärtung analysieren wir Daten aus einer Reihe von Quellen, einschließlich unseres Vulnerability Rewards-Programms (VRP). Vergangene Sicherheitsprobleme bieten nützliche Einblicke in die Komponenten, die eine zusätzliche Härtung benötigen. Android veröffentlicht monatliche Security Bulletins, die Korrekturen für alle Sicherheitslücken mit hohem / kritischem Schweregrad im Android Open Source Project (AOSP) enthalten, die über unser VRP gemeldet wurden. Das Beheben von Schwachstellen ist zwar erforderlich, aber die Metadatenanalyse zum Ort und zur Klasse der Schwachstellen bietet uns auch einen großen Mehrwert. Mit dieser Einsicht können wir die folgenden Strategien auf unsere vorhandenen Komponenten anwenden:

  • Enthalten: Isolieren und Deaktivieren von Komponenten, insbesondere von Komponenten, die nicht vertrauenswürdigen Inhalt verarbeiten. Das beinhaltet:
    • Zugriffssteuerung: Hinzufügen von Berechtigungsprüfungen, Erhöhen der Granularität von Berechtigungsprüfungen oder Wechseln zu sichereren Standardeinstellungen (z. B. Standardverweigerung).
       
      Angriffsflächenreduzierung: Reduzieren der Anzahl von Eintritts- / Austrittspunkten (d. H. Prinzip des geringsten Privilegs).
       
    • Architekturzerlegung: Aufteilen privilegierter Prozesse in weniger privilegierte Komponenten und Anwenden der Reduzierung der Angriffsfläche.
  • Abmildern: Nehmen Sie an, dass Sicherheitsanfälligkeiten vorhanden sind, und verteidigen Sie sich aktiv gegen Sicherheitsanfälligkeitsklassen oder allgemeine Ausnutzungstechniken.

Hier ein Blick auf Schwachstellen mit hohem Schweregrad nach Komponente und Ursache ab 2018:

 Sicherheitsanfälligkeiten nach Komponente
 Sicherheitsanfälligkeiten nach Ursache

Die meisten Sicherheitsanfälligkeiten von Android treten in den Medien- und Bluetooth-Komponenten auf. Use-after-free (UAF), ganzzahlige Überläufe und OOB-Lese- / Schreibvorgänge machen 90% der Sicherheitsanfälligkeiten aus, wobei OOB am häufigsten vorkommt.

Eine eingeschränkte Sandbox für Software-Codecs

In Android Q haben wir Software-Codecs aus dem Haupt-MediaCodec-Dienst in eine eingeschränkte Sandbox verschoben. Dies ist ein großer Schritt vorwärts in unserem Bestreben, die Sicherheit zu verbessern, indem verschiedene Medienkomponenten in weniger privilegierten Sandboxen isoliert werden. Wie Mark Brand von Project Zero in seinem Blogpost "Return To Libstagefright" betont, befinden sich eingeschränkte Sandkästen nicht dort, wo ein Angreifer enden möchte. Im Jahr 2018 traten ungefähr 80% der Schwachstellen mit kritischem oder hohem Schweregrad in Medienkomponenten in Software-Codecs auf, was bedeutet, dass eine weitere Isolierung eine große Verbesserung darstellt. Aufgrund des erhöhten Schutzes durch die neue mediaswcodec-Sandbox erhalten dieselben Sicherheitsanfälligkeiten einen niedrigeren Schweregrad, der auf den Schweregradrichtlinien von Android basiert.

Die folgende Abbildung zeigt einen Überblick über die Entwicklung des Mediendienstlayouts in den letzten Android-Versionen.

  • Vor N befanden sich alle Mediendienste in einem einzigen monolithischen Mediaserver-Prozess, und die Extraktoren wurden im Client ausgeführt.
  • In N haben wir einen wichtigen Sicherheits-Re-Architect geliefert, bei dem eine Reihe von Mediendiensten auf niedrigerer Ebene in einzelne Dienstprozesse mit Sandboxen mit reduzierten Rechten ausgegliedert werden. Extraktoren werden auf die Serverseite verschoben und in eine eingeschränkte Sandbox gestellt. In mediaserver selbst blieben nur einige übergeordnete Funktionalitäten.
  • In O werden die Dienste "verdreifacht" und weiter benachteiligt, dh in einzelne Sandkästen aufgeteilt und in HALs umgewandelt. Der media.codec-Dienst wurde zu einer HAL, während sowohl Software- als auch Hardware-Codec-Implementierungen gehostet wurden.
  • In Q werden die Software-Codecs aus dem media.codec-Prozess extrahiert und zurück auf die Systemseite verschoben. Es wird ein Systemdienst, der die Codec-HAL-Schnittstelle verfügbar macht. Selinux Policy und Seccomp Filter werden für diesen Prozess weiter verschärft. Während der vorherige MediaCodec-Prozess Zugriff auf Gerätetreiber für hardwarebeschleunigte Codecs hatte, hat der Software-Codec-Prozess keinen Zugriff auf Gerätetreiber.

 Mehr zu weniger eingeschränkten Codecs

Mit diesem Schritt verfügen wir nun über die beiden Hauptquellen für Medienschwachstellen, die in eingeschränkten Prozessen eng umschlossen sind. Software-Codecs sind Extraktoren insofern ähnlich, als sie beide umfangreiche Code-Parsing-Bitströme von nicht vertrauenswürdigen Quellen aufweisen. Sobald eine Sicherheitsanfälligkeit im Quellcode identifiziert wurde, kann sie ausgelöst werden, indem eine gestaltete Mediendatei an Medien-APIs (wie MediaExtractor oder MediaCodec) gesendet wird. Durch Sandboxing dieser beiden Dienste können wir den Schweregrad potenzieller Sicherheitslücken verringern, ohne die Leistung zu beeinträchtigen.

Zusätzlich zur Einschränkung riskanterer Codecs wurde auch viel Arbeit in die Verhinderung gängiger Arten von Sicherheitsanfälligkeiten investiert.

Bound Sanitizer

Unkorrekte oder fehlende Speicherbeschränkungen bei der Überprüfung von Arrays machen etwa 34% der Sicherheitsanfälligkeiten von Android-Nutzern aus. In Fällen, in denen die Arraygröße zum Zeitpunkt der Kompilierung bekannt ist, kann der Bound Sanitizer (BoundSan) von LLVM Arrays automatisch instrumentieren, um Überläufe zu verhindern und einen sicheren Ausfall zu gewährleisten.

 Bound Sanitizer-Image

BoundSan-Instrumentierung

BoundSan ist in 11 Mediencodecs und im gesamten Bluetooth-Stack für Android Q aktiviert. Durch das Wegoptimieren einer Reihe unnötiger Überprüfungen wurde der Leistungsaufwand auf weniger als 1 reduziert %. BoundSan hat bereits potenzielle Sicherheitslücken in Codecs und Bluetooth gefunden / verhindert.

Mehr Integer-Sanitizer an mehr Orten

Android war Vorreiter bei der produktiven Verwendung von Sanitizern in Android Nougat, als wir mit der Einführung von Integer-Sanitizer (IntSan) in den Medien-Frameworks begannen. Diese Arbeit wurde mit jeder Veröffentlichung fortgesetzt und hat sehr erfolgreich dazu beigetragen, ansonsten ausnutzbare Sicherheitsanfälligkeiten zu verhindern. Beispielsweise wurden durch die neue IntSan-Abdeckung in Android Pie 11 kritische Sicherheitsanfälligkeiten verringert. Die Aktivierung von IntSan ist eine Herausforderung, da Überläufe im Allgemeinen harmlos und vorzeichenlose Ganzzahlüberläufe klar definiert und manchmal absichtlich sind. Dies unterscheidet sich erheblich von dem gebundenen Desinfektionsprogramm, bei dem OOB-Lese- / Schreibvorgänge immer unbeabsichtigt und häufig ausnutzbar sind. Intsan zu aktivieren war ein mehrjähriges Projekt, aber mit Q haben wir es vollständig für alle Medien-Frameworks aktiviert, einschließlich elf weiterer Codecs.

 IntSan-Instrumentierung

IntSan-Instrumentierung

IntSan verwendet arithmetische Operationen, um den Vorgang abzubrechen, wenn ein Überlauf auftritt. Diese Instrumentierung kann sich auf die Leistung auswirken. Daher ist eine Bewertung der Auswirkungen auf die CPU-Auslastung erforderlich. In Fällen, in denen die Auswirkungen auf die Leistung zu hoch waren, haben wir Hot-Funktionen identifiziert und IntSan für diese Funktionen einzeln deaktiviert, nachdem wir sie manuell auf ganzzahlige Sicherheit überprüft haben.

BoundSan und IntSan gelten als starke Schadensbegrenzer, da sie (sofern angewendet) die Hauptursache für Sicherheitsanfälligkeiten im Speicher verhindern. Die Klasse der Milderungen beschreibt als nächstes das Ziel allgemeiner Nutzungstechniken. Diese Abschwächungen werden als probabilistisch angesehen, da sie die Ausnutzung erschweren, indem sie die Verwendung einer Sicherheitsanfälligkeit einschränken.

Shadow Call Stack

LLVMs Control Flow Integrity (CFI) wurde in den Medien-Frameworks, Bluetooth und NFC in Android Pie aktiviert. CFI erschwert Angriffe auf die Wiederverwendung von Code, indem die Vorwärtskanten des Aufrufdiagramms wie Funktionszeiger und virtuelle Funktionen geschützt werden. Android Q verwendet den Shadow Call Stack (SCS) von LLVM, um Absenderadressen zu schützen und die Hinterkante des Kontrollflussdiagramms zu schützen. SCS erreicht dies, indem die Rücksprungadressen in einem separaten Schattenstapel gespeichert werden, der vor Datenverlust geschützt ist, indem seine Position im x18-Register gespeichert wird, das jetzt vom Compiler reserviert wird.

 SCS-Instrumentierung

SCS-Instrumentierung

SCS hat einen vernachlässigbaren Leistungsaufwand und einen geringen Speicherzuwachs aufgrund des separaten Stapels. In Android Q wurde SCS in Teilen des Bluetooth-Stacks aktiviert und ist auch für den Kernel verfügbar. Darüber werden wir in einem kommenden Beitrag mehr berichten.

Nur-eXecute-Speicher

Wie bei SCS zielt XOM (eXecute-Only Memory) darauf ab, gängige Ausnutzungstechniken teurer zu machen. Dies geschieht durch Stärkung des Schutzes, der bereits durch die Adressraum-Layout-Randomisierung (Address Space Layout Randomization, ASLR) bereitgestellt wird, was wiederum Code-Wiederverwendungsangriffe erschwert, indem Angreifer aufgefordert werden, zunächst den Ort des Codes zu ermitteln, den sie wiederverwenden möchten. Dies bedeutet häufig, dass ein Angreifer jetzt zwei Sicherheitslücken benötigt, ein Leseprimitiv und ein Schreibprimitiv, wobei zuvor nur ein Schreibprimitiv erforderlich war, um seine Ziele zu erreichen. XOM schützt vor Lecks (Speicherfreigaben von Codesegmenten), indem Code unlesbar gemacht wird. Versuche, Code nur zum Ausführen zu lesen, führen dazu, dass der Prozess sicher abgebrochen wird.

 Tombstone von einem XOM-Abbruch

Tombstone von einem XOM-Abbruch

Ab Android Q werden von der Plattform bereitgestellte AArch64-Codesegmente in Binärdateien und Bibliotheken nur als ausführbar geladen. Nicht alle Geräte erhalten sofort den Vorteil, da diese Durchsetzung Hardware-Abhängigkeiten (ARMv8.2 +) und Kernel-Abhängigkeiten (Linux 4.9+, CONFIG_ARM64_UAO) aufweist. Bei Apps mit einer TargetSdkVersion unter Q wird der Schutz durch den Zygote-Prozess von Android gelockert, um einen möglichen App-Bruch zu vermeiden. 64-Bit-Systemprozesse (z. B. Mediaextractor, Init, Vold usw.) werden jedoch geschützt. XOM-Schutz wird zur Kompilierungszeit angewendet und hat keinen Speicher- oder CPU-Overhead.

Scudo-Hardened-Allocator

Scudo ist ein dynamischer Heap-Allocator, der für die Ausfallsicherheit von Heap-bezogenen Sicherheitsanfälligkeiten entwickelt wurde, z.

  • Use-After-Frees: Durch Quarantäne von freigegebenen Blöcken.
  • Double-Frees: Durch Verfolgen von Blockzuständen.
  • Pufferüberlauf: Durch Überprüfen der Kopfzeilen.
  • Heap-Sprays und Layout-Manipulation: durch verbesserte Randomisierung.

Scudo verhindert nicht die Ausbeutung, sondern verwaltet den Speicher proaktiv, um die Ausbeutung zu erschweren. Je nach Leistungsanforderungen kann es pro Prozess konfiguriert werden. Scudo ist in Extraktoren und Codecs in den Medien-Frameworks aktiviert.

 Tombstone von Scudo wird abgebrochen

Tombstone von Scudo wird abgebrochen

Sicherheitsverbesserungen für Open Source beitragen

AOSP verwendet eine Reihe von Open Source-Projekten, um Android zu erstellen und zu sichern. Google leistet in einer Reihe sicherheitskritischer Bereiche einen aktiven Beitrag zu diesen Projekten:

Vielen Dank an Ivan Lozano, Kevin Deus, Kostya Kortchinsky, Kostya Serebryany und Mike Logan für ihre Beiträge zu diesem Beitrag.

About AndroidWeltEditor

Check Also

An introduction to the Google Play Console for Android Developers

If you want to be a successful app developer, learning how to code and build …

Leave a Reply

Your email address will not be published. Required fields are marked *