- tachy0n ist ein veröffentlichter Fall eines modernen 0day-Jailbreak-Exploits für iOS 13.0~13.5
- Der Bug ist eine Race Condition im
lio_listio-Systemaufruf namens Lightspeed und nutzt eine Kernel-LPE-Schwachstelle (Privilege Escalation) aus
- Mehrere Jailbreak-Projekte wie Spice und unc0ver haben diese Schwachstelle tatsächlich eingesetzt; beschrieben werden die Exploit-Methode sowie Hacking-Techniken rund um Speicherverwaltungsprobleme
- Nach der Veröffentlichung dieses Exploits führte Apple Patches und Regressionstests ein und verstärkte zugleich deutlich die Isolierung von Kernel-Objekten (Zone,
kheap usw.) sowie Pointer-Schutzfunktionen
- Seit iOS 14 hat sich die Umgebung für Jailbreaks und Kernel-Exploits grundlegend verändert; öffentlich verfügbare Kernel-Exploits existieren inzwischen nicht mehr
0. Einleitung
- tachy0n ist ein älterer Exploit, der für iOS 13.0 bis 13.5 gilt
- Am 23. Mai 2020 wurde er als 0day in unc0ver v5.0.0 veröffentlicht, und Apple spielte bereits nach nur einer Woche einen Notfall-Patch ein
- Die betreffende Schwachstelle war zuvor bereits als 1day im Einsatz, weshalb sie auch aus Sicht der Exploit-Technik als bedeutender Fall gilt
- Der Text erläutert detailliert die Quelle der Schwachstelle und wie sie entdeckt wurde
1. Lightspeed
- Die Schwachstelle ist der von Synacktiv vorgestellte Lightspeed-Bug (CVE-2020-9859 usw.); beim Freigeben des asynchronen I/O-Kontextspeichers im
lio_listio-Syscall tritt ein Race-Condition-Problem auf
- Um eine Double-Free-Bedingung im Speicher zu erzeugen, wird das Timing der I/O-Operationen angepasst; über zwei Objekt-Freigaben lassen sich mehrere Objekte im selben Speicherbereich überlagern und ausnutzen
- Dabei wird die dynamische Speicherallokationsstruktur der
kalloc.16-Zone des Kernels für den Exploit verwendet
- Im Kern handelt es sich um eine Methode, die die Race-Bedingung vielfach wiederholt, um die Erfolgswahrscheinlichkeit zu erhöhen
2. Spice
- Dieser Exploit wurde früher im Jailbreak Spice von team Jake Blair verwendet
- In racoon und in der App wurden unterschiedliche Exploit-Varianten implementiert; das Hauptziel war die Fälschung von Mach-Ports
- Unter iOS 11.x ließ sich PAN (Protection Against Null dereference) damals leicht umgehen; außerdem wurden verschiedene Hacking-Techniken in Kombination mit Kernel-Infoleaks und Sandbox-Escapes ausprobiert
- Im Fall von racoon wurden wegen IOKit-Zugriffsbeschränkungen mit
OSUnserializeXML Objekte für das gezielte Besprühen der betreffenden Kernel-Zone erzeugt
- Auch Details wie sysctl_procargsx, nicht initialisierte Speicherlecks im Kernel, Sandbox-Richtlinien und die anschließende technische Weiterentwicklung werden beschrieben
3. unc0ver
- Zur Zeit der Integration in unc0ver wurde die Exploit-Struktur so entworfen, dass sie auf einer breiten SoC-Palette einschließlich A8 bis A13 funktioniert
- Das Überlagern und Nachverfolgen von OSData-Objekten sowie das Freigeben bzw. Allokieren gewünschter Objekte zum richtigen Zeitpunkt dienten dazu, den Speicherbereich zu kontrollieren
- Mithilfe von Kernel-Objekten wie
IOMemoryDescriptor werden Adressen benutzerkontrollierter Datenpuffer offengelegt und direktes Lesen/Schreiben im Kernel umgesetzt
- Schwächen in den Richtlinien des Kernel-Speicherallokators unter iOS 13, etwa zur Umgehung von zone_require, werden gezielt ausgenutzt
- Die vollständige Exploit-Struktur lässt sich im veröffentlichten GitHub-Repository (tachy0n) im Detail nachvollziehen
4. Nachwirkungen
- Die Veröffentlichung des 0day-Exploits sorgte in der Security-Community und bei Apple für großes Aufsehen
- Bereits 4 Stunden nach der Veröffentlichung des realen Exploits erfolgten bei Project Zero und Synacktiv detaillierte Analysen und Gegenmaßnahmen
- Nach dem Patch fügte Apple in XNU unter anderem offizielle Regressionstests für diese Schwachstelle hinzu und wechselte damit zu einer Linie der grundsätzlichen Stärkung der Sicherheitsstrategie
- Ab iOS 14 wurden umfassende Änderungen eingeführt, die die Entwicklung von Exploits deutlich erschweren, darunter die Trennung von Allokationsbereichen, Object Secure Guard, PAC (Pointer Authentication Code) und die
kheap-Struktur
- Heute ist die Exploit-Strategie selbst wichtiger geworden, und die Lücke zwischen öffentlichen Informationen und nicht öffentlicher Forschung ist größer; für iOS 17~18 gibt es faktisch überhaupt keine öffentlichen Kernel-Exploits mehr
5. Fazit
- Dies ist ein Fall, der klar zeigt, wie sich der Bereich iOS-Sicherheit/Jailbreaks innerhalb von 5 Jahren dramatisch verändert hat
- Er bietet Einblicke darin, wie sich die technische Ausrichtung der Jailbreak-/Exploit-Community, der Forschenden und von Apple verändert hat
- Die Zeit, in der man IL teilte und Herausforderungen gemeinsam anging, ist inzwischen Vergangenheit; seit iOS 14 ist der Austausch von Exploit-Informationen deutlich zurückgegangen
Referenzen und Kontakt
2 Kommentare
Apples Hardware ist zwar hervorragend, aber die Software ist voller Absichten, die Nutzer an die Leine zu legen.
Selbst wenn man eine selbst erstellte und gebaute App nur auf dem eigenen Gerät ausführen will, braucht man ein 100-Dollar-Abo.
Wenn man als Entwickler kleinere bis mittelgroße Open-Source-Apps nutzt, sie selbst baut und verwendet,
ist es bequemer, einfach Android zu nutzen, als auf Apple-Geräten Schwachstellen auszunutzen, sie zu jailbreaken und per Sideloading Apps zu installieren.
Hacker-News-Kommentare
Es wird erwähnt, dass SockPuppet schon früher für einen Jailbreak zu iOS 12 verwendet wurde und nach einer Meldung von Project Zeros Ned Williamson an Apple in iOS 12.3 gepatcht wurde, dann aber in iOS 12.4 erneut auftauchte
Wahrscheinlich hatte Apple XNU in einen separaten Branch geforkt und diesen Patch dabei übersehen; das grundlegende Problem sei vor allem das völlige Fehlen von Regressionstests für solche neuen und alten Schwachstellen
Ich habe selbst nur einige bekannte 1-Day-Schwachstellen per Regressionstest automatisiert und laufen lassen und sofort erfolgreich Schwachstellen gefunden
Ich frage mich, ob auch verschiedene Open-Source-Projekte wie Linux, FreeBSD, OpenWRT und OpenSSH bei neuen Versionen Regressionstests für alte Schwachstellen ausführen
Wenn man jede Schwachstelle automatisiert beschreibt und in der CI die nötigen Ressourcen investieren kann, dürfte der Nutzen groß genug sein
Es wird die Erfahrung geteilt, vor 20 Jahren während des Studiums bei Mozilla ehrenamtlich in der QA gearbeitet zu haben, wo es Hunderte von Regressionstestfällen gab
Meist ging es um Rendering-/Layout- und JS-Engine-Bugs; wenn man einen minimierten Testfall erstellt, kann er direkt der CI-Pipeline hinzugefügt werden
Bugs selbst lassen sich nicht vermeiden, aber wenn bereits behobene Bugs wieder auftauchen, ist das die schlimmste Verschwendung von Zeit und Geld; Organisationen, denen Qualität wichtig ist, investieren deshalb zwangsläufig stark in Regressionstests
Leider gibt es auch viele Organisationen, die QA ignorieren oder nur per Outsourcing abdecken und sich nicht ernsthaft darum kümmern
Dass Apple in Bezug auf Jailbreaks keine Regressionstests hatte, ist schwer nachvollziehbar
Schon früher hätten etwa Mozilla mit Tools wie Tinderbox und Bugzilla hervorragende QA- und CI/CD-Umgebungen aufgebaut, und man habe gedacht, solche Arbeitsweisen seien schon vor dem Aufkommen des DevOps-Begriffs allgemein üblich gewesen – erst später sei klar geworden, dass das nicht so war
Es habe Tausende von Testfällen gegeben, vermutlich sei es Sqlite gewesen
Wenn man Patches nicht backportet, ist die Wahrscheinlichkeit hoch, dass auch die zugehörigen Tests nicht mit backportet werden
Letztlich gelte Conway’s Law genauso zwischen Security und Feature-Entwicklung
Daher besteht selbst in Organisationen mit guten Regressionstests im Build-/Release-Prozess wegen der internen Struktur eine hohe Wahrscheinlichkeit, dass sicherheitsbezogene Themen herausfallen
wird die Meinung geäußert, dass Geheimdienste (G10, Russland, China, Nordkorea usw.) und viele private Gruppen selbstverständlich auf diese Weise Regressionstests für Schwachstellen durchführen dürften
wird die Situation damit verglichen, sich mit einem Freund in einer Fremdsprache zu unterhalten und im nächsten Moment plötzlich zu einem hochspezialisierten Thema wie Gehirnchirurgie oder Kernphysik zu wechseln, sodass der Kopf völlig leer wird
Es erinnert an eine frühere Erfahrung, ein Gespräch über die Reparatur eines Stahlwerks dolmetschen zu wollen
Es ist schade, dass Jailbreaks praktisch verschwunden sind; zwar habe ich ein gejailbreaktes iPad nicht besonders nützlich eingesetzt, aber allein daran Spaß gehabt
Heute würde ich gern eine Tethering-App oder UTM bzw. eine JIT-Lösung installieren
SideStore wirkt vielversprechend und ich würde es gern ausprobieren, aber mein Apple-Account war früher ein kostenpflichtiger Entwickleraccount, und weil 10 App-IDs noch nicht abgelaufen sind, gibt es Einschränkungen bei der Installation solcher Apps
Möglich wäre es nur mit einem neuen Account oder wenn ich erneut bezahle
Ohne Jailbreak gab es für mich überhaupt keinen Grund, ein iPhone als Haupttelefon zu verwenden, und letztlich bin ich zu Android gewechselt
Damals hatte Android bei den Grundfunktionen stark aufgeholt
Ob man über einen Zwischenbroker gehen muss, ob es eine offizielle E-Mail-Adresse oder Anlaufstelle gibt und ob die Gefahr besteht, einfach im First-Level-Support unterzugehen
Wie im Artikel erwähnt, besitzen private Communities weiterhin Schwachstellen, und Apple patcht sie weiter
Nur öffentlich verfügbare Jailbreaks sind seltener geworden