Der letzte 0day-Jailbreak: Tachy0n

 (blog.siguza.net)
1 Punkte von GN⁺ 2025-05-25 | 2 Kommentare | Auf WhatsApp teilen
  • tachy0n war ein Kernel-Privilege-Escalation-Exploit, der unter iOS 13.0 bis 13.5 funktionierte. Er wurde am 23. Mai 2020 als 0day in unc0ver v5.0.0 aufgenommen und zielte damit direkt auf die damals aktuelle iOS-Version ab.
  • Kern war die Lightspeed-Race-Condition in lio_listio, durch die ein kalloc.16-Objekt zweimal freigegeben werden konnte, sodass zwei unterschiedliche Objekte auf denselben Speicher zeigten.
  • Ein Bug derselben Familie wurde zuvor bereits im Spice-Jailbreak/Untether für iOS 11 verwendet, doch App-Sandbox und racoon-Umgebung unterschieden sich stark bei Berechtigungen, Sandbox und Spray-Techniken.
  • Der Exploit für unc0ver beschaffte wiederholt überlappende OSData-Objekte und nutzte IOBufferMemoryDescriptor sowie IOAcceleratorFamily2, um einen fake task und einen fake mach port aufzubauen.
  • Seit iOS 14 ist Apple dazu übergegangen, durch getrennte Allocator, Sequestering, PAC und objektbezogene Härtungen die Exploit-Strategien selbst zu blockieren. Öffentliches Wissen über iOS-Kernel-Exploits liegt heute deutlich hinter dem Stand der iOS-13-Zeit zurück.

Warum die Veröffentlichung von tachy0n ungewöhnlich war

  • tachy0n ist ein älterer Exploit, der iOS 13.0 bis 13.5 betraf und am 23. Mai 2020 mit unc0ver v5.0.0 öffentlich wurde.
  • Nach damaligem Maßstab war es eine typische lokale Kernel-Rechteausweitung (kernel LPE), ungewöhnlich war aber, dass sie als 0day-Jailbreak veröffentlicht wurde, der die aktuelle iOS-Version betraf.
  • Apple veröffentlichte etwa eine Woche nach der Exploit-Veröffentlichung einen Patch, der nur diesen Bug adressierte.
  • In iOS 13.5 war der Bug ein 0day, zuvor war er jedoch bereits in Form eines 1day ausgenutzt worden.
  • Pwn20wnd suchte nach einem aus der App-Sandbox erreichbaren 0day; Ausgangspunkt waren Regressionstests für bekannte 1days.
    • SockPuppet aus iOS 12 wurde in iOS 12.3 gepatcht, tauchte aber in iOS 12.4 wieder auf.
    • Dieser Fall zeigte, dass Apple für diese Art von Bugs keine Regressionstests hatte, und Pwn20wnd implementierte Regressionstests für mehrere bekannte 1days und erzielte dabei einen Treffer.

Lightspeed: die Race-Condition in lio_listio

  • Der Kernbug von tachy0n ist Synacktivs Lightspeed-Bug und steht mit CVE-2020-9859 sowie möglicherweise CVE-2018-4344 in Verbindung.
  • Die Schwachstelle liegt im Syscall lio_listio, der asynchrones oder gebündeltes Datei-I/O ausführt.
  • Der Kernel allokiert eine aio_lio_context-Struktur, um die eingereichten I/O-Aufgaben zu verfolgen.
    • Die Struktur enthält die Felder io_waiter, io_issued und io_completed.
  • Die eigentliche Arbeit läuft in separaten Threads, und sobald alle I/O-Vorgänge abgeschlossen sind, gibt do_aio_completion diesen Kontext frei.
  • Wenn keine Aufgabe geplant wurde, muss der aktuelle Thread von lio_listio den Kontext freigeben.
  • Das Problem ist, dass diese Prüfung eine Race-Condition enthält.
    • Eine Aufgabe kann an einen anderen Thread übergeben worden sein, aber bereits vor dem Prüfzeitpunkt abgeschlossen sein, sodass der Kontext freigegeben wurde.
    • In diesem Fall prüft lio_listio den inzwischen zum Dangling Pointer gewordenen lio_context erneut.

Wie der Double Free zum Exploit führt

  • Die für den Exploit nötige Abfolge sieht so aus:
    • lio_listio allokiert einen lio_context.
    • Die Aufgabe wird abgeschlossen und do_aio_completion gibt den lio_context frei.
    • Der freigegebene Speicher wird als vom Angreifer kontrolliertes Objekt neu allokiert und so gestaltet, dass es wie lio_context->io_issued == 0 aussieht.
    • lio_listio sieht das und gibt das Angreiferobjekt erneut frei.
    • Derselbe Speicher wird als weiteres Objekt neu allokiert, sodass zwei verschiedene Allokationen auf denselben Speicher zeigen.
  • Auf 64-Bit-Geräten landet lio_context in der kleinsten Zone, kalloc.16.
  • Vor iOS 14 teilten sich Objekte unabhängig von ihrem Typ dieselbe Allocation Site nach Größenklassen.
    • C++-Objekte, Pointer-Arrays und vom Nutzer bereitgestellte Datenpuffer konnten innerhalb desselben Größen-Buckets gegenseitig ihren Speicher wiederverwenden.
  • Dieser Double Free verhält sich anders als ein gewöhnlicher Double Free, der ohne Zwischenallokation schnell in einen fatalen Zustand führt.
    • lio_context->io_issued ist während der Allokation nie 0.
    • Nach der Freigabe überschreibt der Allocator die ersten 8 Bytes mit einem Canary-Wert und einem Freelist-Pointer oder mit einem XOR-Wert der Objektadresse.
    • Deshalb tritt die zweite Freigabe nur dann auf, wenn es dazwischen eine Neuallokation gibt und die Bytes 4 bis 7 0 sind.
  • Der tatsächliche Exploit konnte dieses Race mehrfach wiederholen; dass andere Systemobjekte zufällig die nötigen Bytes auf 0 setzen und so den Double Free auslösen, war in der Praxis selten.

Frühere Nutzung in Spice

  • Derselbe Bug wurde auch im Spice-Jailbreak/Untether für iOS 11.x verwendet.
  • Spice wurde von Jake Blairs Team zusammen mit Sparkey und littlelailo entwickelt; die damals aktuelle Version war iOS 13.x.
  • Ziel war es, sowohl in der App-Umgebung als auch in der racoon-Umgebung mach port forgery zu erzeugen.
    • Bei Kernel-Exploits vor iOS 14 wurde die weitere Ausnutzung entscheidend einfacher, sobald man den Kernel dazu bringen konnte, einen vom Nutzer bereitgestellten Wert als mach-port-Pointer zu interpretieren.
  • Der grundlegende Ablauf, um mit Lightspeed mach port forgery zu erzeugen, war:
    • die erste Freigabe von lio_context auslösen;
    • eine mach message mit einem OOL mach ports descriptor der Größe 1 oder 2 sprayen;
    • den ersten Eintrag auf MACH_PORT_NULL setzen, damit er in kalloc.16 landet und io_issued wie 0 aussieht;
    • durch die zweite Freigabe das OOL-mach-ports-Array freigeben;
    • kontrollierte Daten in kalloc.16 sprayen und so das mach-ports-Array durch einen fake pointer ersetzen.

Unterschiedliche Einschränkungen von App-Sandbox und racoon

  • Auf A7 bis A9(X) gab es kein PAN, sodass sich Userland-Adressen allein mit mmap und mlock wie Kernel-Pointer dereferenzieren ließen.
  • A10 und A11 sollten ebenfalls unterstützt werden, aber in der App-Sandbox fanden sich weder ein passender Leak für Kernel-Adressen noch ein Ziel, um kontrollierte Daten zu platzieren; daher wurde dies nicht fertiggestellt.
  • Zu den 1days, die genutzt werden sollten, gehörten Ian Beers Kernel-Stack-Informationsleck und ein Sandbox-Escape über backboardd.
    • Der Plan war, Shared-Memory-Pointer zu leaken oder Daten im Kernel-__DATA-Segment zu platzieren.
    • Da kein geeignetes Target gefunden wurde, kam A10/A11-Support über den App-Pfad nicht zustande.
  • Der racoon-Pfad hatte andere Bedingungen.
    • Er läuft als root, hat aber eine strengere Sandbox als normale Apps.
    • Es gab keinen Zugriff auf IOSurface, daher war der übliche OSUnserializeXML-Spray über IOSurface::setValue nicht nutzbar.
    • Stattdessen ließ sich der OSUnserializeXML-Aufruf in RootDomainUserClient::secureSleepSystemOptions verwenden, um einige Objekte in Leak-Form zu sprayen.
  • racoon hatte ein Sandbox-Profil, das alle sysctl-Lese- und Schreibzugriffe erlaubte, und lief außerdem mit root-Rechten.
    • Wenn der Kernel-Slide bekannt war, ließ sich ein sysctl-Global im Kernel-__DATA als Datenspeicher an einer bekannten Adresse verwenden.
    • In Spice wurde vm.swapfileprefix gewählt.
  • Zur Ermittlung des Kernel-Slides wurde panicalls CVE-2018-4413 verwendet.
    • Ein Informationsleck in sysctl_procargsx konnte fast eine ganze Page uninitialisierten Kernel-Speichers aus kernel_map leaken.
    • Dadurch ließen sich Kernel-Code- und Heap-Pointer erhalten und A7 bis A11 abdecken.
    • In der App-Sandbox war sysctl_procargsx blockiert, sodass derselbe Ansatz nicht möglich war.

Aufbau des tachy0n-Exploits für unc0ver

  • Ziel von unc0ver waren A8 bis A13, weshalb man A10+ nicht ignorieren und sich nicht auf Userland-Dereferenzierung verlassen konnte.
  • Der Exploit wurde wegen der potenziell fehlschlagenden Memory-Corruption-Schritte als zweischichtige Struktur entworfen.
    • Die untere Schicht startet freerer-Threads, die lio_listio aufrufen, und racer-Threads, die über IOSurface OSData deserialisieren.
    • Standardmäßig gibt es 4 freerer und 16 racer, konfigurierbar.
  • Die über IOSurface deserialisierten Daten waren ein OSDictionary mit mehreren OSData-Einträgen.
    • Die Position, die io_issued entspricht, musste 0 sein.
    • Magic Values wie 0x41414141 und 0x69696969 sowie der Schlüsselwert k wurden zur Erkennung von Overlaps verwendet.
  • Nach dem Race werden alle OSData-Werte geprüft.
    • Objekte, deren Magic Value verändert wurde, gelten als von einem anderen Systemobjekt übernommen und werden später zur Bereinigung markiert.
    • Wenn der Schlüssel und der k-Wert im Buffer voneinander abweichen, wird angenommen, dass ein Overlap vorliegt, bei dem ein anderes OSData-Objekt auf denselben Backing Buffer zeigt.
  • Die Funktionen maybe_reyoink und overlap im Code bauen diese Overlap-Informationen auf und geben sie an die obere Schicht weiter.
  • Die obere Schicht verwendet die überlappenden OSData-Objekte, um einen fake mach port zu konstruieren.
    • Ein OSData wird freigegeben.
    • Eine mach message mit OOL-port descriptor wird gesprayt.
    • Ein anderes OSData wird freigegeben.
    • Es wird als neues OSData mit einem Pointer auf einen fake task port neu allokiert.

Kontrollierte Daten an einer bekannten Kernel-Adresse platzieren

  • Der Exploit konnte Inhalte, die als OOL-ports-descriptor-Array neu allokiert wurden, als OSData lesen und so rohe Kernel-Pointer von mach ports leaken.
  • In späteren Schritten wurde das genutzt, um die Adressen eines task port und des IOSurfaceRoot-Service-Ports zu leaken; das Kernproblem war aber, die Kernel-Adresse eines kontrollierbaren Buffers zuverlässig zu erhalten.
  • Ein in den XNU-Quellen gefundener Kandidat war IOMemoryDescriptor.
    • Das Feld _ranges ist ein Array von IOVirtualRange; ein einzelner IOVirtualRange passt exakt in kalloc.16.
    • Ein gewöhnlicher IOMemoryDescriptor verwendet bei nur einer Range allerdings _singleRange statt einer Heap-Allokation.
  • IOBufferMemoryDescriptor ist eine Ausnahme und ruft für eine einzelne Range IONew(IOAddressRange, 1) auf, wodurch eine Heap-Allokation erfolgt.
  • Eine praktische Stelle, um dies beliebig zu allokieren und in den Nutzeradressraum zu mappen, war das AGX-Interface von IOAcceleratorFamily2.
    • Öffnet man in IOGraphicsAccelerator2 einen Userclient vom Typ 0, erhält man IOAccelContext2.
    • Über ::clientMemoryForType() lassen sich drei memory descriptor mappen.
    • Typ 0 ist 0x8000 Bytes groß und wurde zur Identifikation des victim descriptor verwendet.
  • Der Exploit nutzt folgende Schleife:
    • IOAccelContext2 öffnen und zwei überlappende OSData erhalten;
    • ein OSData freigeben;
    • den zuvor geöffneten IOAccelSharedUserClient2 per IOConnectAddClient() verbinden;
    • das verbleibende OSData lesen und prüfen, ob die ersten 8 Bytes ein page-aligned Kernel-Pointer sind und die nächsten 8 Bytes 0x8000 betragen;
    • falls die Bedingungen nicht passen, IOAccelContext2 schließen und wiederholen.

Pageable Memory, fake port, zone_require

  • Nachdem der memory descriptor in den Prozess gemappt und die Kernel-Adresse ermittelt war, blieb das Problem, dass der Speicher als kIOMemoryPageable erzeugt wurde.
  • Da auf fake mach port und fake task object in Situationen zugegriffen werden kann, in denen Preemption deaktiviert ist, musste der Kernel die betreffende Page faulten.
  • Das wurde gelöst, indem external method 2 von IOAccelContext2::submit_data_buffers, die indirekt IOAccelContext2::processSidebandBuffer aufruft, zweimal aufgerufen wurde.
    • Sie liest eine Struktur 0x10 Bytes nach Beginn des Shared Memory.
    • Die erste Struktur hat tok == 0x100 und ist so aufgebaut, dass sie die gesamte Page abdeckt und zur zweiten Page weitergeht.
    • Auf der zweiten Page können anschließend die Daten für fake objects liegen.
  • Die nächsten Schritte führen zu fake task, fake port, einem OOL-descriptor switcheroo und dem Aufbau eines Primitives für beliebiges Lesen.
  • Auch ein Bypass von zone_require war nötig.
    • Damals erlaubte zone_require Pages außerhalb von zone_map und interpretierte die ersten 0x20 Bytes einer Page als Metadaten.
    • Mit dem richtigen Zone-Index konnte man dies wie eine Zugangsberechtigung für die gewünschte Zone verwenden.
    • Deshalb waren zwei Pages nötig: eine für task und eine für mach port.
  • Dieser Exploit ist inzwischen auf GitHub veröffentlicht.

Analyse und Patch nach der Veröffentlichung

  • Die Veröffentlichung eines vollständigen 0day-Exploits gegen die aktuell signierte Version zog die Aufmerksamkeit der iOS-Jailbreak-Szene auf sich.
  • Brandon Azad, damals bei Project Zero, identifizierte die Schwachstelle innerhalb von 4 Stunden nach der Exploit-Veröffentlichung und informierte Apple.
  • 6 Tage nach der Exploit-Veröffentlichung behandelte Synacktiv in einem neuen Artikel, dass der ursprüngliche Fix in iOS 12 ein Memory Leak erzeugt hatte und dass der Versuch, dieses Memory Leak zu beheben, wahrscheinlich den ursprünglichen Bug wiederbelebte.
  • 9 Tage nach der Exploit-Veröffentlichung stellte Apple einen Patch bereit.
  • Später wurde XNU ein Regressionstest für diesen Bug hinzugefügt.
  • 54 Tage nach der Veröffentlichung wurde eine reverse-engineered Version namens „tardy0n“ in den Odyssey-Jailbreak aufgenommen, ebenfalls für iOS 13.0 bis 13.5.

Die veränderte Exploit-Landschaft seit iOS 14

  • iOS 14 zeigt den Strategiewechsel bei Apples Kernel-Sicherheit.
  • Vor iOS 14 war das nächste Ziel nach einem ersten Primitive meist ein mach port, egal ob die Ausgangslage Heap Overflow, C++-Objekt-Over-Release, Type Confusion oder etwas anderes war.
  • Eine der größten Änderungen in iOS 14 betraf die Allocator kalloc und zalloc.
    • Die zone map wurde in mehrere „kheap“-Bereiche aufgeteilt.
    • Von Nutzern kontrollierte Daten und Kernel-Objekte wurden getrennt in unterschiedliche Heaps gelegt.
    • Auf Kernel-Objekte wurde Sequestering angewendet, sodass Virtual-Address-Pages, die einer bestimmten Zone zugewiesen sind, bis zum Neustart nicht für eine andere Zone wiederverwendet werden.
    • Physischer Speicher kann freigegeben werden, aber der virtuelle Speicherbereich wird nicht für andere Objekte wiederverwendet, was Kernel-Objekt-Type-Confusion praktisch verhindert.
  • Guard Pages, pro Boot variierende Startpositionen der Zone-Allokation und spätere Verfeinerungen senkten die Zuverlässigkeit von Cross-Zone-Angriffen deutlich.
  • Apple wechselte von der bloßen Blockade einzelner Bugs zu einem Ansatz, der Exploit-Strategien blockiert.
    • Wenn ein Exploit eine kmsg struct als Corruption Target verwendet, wird diese Struktur signiert.
    • Wenn ein pipe buffer als stabile Kernel-Lese-/Schreibschnittstelle genutzt wird, werden die zugehörigen Pointer unter PAC gestellt.
    • Wenn eine Technik auftaucht, die ein eigentlich unbeteiligtes Objekt als victim nutzt, wird dieser Objekttyp gehärtet.
  • In der Folge wurde bei der Exploit-Entwicklung die Exploit-Strategie wertvoller als der initiale Memory-Corruption-0day.

Bruch im öffentlichen Wissen

  • Für die Zeit vor iOS 14 wird eingeschätzt, dass öffentliches iOS-Sicherheitsforschungswissen nahezu auf dem Niveau nicht öffentlichen Wissens lag.
  • Seit iOS 14 ist der Informationsaustausch, von Ausnahmen abgesehen, praktisch zum Erliegen gekommen.
  • Selbst wenige Wochen vor der iOS-19-Beta gibt es demnach keinen öffentlichen Kernel-Exploit für iOS 18 oder iOS 17.
  • In Apples Security Notes tauchen gelegentlich in freier Wildbahn ausgenutzte Schwachstellen auf, doch die öffentlichen Informationen halten mit der nicht öffentlichen Forschung nicht Schritt.
  • Dass die Veröffentlichung von tachy0n erst 5 Jahre zurückliegt, zeigt, wie schnell sich das Feld der iOS-Kernel-Exploits verändert hat.

Verwandte Beiträge

2 Kommentare

 
ndrgrd 2025-05-26

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.
 
GN⁺ 2025-05-25
Meinungen auf Hacker News

  • Beeindruckend ist, dass die Methode, mit der ein Billion-Dollar-Unternehmen geschlagen wurde, eine einfache, langweilige Aufgabe war, bei der Apple besonders schwach ist: Regressionstests.
    SockPuppet, eine der großen Schwachstellen, die für den Jailbreak in iOS 12 genutzt wurden, wurde von Ned Williamson von Project Zero gefunden und an Apple gemeldet, in iOS 12.3 gepatcht und später im Bugtracker von Project Zero veröffentlicht.
    Doch in iOS 12.4 tauchte sie wieder auf, als wäre sie nie gepatcht worden; vermutlich hatte Apple XNU für diese Version in einen eigenen Branch geforkt und den Patch dabei nicht übernommen.
    Das war ein starkes Signal dafür, dass es für diese Art von Schwachstelle keine Regressionstests gab, und schon die Automatisierung einiger bekannter 1-days hätte Pwn sofort treffen können.
    Ich frage mich, wie viele Stellen CI-Farmen betreiben, die alte Schwachstellen kontinuierlich gegen neue Versionen von Projekten wie Linux, FreeBSD, OpenWRT oder OpenSSH laufen lassen.

    • Regressionstests sind ein standardmäßiges QA-Verfahren, um zu prüfen, ob behobene Bugs nicht wieder auftauchen.
      Vor 20 Jahren habe ich während des Studiums ehrenamtlich QA bei Mozilla gemacht; dort gab es eine ständig wachsende Sammlung von Regressionstests, vor allem für Rendering-/Layout- und JavaScript-Engine-Bugs.
      Da man zur Reproduktion und zur Verifikation des Fixes minimale Testfälle erstellte, war es auch einfach, diese in die Build-Pipeline aufzunehmen.
      Bugs sind unvermeidlich, aber dass ein Bug, in dessen Behebung Zeit und Geld geflossen sind, wiederaufersteht, ist das Worst-Case-Szenario.
      Organisationen, denen Qualität wichtig ist, investieren sicher in Regressionstests, aber viele Organisationen respektieren QA nicht und machen sie entweder gar nicht oder geben sie an den billigsten Outsourcer.
      Dass Apple für Jailbreaks, historisch eine der sichtbarsten Bug-Kategorien überhaupt, keine Regressionstests hatte, ist wirklich seltsam.
      Mozilla kann heutzutage für vieles kritisiert werden, aber schon Anfang der 2000er hatte man mit Tools wie Tinderbox und Bugzilla recht solide QA und CI/CD.
      Als DevOps populär wurde und diese Vorgehensweisen verbreitete, dachte ich, das hätten ohnehin schon alle gemacht – aber das war mein Irrtum.
    • Wenn man hier unter „Projekte“ auch Nachrichtendienste einbezieht, kann man wohl sicher davon ausgehen, dass zumindest die G10-Nachrichtendienste sowie Russland, China, Nordkorea und zahlreiche private Gruppen so etwas tun.
    • Das Grundproblem scheint zu sein, dass viele Organisationen Security-Arbeit in einen eigenen Ablauf und eine eigene Bug-Kategorie isoliert haben.
      Das ist eine Art Conway’s Law, entstanden durch die Trennung von Security und Feature-Entwicklung.
      Selbst wenn es Build-/Release-Prozesse und eine ausgereifte Sammlung von Regressionstests gibt, ist es aufgrund der internen Organisationsstruktur gut möglich, dass solche Security-Issues dort nicht hineinfallen.
    • Ich erinnere mich nicht an den Namen, aber ich habe einmal ein FOSS-Projekt gesehen, das für jedes Issue ein Testfall-Verzeichnis hatte.
      Es waren locker Tausende, und ich glaube, es war SQLite.
      Das ist ein nachahmenswerter Ansatz.
      Wenn man Fixes nicht backportet, ist es wohl auch wahrscheinlich, dass man die Tests nicht backportet.

  • Bei Begriffen wie kheap separation, task port mitigation, SSV und SPTM fühlte es sich an, als würde man sich in einer Fremdsprache gut mit einem Freund unterhalten und dann plötzlich in eine Erklärung von Gehirnchirurgie oder Kernphysik abrutschen, woraufhin das Verständnis eine Klippe hinunterfällt.
    Ähnlich war es, als ich einmal ein Gespräch über die Modernisierung eines Hochofens dolmetschen wollte.
    Schade, dass Jailbreaking nicht mehr so lebhaft ist wie früher.
    Ich habe mit einem jailbroken iPad kaum etwas Praktisches gemacht, aber es hat Spaß gemacht; heute würde ich gern eine Tethering-App, UTM und eine JIT-Lösung installieren.
    SideStore sah ebenfalls vielversprechend aus, aber mein Account war einmal ein kostenpflichtiger Apple-Developer-Account, deshalb habe ich noch 10 nicht ablaufende App-IDs übrig und kann daher keine Apps wie UTM installieren, ohne einen neuen Account anzulegen oder wieder zu bezahlen.

    • Ich habe früher ein iPhone 4 per Jailbreak genutzt, und das war praktisch die einzige Möglichkeit, ein iPhone als Hauptgerät zu verwenden.
      Nachdem ich das verloren hatte, bin ich zu Android zurückgekehrt; zu diesem Zeitpunkt hatte Android bei den Basisfunktionen schon ziemlich aufgeholt.

  • Ich habe gehört, dass Apple heutzutage 1 Million Dollar für einen Jailbreak zahlt, und das dürfte die Untergrenze des freien Marktpreises sein.

  • Wenn das stimmt, hat Apple eine erstaunliche Strategie verfolgt.
    Wenn man alle Wege sperrt, Root auf dem Gerät zu erlangen, kann Apple die Schwachstellen patchen, die Jailbreak-Entwickler kostenlos finden.

    • Ganz so ist es aber nicht.
      Dem Artikel zufolge verfügen private Communities weiterhin über Exploits, und Apple patcht diese.
      Nur bei der öffentlichen Community oder diesem Entwickler scheint das aus irgendeinem Grund nicht mehr der Fall zu sein.

  • Der beste Satz im ganzen Text war: „Ich möchte auch der Person danken, die diesen Bug in iOS 13.0 wieder unpatched gemacht hat. Das war ebenfalls eine sehr coole Aktion.“

  • „Ich kann mir nicht vorstellen, wo wir in fünf Jahren sein werden“ – ich schon.
    iMessage wird weiterhin die Übernahme von Geräten, Accounts und Daten ermöglichen.

  • Im Text stand nicht, ob es tethered oder untethered ist.

    • tachy0n ist eine lokale Rechteausweitung (LPE), daher passt diese Einordnung nicht wirklich.
      Der Jailbreak unc0ver, in dem das enthalten war und der ausgeliefert wurde, war meines Wissens wohl „semi-untethered“.