thegaminggallifreyan/liberationplay-cve-2025-24132-airbourne-pocPOC pour CVE-2025-24132 (AirBourne). Actuellement, déclenche simplement le débordement et provoque un crash.
POC pour CVE-2025-24132 (AirBourne). Déclenche actuellement le débordement et provoque un crash
Dans le but d’essayer d’obtenir un accès root à l’unité centrale de ma voiture, j’ai recherché et compilé tout ce que j’ai appris sur l’exploit AirPlay CVE-2025-24132 (nommé Airborne) découvert par Oligo Security.
https://www.oligo.security/blog/airborne
C’est mon premier projet de rétro-ingénierie. Je m’y suis lancé sans avoir jamais utilisé de débogueur, avec très peu d’expérience en Linux et en programmation, et sans avoir jamais touché à MacOS jusqu’à la moitié de ce projet. J’aurais peut-être dû commencer par un CTF… Tant pis. J’ai travaillé dessus par intermittence ces derniers mois juste pour voir si j’y arriverais.
Il m’a fallu plusieurs mois pour obtenir une copie vulnérable et une copie corrigée du binaire à comparer, puis encore un mois pour les faire fonctionner dans un émulateur.
Mais il s’avère que le code vulnérable est impossible à atteindre dans un émulateur, car il nécessite une communication avec une puce MFi physique sur la carte logique. Après avoir lutté pendant 2 mois, me demandant pourquoi je n’arrivais pas au débordement, puis en réalisant le problème, j’ai pu cannibaliser suffisamment le binaire en supprimant les vérifications des réponses de la puce MFi et en remplissant ce qu’elle aurait retourné avec des déchets. Cela m’a enfin permis d’atteindre le débordement et d’en comprendre assez pour provoquer un crash sur un système réel.
Le débordement se situe dans la gestion du chiffrement AES CTR. La taille de la clé de chiffrement transmise dans un paquet SETUP n’est pas vérifiée et est supposée être de 16, et un tampon de 16 est créé.
Ces crashs sont à peine perceptibles, car le serveur redémarre et se reconnecte généralement immédiatement, ce qui entraîne juste une brève perte audio ou quelques secondes d’écran noir sur un système CarPlay. Je n’ai pas encore réussi à comprendre comment ils fuient la mémoire, donc cette attaque n’est actuellement viable que sur des appareils dont les protections de pile sont désactivées.
Trouver un moyen de fuiter la mémoire pour contourner les protections de pile.
Cela fonctionne contre les unités CarPlay ou AirPlay qui ne nécessitent aucun type d’autorisation. Si un code PIN est requis pour l’appairage préalable, cela ne fonctionnera pas car il y a plus d’étapes d’appairage impliquées qui ne sont pas implémentées.
Pour les appareils Bluetooth, afin d’éviter de devoir gérer tout le bazar de l’appairage Bluetooth, vous pouvez simplement télécharger une application comme Pyto et exécuter le script directement depuis le téléphone, comme je l’ai fait. Beaucoup plus simple.
J’ajouterai ici les appareils corrigés connus au fur et à mesure que je les découvre.
Tous les récepteurs AV Onkyo prenant en charge AirPlay devraient être vulnérables à cela. Mon unité de test est un TX-NR656 qui n’a aucune protection de pile. Les unités Crestron DM-NAX-8ZSA avant le firmware 3.1 sont vulnérables et n’ont pas de canaris, mais le processus AirPlay s’exécute dans un conteneur. Les unités principales Kia CCNC ont une protection de pile adéquate et jusqu’à présent je n’ai pas réussi à la contourner, mais selon les journaux système, le carplayserver s’exécute en tant que root.
