Contexte technique

Sur Android, chaque application tierce s’exécute dans le domaine SELinux untrusted_app avec un UID dédié et un filtre seccomp. Cette combinaison de DAC, SELinux et seccomp réduit l’accès aux nœuds du noyau : seules les interfaces essentielles (syscalls de gestion mémoire, VFS, futex, timers, Binder, et quelques nœuds graphiques comme /dev/kgsl-3d0 ou le nœud DRM) restent visibles. Les pilotes spécifiques aux OEM, ainsi que les interfaces DSP/NPU, sont masqués par la politique SELinux et ne sont accessibles qu’après une élévation de privilège.

Stratégie d’exploitation

L’étude propose d’exploiter une use‑after‑free (UAF) de page située dans un pilote noyau propre à l’OEM. Une UAF conserve une référence physique à une page libérée, permettant à un attaquant de réutiliser cette page comme primitive de lecture/écriture. Le point d’entrée de la chaîne est un sandbox escape également présent dans le code OEM, qui permet de passer du domaine untrusted_app à un domaine plus privilégié où le pilote vulnérable est exposé. Tous les bugs exploités proviennent du code OEM, ce qui évite la dépendance aux correctifs du noyau Linux générique ou aux pilotes de chipset.

Analyse de fiabilité, portabilité et universalité

La fiabilité repose sur la stabilité de la primitive de page : contrairement aux bugs de type heap ou stack, la UAF de page n’est pas affectée par KASLR, CFI ou le durcissement du slab, car elle agit au niveau physique. La portabilité découle du fait que le même type de bug (UAF de page) est recherché dans chaque pilote OEM, sans adaptation majeure au numéro de version du noyau. L’universalité est illustrée par les trois implémentations présentées : une chaîne couvre les smartphones Samsung Galaxy S23 à S26 et la série Z, une seconde cible la plupart des appareils Xiaomi milieu‑à‑haut de gamme, et une troisième touche les flagships Oppo, OnePlus et Realme récents. Aucun des trois scénarios nécessite de désactiver le bootloader, démontrant que la méthode fonctionne même avec le chargeur verrouillé.

Limites et perspectives

La méthode dépend de la présence d’une UAF de page dans le code OEM et d’un mécanisme d’évasion de sandbox accessible depuis untrusted_app. Si un fabricant corrige ces deux vecteurs, la chaîne devient inopérante. De plus, la recherche de ces bugs reste manuelle : chaque nouveau modèle OEM doit être analysé pour identifier la combinaison exacte de pilote et de politique SELinux. Enfin, la chaîne ne contourne pas les protections de type verified boot ou les mises à jour OTA qui peuvent remplacer le pilote vulnérable entre deux versions du firmware.