Examinons la fonction avant le patch (j'ai essayé d'annoter les lignes pertinentes) :

• La boucle [1] compte le nombre de IOHIDElementValues dans le tampon et stocke ce compte dans cookieCount.
• La vérification [2] (combinée à la condition de la boucle while) garantit que le champ length de chaque en-tête ne dépasse pas les limites du tampon elementData (et ne s'arrête pas non plus avant la fin du tampon, bien que cela soit moins pertinent).
• Une fois que tous les éléments ont été comptés et validés par cette boucle, un tampon cookies est alloué sur le tas en [3] avec une taille de cookieCount * 4 (ou un tampon sur la pile est utilisé si cookieCount est suffisamment petit).
• Une seconde boucle en [4] effectue ensuite un deuxième passage dans le tampon, analysant à nouveau les IOHIDElementValues.
• Des objets OSData sont créés pour contenir la valeur de chaque élément en [5], utilisant le champ length validé dans la première boucle.
• En [6], le cookie de chaque élément est écrit dans le tableau cookies alloué en [3].

Quel est donc le problème ? Cette fonction se comporte parfaitement correctement lorsque elementData n'est pas volatil ; le problème survient lorsque la méthode est appelée avec de la mémoire partagée. Voici la méthode DriverKit IOHIDInterface::SetElementValues_Impl :

Ici, postElementTransaction est appelée avec md->getBytesNoCopy(), une mémoire partagée avec l'espace utilisateur, ce qui viole l'hypothèse selon laquelle elementData n'est pas volatil. Le contenu du tampon elementData peut changer après la boucle [1], mais avant la boucle [4]. Qu'est-ce que cela signifie pour un attaquant ?

Un attaquant peut abuser de cela de deux manières :

• La première consiste à remplacer le length d'un petit IOHIDElementValueHeader à la fin du tampon par une valeur beaucoup plus grande. Cela signifie que lorsque OSData est créé en [5], il s'étendra bien au-delà des limites du tampon elementData, permettant à un attaquant de lire des données hors limites à l'aide de IOHIDInterface::GetElementValues_Impl.
• La seconde consiste à remplacer le length d'un grand IOHIDElementValueHeader au début du tampon par une valeur beaucoup plus petite. Cela fera analyser par la boucle [4] beaucoup plus d'en-têtes que ceux comptés initialement dans la boucle [1], de sorte que lorsque les cookies sont écrits dans le tableau cookies en [6], ils déborderont du tableau car index n'est jamais validé par rapport à cookieCount.

En pratique, cela permet à un attaquant de lire des données hors limites du tas du noyau d'une taille arbitraire, et d'écrire des données arbitraires (également d'une taille arbitraire) hors limites dans le tas du noyau. Ce sont deux primitives puissantes.

Gagner la course

Avec les conditions de course, nous cherchons toujours des moyens de déterminer si la course a été gagnée avec succès, afin de pouvoir réessayer jusqu'à réussir, rendant notre déclencheur déterministe. Heureusement, dans le cas de cette condition de course, nous pouvons faire exactement cela.

Pour la variante de lecture OOB, je place un IOHIDElementValueHeader supplémentaire après l'en-tête dont je modifie le length, avec sa value définie sur la constante reconnaissable 0xD1AB011CAC1DF00D. Ensuite, lorsque je relis la valeur de l'élément, je sais que j'ai gagné la course si je vois l'en-tête familier 0xD1AB011CAC1DF00D au début des données renvoyées.

Pour la variante d'écriture OOB, je place un IOHIDElementValueHeader après l'en-tête dont je modifie le length, mais avant les en-têtes dont les cookies seront débordés, cette fois avec la value reconnaissable 0xD15EA5ED. Cet en-tête sera encapsulé à l'intérieur de la value de l'élément plus grand dans le cas où nous ne gagnons pas la course, de sorte que l'en-tête ne sera analysé et que la valeur de l'élément ne sera définie sur 0xD15EA5ED que si nous gagnons la course. En relisant la valeur de l'élément, je sais si j'ai réussi.

Le correctif d'Apple

Pour corriger le problème, Apple a choisi d'ajouter une troisième boucle entre la boucle [1] et la boucle [4], validant chaque champ length, puis le mettant en cache dans un nouveau tableau dataLengths, tout en s'assurant que le nombre d'éléments n'avait pas changé. La boucle finale utilise ensuite les longueurs mises en cache pour ses calculs, évitant ainsi de lire à nouveau le tampon.

Problèmes liés à l'exploitation

Le principal obstacle à surmonter lors de l'exploitation de ce problème est que le tampon depuis lequel nous débordons appartient à KHEAP_DATA_BUFFERS, les cibles d'exploitation sont donc limitées. Dans ce proof-of-concept, j'ai choisi de cibler les en-têtes kmsg, car ce sont l'une des rares structures de KHEAP_DATA_BUFFERS contenant des pointeurs du noyau. La primitive « arbitrary kfree » que j'ai obtenue avec cette approche est la même que celle utilisée dans l'exploit multicast_bytecopy. Cependant, le tableau IOSurfaceClient est désormais protégé par PAC et les clients forgés doivent avoir un pointeur valide vers le IOSurfaceRootUserClient qui les a créés, ce qui en fait une cible de lecture/écriture noyau moins intéressante.

Compilation et installation

Apple n'a pas rendu la compilation et l'installation d'extensions DriverKit personnalisées très faciles, surtout sans compte développeur Apple payant, mais c'est possible.

Avant de commencer, je recommande :

• Désactiver SIP
• Définir les boot-args amfi_get_out_of_my_way=1 cs_enforcement_disable=1
• Exécuter systemextensionsctl developer on
• Redémarrer votre ordinateur

Après cela, vous devriez pouvoir sélectionner votre équipe de développement dans les paramètres du projet Xcode et le projet se compilera avec succès. Vous pouvez ensuite exécuter HIDDriverLoader, utiliser « Install Dext » pour installer l'extension DriverKit et « Trigger Exploit » pour, vous l'aurez deviné, déclencher l'exploit.

Si cela échoue, vous pouvez également essayer de compiler sans signature en utilisant :

Puis en signant manuellement à l'aide de :

Remplacez self-sign-cert par le nom d'un certificat auto-signé dans votre trousseau.

Merci de votre lecture :)