Erste öffentlich gemachte macOS-Kernel-Speicherbeschädigungs-Schwachstelle auf Apple M5

 (blog.calif.io)
2 Punkte von GN⁺ 2026-05-15 | 1 Kommentare | Auf WhatsApp teilen
  • Die Ingenieure von Calif haben einen macOS-Kernel-Speicherbeschädigungs-Exploit entwickelt, der auf Apple M5 läuft, und Apple einen Forschungsbericht zur Schwachstelle übermittelt
  • Die Exploit-Kette zielt auf Bare-Metal-M5-Hardware mit aktiviertem MIE ab; die vollständigen technischen Details sollen nach Apples Behebung veröffentlicht werden
  • Ziel ist macOS 26.4.1 (25E253); von einem nicht privilegierten lokalen Benutzer aus wird allein mit normalen Systemaufrufen eine Root-Shell erreicht
  • Für die Implementierung wurden zwei Schwachstellen und mehrere Techniken verwendet; Calif stuft dies als den ersten öffentlich gemachten macOS-Kernel-Exploit für MIE-Hardware ein
  • Mythos Preview half bei der Identifizierung der Bugs und der Entwicklung des Exploits, doch für das Umgehen neuer Mitigationsmaßnahmen wie MIE sind weiterhin menschliche Experten nötig

macOS-Kernel-Exploit, der MIE auf dem M5 überwindet

  • Die Ingenieure von Calif haben zusammen mit Mythos Preview einen macOS-Kernel-Speicherbeschädigungs-Exploit entwickelt, der auf Apple M5-Silizium läuft, und Apple den Forschungsbericht zur Schwachstelle persönlich im Apple Park übergeben
  • Diese Kette zielt auf Bare-Metal-M5-Hardware mit aktiviertem MIE(Memory Integrity Enforcement) ab
  • Ziel ist macOS 26.4.1 (25E253); es handelt sich um eine datenbasierte lokale Kernel-Privilege-Escalation-Kette, die bei einem nicht privilegierten lokalen Benutzer beginnt, nur normale Systemaufrufe verwendet und in einer Root-Shell endet
  • Für die Implementierung wurden zwei Schwachstellen und mehrere Techniken kombiniert; nach der Behebung der Schwachstellen und des Angriffswegs durch Apple sollen ein 55-seitiger Bericht und alle technischen Details veröffentlicht werden
  • Der Zeitplan verlief schnell
    • Bruce Dang entdeckte den Bug am 25. April
    • Dion Blazakis stieß am 27. April zu Calif
    • Josh Maine entwickelte die Tools, und am 1. Mai war ein funktionierender Exploit fertig

Die Bedeutung von MIE und Mythos Preview

  • Speicherbeschädigung ist weiterhin der häufigste Schwachstellentyp, auch unter iOS und macOS; wenn sie sich nicht vollständig verhindern lässt, sind Mitigationsmaßnahmen nötig, die die Angriffskosten erhöhen
  • Apple hat viele Schutzfunktionen mit Blick auf Leistung und Sicherheit in die Hardware integriert und die Schwierigkeit von Umgehungen erhöht, indem das Unternehmen den gesamten Stack kontrolliert
  • MIE ist ein hardwaregestütztes Speichersicherheitssystem auf Basis von ARMs MTE (Memory Tagging Extension) und wurde als zentrale Sicherheitsfunktion von Apple M5 und A19 eingeführt
  • Laut Apples Forschung stört MIE alle öffentlich bekannten Exploit-Ketten gegen modernes iOS, einschließlich der kürzlich geleakten Exploit-Kits Coruna und Darksword
  • Calif hat untersucht, wie KI zur Entwicklung von Exploits beitragen kann, die auch in MTE-Umgebungen funktionieren; da Apples bislang iOS-zentriertes MIE nun auch auf dem M5 aktueller MacBooks eingesetzt wird, werden damit Angriffspfade für macOS möglich
  • Mythos Preview half bei der Bug-Identifizierung und bei der gesamten Exploit-Entwicklung und kann bei bereits gelernten Problemtypen sogar auf nahezu identische Problemarten generalisieren
  • Dass Mythos die Bugs schnell fand, lag daran, dass sie zu bekannten Typen gehörten; das autonome Umgehen neuer Mitigationsmaßnahmen auf höchstem Niveau wie MIE bleibt weiterhin Sache menschlicher Experten
  • Calif testete den Umfang dessen, was möglich ist, wenn Spitzenmodelle und Experten zusammenarbeiten; diese Kombination konnte innerhalb einer Woche einen Kernel-Speicherbeschädigungs-Exploit gegen Schutzmechanismen auf höchstem Niveau fertigstellen
  • MIE ist keine Maßnahme, die Hacker vollständig stoppen soll; bei passenden Schwachstellen kann es umgangen werden
  • In der Reihe MAD Bugs wird vertreten, dass KI-Systeme immer mehr Schwachstellen finden und einige davon stark genug werden könnten, um fortgeschrittene Mitigationsmaßnahmen wie MIE zu überwinden
  • Als Apple MIE entwickelte, gab es noch keine Umgebung wie Mythos Preview; diese Arbeit ist ein frühes Ergebnis, das zeigt, welchen Druck KI-basierte Bug-Suche auf fortgeschrittene Mitigationstechniken ausübt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-05-15
Hacker-News-Kommentare

  • Nach der Demo zu urteilen, wirkt das auf Apples Bug-Bounty-Plattform wie eine 100.000-Dollar-Schwachstelle, aber mit guter Verpackung könnte daraus auch eine 1,5-Millionen-Dollar-Schwachstelle werden
    Man müsste sie auf einer macOS-Betaversion reproduzieren, als unautorisierten Zugriff einstufen und wenn möglich auch im Lockdown-Modus zeigen

    • Das hier sieht nach lokaler Rechteausweitung (LPE) aus, während das oben Gesagte eher an Remote Code Execution (RCE) ohne Klick erinnert

  • Die Welt scheint auf den Einfluss von LLMs auf Sicherheitsprobleme überhaupt nicht vorbereitet zu sein
    Falls das stimmt, Glückwunsch an das Calif-Team, und auch wenn die Details zu technisch sind, um alles vollständig zu verstehen, freue ich mich schon auf den 55-seitigen Bericht

    • Sehe ich auch so, aber meine Sorge gilt den Menschen
      Man hört überall Geschichten darüber, dass Entwickler von LLMs erzeugte Codeänderungen in die Produktion schieben, ohne wirklich zu verstehen, was sie da überhaupt ausrollen
      Je mehr sich diese Änderungen ansammeln, desto geringer wird das Verständnis für die Codebasis und desto riskanter wird das Verhalten
      Noch schlimmer ist, dass dieses Verhalten von der Führung direkt oder indirekt gefördert wird. Etwa durch unrealistische Geschwindigkeitsziele, Beförderungen über vage „AI-Nutzung“-Initiativen, Überlastung der verbleibenden Entwickler nach Entlassungen oder indem unerfahrene Entwickler in Senior-Rollen gesetzt werden
      Es wirkt, als wolle ein großer Teil der Branche die Grundlagen der Sicherheit mühsam noch einmal neu lernen, während die Welt verrücktspielt
    • Das klingt so, als würde man davon ausgehen, dass Blue Teams und Engineers tatenlos dasitzen und nichts tun

  • LLMs werden in den nächsten Jahren massenhaft Rube-Goldberg-artige Schwachstellen hervorbringen
    Das hat bereits begonnen, und auch wenn dieser Fall wohl nicht dazugehört, passiert es tatsächlich

    • Es könnte theoretisch schlicht physikalisch unmöglich sein, ein wirklich sicheres System zu bauen
      So wie es vielleicht keine Zelle gibt, die gegen jedes Virus resistent ist
      Vielleicht haben wir bisher nur dank einer Art Security through Obscurity überlebt, und diese Obskurität bedeutete am Ende nur, dass niemand Zeit oder Konzentration hatte, den Code tatsächlich zu analysieren
    • Ich frage mich, ob gemeint ist, dass solche Schwachstellen per Vibe Coding in den Kernel eingebaut werden, oder dass sie damit gefunden werden

  • Leider fehlen ein paar Details
    Mich interessiert sehr, wie der Bug MTE umgehen konnte

    • Memory Tagging Extension
      Arm hat 2019 die Spezifikation für die Memory Tagging Extension (MTE) veröffentlicht, ein Werkzeug, das der Hardware helfen soll, Memory-Corruption-Bugs zu erkennen
      MTE ist ein System zur Speicher-Markierung und Tag-Prüfung, das jede Speicherallokation mit einem geheimen Wert versieht
      Die Hardware erlaubt danach Speicherzugriffe nur, wenn die Anfrage den korrekten geheimen Wert enthält
      Stimmt der geheime Wert nicht, stürzt die App ab, das Ereignis wird protokolliert und Entwickler können den Memory-Corruption-Bug sofort identifizieren
      https://support.apple.com/guide/security/operating-system-in...
    • Nachdem ich mehr über Data-only-Angriffe gelesen habe, ergibt es Sinn
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      Das Programm selbst wird nicht wirklich verändert, also wird kein Verhalten erzwungen, bei dem MTE eingreifen müsste, und deshalb wird MTE nicht ausgelöst
      Eine andere Frage ist, warum Apple hier keine fbounds-Prüfungen verwendet hat
      Anderswo hat Apple sie ziemlich aggressiv eingesetzt
      Mit MTE zusammen mit flächendeckenden fbounds-Prüfungen könnte das Betriebssystem extrem robust werden
    • GPU-Speicher, Shader und Ähnliches sind nicht durch MTE oder PAC geschützt
      Da von „data-only“ die Rede war, könnten GPU-Befehle hier gut ins Bild passen
    • Ich hatte dieselbe Frage, und falls das ein Data-only-Angriff ist, könnte das die Lehre sein, dass MIE zwar viele Angriffswege reduziert, aber nützliche Corruption-Primitiven nicht vollständig beseitigt
    • Es ist nicht das erste Mal, dass ein Bug MTE umgeht
      Vergangenes Jahr gab es bei Google Pixel etwas Ähnliches
      https://github.blog/security/vulnerability-research/bypassin...

  • Es überrascht mich, dass Apple die angeblich sichere Sprache Swift intern immer noch nicht richtig nutzt
    Da fragt man sich, ob Swift 6 insgesamt fast nur Marketing war

    • Tun sie definitiv
      Einer der Gründe für Embedded Swift ist gerade, die derzeitige iBoot-Firmware, die in einem C-Dialekt mit ähnlicher Grundidee wie Fil-C geschrieben ist, durch etwas Besseres zu ersetzen
      Ansonsten ist das nicht anders als beim Linux-Kernel
      Nur weil Rust erlaubt wurde, wurde nicht gleich die ganze Welt neu geschrieben, und kein vernünftiger Mensch würde versuchen, den Kernel mit Claude neu zu schreiben
    • Bei Apple wird Swift ganz klar verwendet
      Vor kurzem wurde es dem CSS-Parser von Safari hinzugefügt, und Teile der Secure Enclave laufen ebenfalls in eingebetteter Form damit
      Soweit ich weiß, gibt es seit der Strangeloop-Zeit Diskussionen darüber, es in den Kernel zu bringen, aber ich weiß nicht, wie weit das gediehen ist
      Unabhängig davon hat Apple stark auf fbounds-Prüfungen in clang gesetzt, was einen kleinen, aber wichtigen Teil dessen erreichen kann, was speichersichere Sprachen bieten
      Ich würde auch gern sehen, dass Swift oder alternative Sprachen noch stärker übernommen werden, und mehr Wettbewerb im Bereich sicherer Sprachen ist immer willkommen
    • Vielleicht ist die Option Strict Memory Safety interessant
      https://docs.swift.org/compiler/documentation/diagnostics/st...

  • Ich habe mir extra wegen MIE ein M5 gekauft und fühle mich jetzt etwas dumm

    • Dafür gibt es keinen Grund
      MTE blockiert eine große Klasse von Schwachstellen und macht Techniken wie ROP und JOP inzwischen sehr schwer oder praktisch unmöglich
    • Ich würde mir mehr Sorgen um npm-/PyPI-Malware machen als um Memory-Corruption-Bugs

  • Wurde der Artikel bearbeitet? Es gibt kaum eine Erklärung zum Vor-Ort-Besuch

  • Das wirkt wie ein weiteres Stück übertriebenes Marketing für Mythos
    Der curl-Bericht war deutlich nüchterner
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • Diese Leute arbeiten nicht bei Apple oder Anthropic