Erster öffentlich gezeigter macOS-Kernel-Speicherbeschädigungs-Exploit auf Apple M5

 (blog.calif.io)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Calif-Ingenieure haben einen macOS-Kernel-Speicherbeschädigungs-Exploit entwickelt, der auf Apple M5 läuft, und Apple einen Bericht zur Schwachstellenforschung übergeben
  • Die Exploit-Kette zielt auf Bare-Metal-M5-Hardware mit aktiviertem MIE ab; die vollständigen technischen Details sollen nach Apples Fix veröffentlicht werden
  • Ziel ist macOS 26.4.1 (25E253); von einem nicht privilegierten lokalen Benutzer aus wird allein mit gewöhnlichen Systemaufrufen eine Root-Shell erreicht
  • Die Implementierung nutzt zwei Schwachstellen und mehrere Techniken; Calif stuft dies als den ersten öffentlich gezeigten macOS-Kernel-Exploit auf MIE-Hardware ein
  • Mythos Preview half bei der Identifizierung der Bugs und der Exploit-Entwicklung, doch zum Umgehen neuer Mitigations wie MIE sind weiterhin menschliche Experten nötig

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

  • Calif-Ingenieure haben gemeinsam mit Mythos Preview einen macOS-Kernel-Speicherbeschädigungs-Exploit entwickelt, der auf Apple-M5-Silicon läuft, und Apple den Bericht zur Schwachstellenforschung persönlich im Apple Park übergeben
  • Die 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 reine datenbasierte Kernel-LPE-Kette, die bei einem nicht privilegierten lokalen Benutzer beginnt, nur gewöhnliche Systemaufrufe verwendet und in einer Root-Shell endet
  • Die Implementierung umfasst zwei Schwachstellen und mehrere Techniken; nach Apples Behebung der Schwachstellen und des Angriffswegs 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 Mitigations nötig, die die Angriffskosten erhöhen
  • Apple hat mit Blick auf Leistung und Sicherheit viele Schutzfunktionen in die Hardware verlagert und die Schwierigkeit der Umgehung 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 zentrales Sicherheitsmerkmal von Apple M5 und A19 eingeführt
  • Laut Apples Forschung stört MIE sämtliche öffentlich bekannten Exploit-Ketten gegen modernes iOS, einschließlich der jüngst geleakten Exploit-Kits Coruna und Darksword
  • Calif untersucht seit Längerem, wie KI zum Aufbau von Exploits beitragen kann, die auch in MTE-Umgebungen funktionieren; da Apples bisher auf iOS fokussiertes MIE nun auch auf dem M5 in aktuellen MacBooks zum Einsatz kommt, werden Angriffswege gegen macOS möglich
  • Mythos Preview half bei der Identifizierung der Bugs und über die gesamte Exploit-Entwicklung hinweg; bei bereits erlernten Problemtypen kann es sogar auf nahezu gleiche Problemklassen generalisieren
  • Dass Mythos die Bugs schnell fand, lag daran, dass sie zu bekannten Typen gehörten; das autonome Umgehen neuer Top-Level-Mitigations wie MIE bleibt weiterhin Sache menschlicher Experten
  • Calif testete, was möglich ist, wenn Spitzenmodelle und Experten zusammenarbeiten; diese Kombination konnte innerhalb einer Woche einen Kernel-Speicherbeschädigungs-Exploit gegen Schutzmechanismen der höchsten Klasse fertigstellen
  • MIE ist nicht dazu gedacht, Hacker vollständig aufzuhalten; bei geeigneten Schwachstellen kann es umgangen werden
  • In der Reihe MAD Bugs wird die Ansicht vertreten, dass KI-Systeme immer mehr Schwachstellen finden und einige davon stark genug werden könnten, um fortgeschrittene Mitigations wie MIE zu überwinden
  • Als Apple MIE entwickelte, gab es noch keine Umgebungen wie Mythos Preview; diese Arbeit ist ein frühes Ergebnis dafür, welchen Druck KI-gestützte Bug-Suche auf fortgeschrittene Mitigationstechniken ausübt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
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