Google empfiehlt, die Angriffsfläche von Grafikprozessoren in Android zu verkleinern, indem IOCTL-Befehle eingeschränkt werden, die Anwendungen in Produktionsumgebungen nicht benötigen, statt sich ausschließlich auf die Erkennung und Behebung einzelner Schwachstellen zu verlassen. Diese Praxis ist das Ergebnis einer Zusammenarbeit zwischen dem Android-Red-Team und Arm zur Analyse der Mali-GPU und ihres Treibers, wobei der Schwerpunkt auf der Verhinderung des Zugriffs auf nicht benötigte Funktionen mithilfe von SELinux liegt.
Dieser Schritt ist aus Sicherheitsgründen von Bedeutung, da die GPU aufgrund ihrer Komplexität und ihrer weitreichenden Berechtigungen innerhalb des Systems zu einem attraktiven Ziel für Angreifer geworden ist. Dem Beitrag zufolge zielte seit 2021 die Mehrheit der Exploits, die auf Android-Kernel-Treibern basierten, auf die GPU ab. Die Angriffe konzentrierten sich im Wesentlichen auf die Schnittstelle zwischen dem Treiber im Userspace, der als UMD bezeichnet wird, und dem privilegierten Treiber im Kernelspace, dem sogenannten KMD.
Warum hat die Verringerung der Angriffsfläche Priorität?
Über diese Schnittstelle eingeschleuste bösartige Eingaben können Schwachstellen ausnutzen, die zu Speicherbeschädigungen führen. Google ist der Ansicht, dass das Unzugänglichmachen nicht benötigter Pfade ein wirksames und häufig schnelleres Mittel zur Verbesserung des Schutzes darstellt, parallel zur weiteren Erkennung und Behebung von Softwarefehlern.
Die gemeinsame Analyse mit Arm umfasste den Mali-Treiber, der in etwa 45 % der Android-Geräte verwendet wird. Sie half dabei, Teile der Angriffsfläche zu identifizieren, die Sicherheitsrisiken darstellen, für den Betrieb der Geräte in der Produktion jedoch nicht erforderlich sind. Daher konzentrierte sich die Richtlinie auf IOCTL-Befehle, die die Ein- und Ausgaben des GPU-Treibers darstellen und somit einen wichtigen Teil der Angriffsfläche bilden.
Im vorgeschlagenen Ansatz werden die Mali-Befehle in drei Kategorien eingeteilt:
- Unbeschränkte Befehle: Sie werden für den normalen Betrieb benötigt und bleiben für Anwendungen verfügbar.
- Mess- und Tool-Befehle: Sie werden von Tools zur Leistungsanalyse und Fehlerbehebung verwendet, um die Leistung der GPU zu überwachen.
- Beschränkte Befehle: Produktionsanwendungen sollten sie nicht verwenden. Dazu gehören Befehle, die für die Entwicklung der GPU bestimmt sind, sowie veraltete Befehle, die in der aktuellen UMD-Version des Geräts nicht mehr verwendet werden.
Die Richtlinie soll veraltete Befehle und Debugging-Befehle in der Produktionsumgebung blockieren und Messbefehle auf die Shell oder Anwendungen mit dem Debugging-Flag beschränken. Produktionsbefehle bleiben für normale Anwendungen verfügbar.
Schrittweise Einführung der SELinux-Richtlinie
Google verfolgte einen schrittweisen Ansatz, um die Wahrscheinlichkeit einer Beeinträchtigung legitimer Anwendungen zu verringern. Der Prozess begann mit einer optionalen Richtlinie. Dabei wurde ein neues SELinux-Attribut namens gpu_harden erstellt, das Messbefehle blockiert, und anschließend auf eine bestimmte Gruppe von Systemanwendungen angewendet, um die Auswirkungen zu testen. In dieser Phase wurde die Regel allowxperm verwendet, um Zugriffsversuche zu protokollieren, anstatt sie unmittelbar zu blockieren. Anschließend wurden die Verweigerungsprotokolle überwacht, um sicherzustellen, dass keine Abstürze auftraten.
Nach der Bestätigung der Sicherheit des Ansatzes wurde die Richtlinie auf ein strengeres Standardmodell umgestellt. Dabei wurde ein Bereich namens gpu_debug erstellt, der den Zugriff auf Messbefehle erlaubt. Anwendungen waren damit standardmäßig geschützt, während Entwicklern in bestimmten Fällen Ausnahmen zur Verfügung standen:
- Ausführung der Anwendung auf einem Gerät mit Root-Berechtigungen.
- Setzen der Eigenschaft android:debuggable="true" in der Manifestdatei der Anwendung.
- Anforderung einer dauerhaften Ausnahme in der SELinux-Richtlinie der Anwendung.
Schritte zur Anwendung der Richtlinie auf Geräten
Google stellt die Anleitung bereit, um Partner und das breitere Ökosystem bei der Einführung eines vergleichbaren Mechanismus zu unterstützen, wobei die Logik der allgemeinen Richtlinie von den Details des jeweiligen Geräts oder Treibers getrennt wird. Der Prozess beginnt mit der Verwendung eines allgemeinen Makromoduls auf Ebene der Android-Plattform innerhalb von system/sepolicy. Dieses Modul befindet sich in der Datei /sepolicy/public/te_macros und ermöglicht es Geräterichtlinien, Listen von IOCTL-Befehlen zu übergeben, die gefiltert werden sollen.
Das Modul wurde so konzipiert, dass alle Anwendungen beziehungsweise die appdomain auf die Liste der unbeschränkten Befehle zugreifen können. Sensible Messbefehle werden dagegen auf Debugging-Tools wie shell oder runas_app beschränkt, wenn die Anwendung debuggbar ist. Außerdem blockiert es Befehle mit weitreichenden Berechtigungen abhängig von der Ziel-SDK-Version der Anwendung und bewahrt dabei die Kompatibilität mit älteren Anwendungen.
Anschließend erstellt der Geräteentwickler eine Datei ioctl_macros im gerätespezifischen SELinux-Richtlinienordner, beispielsweise device/your_company/your_device/sepolicy/ioctl_macros, und definiert darin die Befehlslisten für den GPU-Treiber. Google empfiehlt mindestens separate Listen für Produktions-, Mess- und Debugging-Befehle, die die hexadezimalen IOCTL-Nummern des Treibers enthalten.
Arm stellte in der Datei Documentation/ioctl-categories.rst der Version r54p2 eine offizielle Klassifizierung seiner IOCTL-Befehle bereit und wies darauf hin, dass die Liste mit künftigen Treiberversionen weiter aktualisiert wird.
Testen vor der Durchsetzung
Im nächsten Schritt wird die Richtlinie auf den Geräteknoten der GPU angewendet. Dazu wird im Richtlinienordner des Geräts eine Datei gpu.te erstellt. Anschließend wird das allgemeine Makromodul aufgerufen und mit dem Geräte-Label sowie den zuvor definierten IOCTL-Listen aufgerufen.
Google betont, dass die Entwicklung einer SELinux-Richtlinie ein iterativer Prozess bleiben sollte, der Tests, Feinabstimmung und anschließend die Durchsetzung umfasst. Dieser Ansatz ermöglicht es, Daten zur realen Nutzung zu sammeln, Fälle zu erkennen, die möglicherweise Ausnahmen erfordern, und den Geltungsbereich der Richtlinie schrittweise zu erweitern, statt von Anfang an weitreichende Einschränkungen durchzusetzen.
Google ist der Ansicht, dass die Verringerung der Angriffsfläche nicht nur vor bekannten Schwachstellen schützt, sondern auch dazu führen kann, dass bislang unentdeckte oder künftig auftretende Schwachstellen über die eingeschränkten Pfade nicht erreichbar sind. Die Ausweitung dieses Ansatzes erfordert eine Zusammenarbeit zwischen Android, Geräteherstellern und Ökosystempartnern. Die Sicherheitsteams von Android erklärten, sie seien entschlossen, die breitere Einführung dieser Maßnahmen zu unterstützen.