thegaminggallifreyan/liberationplay-cve-2025-24132-airbourne-pocPOC für CVE-2025-24132 (AirBourne). Löst derzeit nur den Überlauf aus und verursacht einen Absturz.
POC für CVE-2025-24132 (AirBourne). Löst derzeit nur den Overflow aus und verursacht einen Absturz.
Um zu versuchen, Root-Zugriff auf die Headunit meines Autos zu erlangen, habe ich alles recherchiert und zusammengestellt, was ich über den AirPlay-Exploit CVE-2025-24132 (genannt Airbourne) gelernt habe, der von Oligo Security entdeckt wurde.
https://www.oligo.security/blog/airborne
Dies ist mein erstes Reverse-Engineering-Projekt. Ich bin da hineingesprungen, ohne jemals einen Debugger benutzt zu haben, mit sehr wenig Linux- und Programmiererfahrung, und ohne jemals MacOS angefasst zu haben, bis ich zur Hälfte in diesem Projekt war. Vielleicht hätte ich mit etwas CTF anfangen sollen ... Na ja. Ich habe in den letzten Monaten immer wieder daran gearbeitet, nur um zu sehen, ob ich es schaffen kann.
Es dauerte mehrere Monate, um eine verwundbare und eine gepatchte Kopie einer Binary zum Diffen zu bekommen, und dann noch einen weiteren Monat, um sie tatsächlich in einem Emulator zum Laufen zu bringen.
Wie sich jedoch herausstellte, ist der verwundbare Code in einem Emulator unmöglich zu erreichen, da er die Kommunikation mit einem physischen MFi-Chip auf dem Logic Board erfordert. Nachdem ich zwei Monate lang gekämpft hatte, weil ich mich fragte, warum ich den Overflow nicht erreichen konnte, und dann das Problem erkannt hatte, konnte ich die Binary ausreichend kannibalisieren, indem ich die Prüfungen auf die MFi-Chip-Antworten herauspatchte und das, was er zurückgegeben hätte, mit Müll füllte. Dadurch konnte ich den Overflow endlich erreichen und genug davon verstehen, um auf einem echten System einen Absturz auszulösen.
Der Overflow befindet sich in der AES-CTR-Verschlüsselungsverarbeitung. Die Größe des in einem SETUP-Paket übergebenen Verschlüsselungsschlüssels wird nicht überprüft und als 16 angenommen, und es wird ein Puffer der Größe 16 erstellt.
Diese Abstürze sind kaum wahrnehmbar, da der Server in der Regel sofort neu startet und sich erneut verbindet, was lediglich einen kurzen Audioausfall oder ein paar Sekunden schwarzen Bildschirm auf einem CarPlay-System zur Folge hat. Ich habe noch nicht herausgefunden, wie sie Speicher leaken, daher ist dies derzeit nur auf Geräten mit deaktiviertem Stack-Schutz praktikabel.
Einen Weg finden, Speicher zu leaken, um den Stack-Schutz zu umgehen.
Dies funktioniert gegen CarPlay-Einheiten oder AirPlay-Einheiten, die keinerlei Autorisierung erfordern. Wenn zuerst eine PIN zum Pairing erforderlich ist, funktioniert dies nicht, da weitere Pairing-Schritte nötig sind, die nicht implementiert sind.
Bei Bluetooth-basierten Geräten kannst du, um den ganzen Mist mit dem Bluetooth-Pairing zu vermeiden, stattdessen einfach eine App wie Pyto herunterladen und das Skript direkt vom Telefon aus ausführen, so wie ich es getan habe. Viel einfacher.
Ich werde hier bekannte gepatchte Geräte ergänzen, sobald ich sie entdecke.
Alle Onyko-AV-Receiver, die AirPlay unterstützen, sollten dafür anfällig sein. Mein Testgerät war ein TX-NR656, das über keinerlei Stack-Schutz verfügt. Creston-DM-NAX-8ZSA-Geräte vor Firmware 3.1 sind verwundbar und besitzen keine Canaries, aber der AirPlay-Prozess läuft in einem Container. Kia-CCNC-Headunits besitzen einen ordnungsgemäßen Stack-Schutz, und bisher ist es mir nicht gelungen, ihn zu überwinden, aber laut Systemprotokollen läuft der carplayserver als root.
