Mali GPU Kernel LPE (Élévation de privilèges locale du noyau Mali GPU)

Cet article fournit une analyse approfondie de deux vulnérabilités du noyau dans le GPU Mali, accessibles depuis le sandbox applicatif par défaut, que j'ai identifiées et signalées indépendamment à Google. Il inclut un exploit noyau qui permet des capacités de lecture/écriture arbitraires dans le noyau. Par conséquent, il désactive SELinux et élève les privilèges vers root sur les modèles Google Pixel 7 et 8 Pro exécutant les versions Android 14 suivantes :

• Pixel 8 Pro : google/husky/husky:14/UD1A.231105.004/11010374:user/release-keys
• Pixel 7 Pro : google/cheetah/cheetah:14/UP1A.231105.003/11010452:user/release-keys
• Pixel 7 Pro : google/cheetah/cheetah:14/UP1A.231005.007/10754064:user/release-keys
• Pixel 7 : google/panther/panther:14/UP1A.231105.003/11010452:user/release-keys (par m4b4 (Marcel))

Vulnérabilités

Cet exploit exploite deux vulnérabilités : un dépassement d'entier résultant d'un correctif incomplet dans la commande ioctl gpu_pixel_handle_buffer_liveness_update_ioctl, et une fuite d'informations dans les tampons de messages du flux de timeline.

Sous-dépassement de tampon dans gpu_pixel_handle_buffer_liveness_update_ioctl() dû à un correctif incorrect du dépassement d'entier

Google a corrigé un dépassement d'entier dans la commande ioctl gpu_pixel_handle_buffer_liveness_update_ioctl dans ce commit. Au départ, lorsque j'ai signalé ce problème, je pensais que le bogue était causé par un problème dans le correctif décrit précédemment. Après avoir examiné le rapport, j'ai réalisé que mon analyse de la vulnérabilité était inexacte. Malgré ma première hypothèse selon laquelle le correctif était incomplet, il résout et prévient effectivement un sous-dépassement dans le calcul. Cela m'a conduit à soupçonner que la modification n'avait pas été appliquée dans les versions de production. Cependant, bien que je puisse provoquer un sous-dépassement dans le calcul, il n'est pas possible de provoquer un dépassement. Cela suggère que la commande ioctl a été partiellement corrigée, mais pas avec le correctif montré ci-dessus. En regardant IDA, il s'est avéré qu'un autre correctif incomplet a été livré dans les versions de production, et ce correctif n'est présent dans aucune branche git du module noyau mali gpu.

Cette vulnérabilité a été découverte pour la première fois dans la dernière version d'Android et signalée le 19 novembre 2023. Google m'a ensuite informé qu'ils l'avaient déjà identifiée en interne et lui avaient attribué CVE-2023-48409 dans le bulletin de sécurité Android de décembre, la qualifiant de problème en double. Bien que j'aie pu vérifier que le bogue avait été identifié en interne plusieurs mois avant mon signalement (basé sur la date du commit vers le 30 août), il subsiste une confusion. Plus précisément, il est étrange que les niveaux de correctifs de sécurité (SPL) d'octobre et novembre des appareils les plus récents aient toujours été affectés par cette vulnérabilité — je n'ai pas examiné les versions antérieures à celles-ci. Par conséquent, je ne peux pas déterminer de manière concluante s'il s'agissait vraiment d'un problème en double et si le correctif approprié était effectivement prévu pour décembre avant ma soumission, ou s'il y a eu un oubli dans la correction de cette vulnérabilité.

Quoi qu'il en soit, ce qui rend ce bogue puissant est ce qui suit :

• Le tampon info.live_ranges est entièrement contrôlé par l'utilisateur.
• Les valeurs de dépassement sont une entrée contrôlée par l'utilisateur, de sorte que nous pouvons faire dépasser le calcul pour que le pointeur info.live_ranges puisse être à un décalage arbitraire avant le début de l'adresse noyau buff.
• La taille d'allocation est également une entrée contrôlée par l'utilisateur, ce qui permet de demander une allocation mémoire à partir de n'importe quel allocateur de slabs à usage général.

Cette vulnérabilité partage des similitudes avec la vulnérabilité de sous-dépassement de tampon DeCxt::RasterizeScaleBiasData() que j'ai trouvée et exploitée dans le noyau iOS 15 en 2022.

Fuite de pointeurs noyau dans les tampons de messages du flux de timeline

Le GPU Mali implémente un timeline stream personnalisé conçu pour collecter des informations, les sérialiser, puis les écrire dans un tampon circulaire selon un format spécifique. Les utilisateurs peuvent invoquer la commande ioctl kbase_api_tlstream_acquire pour obtenir un descripteur de fichier, leur permettant de lire ce tampon circulaire. Le format des messages est le suivant :

• Un en-tête de paquet

• Un identifiant de message

• Un tampon de message sérialisé, dont le contenu spécifique dépend de l'ID du message. Par exemple, la fonction __kbase_tlstream_tl_kbase_kcpuqueue_enqueue_fence_wait sérialise les pointeurs noyau kbase_kcpu_command_queue et dma_fence dans le tampon de message, ce qui entraîne une fuite de pointeurs noyau vers l'espace utilisateur.```c void __kbase_tlstream_tl_kbase_kcpuqueue_enqueue_fence_wait( struct kbase_tlstream *stream, const void *kcpu_queue, const void *fence ) { const u32 msg_id = KBASE_TL_KBASE_KCPUQUEUE_ENQUEUE_FENCE_WAIT; const size_t msg_size = sizeof(msg_id) + sizeof(u64) + sizeof(kcpu_queue) + sizeof(fence) ; char *buffer; unsigned long acq_flags; size_t pos = 0;

  buffer = kbase_tlstream_msgbuf_acquire(stream, msg_size, &acq_flags);

  pos = kbasep_serialize_bytes(buffer, pos, &msg_id, sizeof(msg_id)); pos = kbasep_serialize_timestamp(buffer, pos); pos = kbasep_serialize_bytes(buffer, pos, &kcpu_queue, sizeof(kcpu_queue)); pos = kbasep_serialize_bytes(buffer, pos, &fence, sizeof(fence));

  kbase_tlstream_msgbuf_release(stream, acq_flags); }

La preuve de concept de l'exploitation divulgue l'adresse de l'objet `kbase_kcpu_command_queue` en surveillant l'ID de message `KBASE_TL_KBASE_NEW_KCPUQUEUE` qui est dispatché par la fonction `kbasep_kcpu_queue_new` chaque fois qu'un nouvel objet de file d'attente kcpu est alloué.

Google m'a informé que la vulnérabilité a été signalée en mars 2023 et a été assignée [CVE-2023-26083](https://source.android.com/docs/security/bulletin/2023-07-01) dans leur bulletin de sécurité. Néanmoins, j'ai pu reproduire le problème sur les derniers appareils Pixel livrés avec les niveaux de correctif de sécurité (SPL) d'octobre et novembre, indiquant que le correctif n'avait pas été appliqué correctement ou pas du tout. Par la suite, Google a rapidement résolu le problème dans le bulletin de mise à jour de sécurité de décembre sans offrir de crédit, et m'a plus tard informé que le problème était considéré comme un doublon. La justification derrière le fait de qualifier ce problème de doublon reste toutefois discutable.

## Exploitation
---
J'ai donc deux vulnérabilités intéressantes. La première offre une capacité puissante à modifier le contenu de n'importe quelle adresse mémoire noyau alignée sur 16 octets située avant l'adresse du ~buff~ alloué. La seconde vulnérabilité fournit des indications sur les emplacements potentiels des objets dans la mémoire du noyau.