Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Aufgedeckte Schwachstelle im M1-Chip: M1RACLES-Lücke umgeht Sicherheitsrichtlinien

Vielen sind vielleicht noch die Anfang 2018 bekanntgewordenen Schwachstellen Spectre und Meltdown in Intel-x86-Chips im Gedächtnis: Angreifer konnten sich Zugriff auf normalerweise geschützte Daten im Speicher verschaffen. Heutige Prozessoren führen bereits weitere Befehle aus, wenn noch gar nicht klar ist, welche Richtung einer Wenn-Dann-Bedingung überhaupt verfolgt wird – dies nennt sich "Spekulative Ausführung". Hat der Prozessor richtig getippt und es wurde der korrekte Weg der Wenn-Dann-Bedingung ausgeführt, sparte die CPU wertvolle Taktzyklen – ansonsten verwarf der Chip einfach die errechneten Informationen. Doch in der Cache landeten trotzdem einige Daten, welche sich im Nachhinein auslesen lassen – und genau hier liegt das Problem: Während der "Spekulativen Ausführung" sind einige Sicherheitsmechanismen der CPU nicht aktiv – und somit kann sich ein Programm Zugriff auf Daten verschaffen, welche normalerweise nicht ausgelesen werden dürfen.


Diese Lücken führten einem breiten Publikum vor Augen, dass auch die Hardware Sicherheitsfehler aufweisen kann, welche sich nicht oder nur mit Nachteilen durch Software beheben lassen. Nun hat Hector Martin, Entwickler bei Asahi Linux und verantwortlich für die Portierung des Betriebssystems auf M1-Macs, einen Mangel in Apples M1-Chip festgestellt, mit welchem es möglich ist, die Sicherheitsrichtlinien des Betriebssystems teilweise außer Kraft zu setzen.

Datenaustausch zwischen Prozessen
Normalerweise kontrolliert das Betriebssystem streng, welche Prozesse oder Apps Daten austauschen. Doch Martin fand nun einen Weg, wie zwei Prozesse Daten mit hoher Geschwindigkeit austauschen können, ohne dass macOS dies verhindern kann. Durch ein ARM-Systemregister mit dem Namen "s3_5_c15_c10_1" ist es möglich, zwei Bits zu lesen und zu schreiben – und zwar ohne jegliche Privilegien aus dem Exception-Level 0 (EL0). Diese Daten bleiben selbst nach einem Kontext-Wechsel in einen anderen Prozess erhalten, so dass ein anderer Prozess diese auslesen kann – völlig vorbei an den Sicherheitsmechanismen von macOS.

In einem kurzen Video (mit fürchterlicher Musik) demonstriert Martin, wie zwei Prozesse mit einer Geschwindigkeit von über 1 MB/s Daten austauschen, ohne dass macOS dies durch ein Software-Update verhindern könnte:


Wie hoch ist das Risiko?
Der Fehler ist nicht mit anderen, schwerwiegenden Sicherheitslücken wie zum Beispiel Spectre oder Meltdown vergleichbar. Es ist nicht möglich, damit Kontrolle über den Mac zu gelangen, Passwörter auszuspionieren oder an andere Daten des Nutzers zu gelangen. Dennoch birgt die Lücke ein gewisses Risiko: Da zwei angepasste Prozesse Daten ohne "Aufsicht" austauschen können, ist es nun einfacher möglich, unter der Zuhilfenahme weiterer Schwachstellen im Betriebssystem einen kompletten Angriffsvektor zu finden.

Ohne Zuhilfenahme weiterer Schwachstellen ist die gefundene Lücke für Hacker wertlos – und selbst dann böten sich normalerweise einfachere Methoden, Daten zwischen Prozessen auszutauschen als die gefundene M1RACLES-Lücke, wie Martin analysiert. Trotzdem verletzt die Schwachstelle die Sicherheitsrichtlinien des Betriebssystems, da macOS nun nicht sicherstellen kann, dass keine Daten zwischen nicht berechtigten Prozessen ausgetauscht werden.

Was kann Apple tun?
Apple wird diesen Fehler nicht durch ein Update von macOS beheben können, da der Fehler in der Hardware selbst begründet ist. Martin meldete den Bug an Apple, so dass zukünftige M-Prozessoren diesen Fehler nicht mehr mitbringen dürften. Da die praktischen Anwendungsfälle, welche durch M1RACLES entstehen, aber sehr wenige bis keine sind, wird Apple dieser Sicherheitslücke nur geringe Priorität beimessen.

Kommentare

aMacUser
aMacUser26.05.21 09:37
Auch Apple kocht nur mit Wasser.

Aber sehe ich das richtig: Solange eine Anwendung nicht dieses spezielle Register verwendet, ist diese "Lücke" vollkommen harmlos?
+1
therojam
therojam26.05.21 09:39
füchterliche Musik liegt im Auge des Betrachters.
+7
Mendel Kucharzeck
Mendel Kucharzeck26.05.21 09:40
aMacUser
Du brauchst zwei angepasste Prozesse, die in das Register Daten reinschreiben und auslesen – einen nicht angepassten Prozess kann man damit nicht "kapern" oder Daten auslesen.
+5
Dirk!26.05.21 09:43
Kann das Betriebssystem bei einem Wechsel des Prozesses diese zwei Bits nicht jedesmal zurücksetzen?
+2
Mendel Kucharzeck
Mendel Kucharzeck26.05.21 09:44
Dirk!
Wenn ich es richtig verstanden habe, teilen sich dieses Register alle Kerne einer Gruppe (also high- und low-power cores). Daher bleiben die nach einem Kontext-Switch auch erhalten.
0
Robby55526.05.21 09:53
Wenn ich es richtig verstehe kann Apple den Fehler nur in neuen Prozessoren nach M1 korrigieren. Was Apple aber sicher machen könnte ist Software die im Store aufgenommen wird darauf zu prüfen, dass sie diesen Fehler nicht ausnutzt. Ein Grund mehr auch auf MacOS keine Software mehr von außerhalb des eigenen Stores zu erlauben.
-8
Marcel Bresink26.05.21 10:06
Robby555
Was Apple aber sicher machen könnte ist Software die im Store aufgenommen wird darauf zu prüfen, dass sie diesen Fehler nicht ausnutzt.

Nein, so etwas kann man nicht zuverlässig prüfen.
+10
Metty
Metty26.05.21 10:12
therojam
füchterliche Musik liegt im Auge des Betrachters.
Falsch ... im Ohr des Betrachters.
+10
MikeMuc26.05.21 10:14
Mendel Kucharzeck
Hmm, Entwerfer teilen sich alle diese Register, dann müßte nur ein Programm dabei sein welches dort abgelegte „Daten“ ausließt.
Bleibt die Frage, wer oder was wird da überhaupt abgelegt. Wenn sich das alle Teilen, kann man sich ja nie auf den Inhalt verlassen, bekommt also bestenfalls zufällige Daten.
Oder das Ding wurde extra zum schnellen Datenaustausch da. Dann ist es auch kein Problem, wenn da 2 was austauschen. Erst wenn noch ein 3. mithört und die Struktur der dort gerade durchlaufenden Daten kennt, dann wird das ganze zum Problem.
Was genau da intern passiert, wird wohl nur Apple wissen denn nur die sollten wissen, wie ihr eigener Prozessor wirklich arbeitet
0
Robby55526.05.21 10:17
Marcel Bresink
Robby555
Was Apple aber sicher machen könnte ist Software die im Store aufgenommen wird darauf zu prüfen, dass sie diesen Fehler nicht ausnutzt.

Nein, so etwas kann man nicht zuverlässig prüfen.

Na dann hat Apple jetzt eine Aufgabe. Solange es in der Praxis noch zu keine großen Probleme kommt ist ja alles gut aber darauf kann sich Apple nicht verlassen. Auch eine 50 % Zuverlässigkeit ist bei einer Überprüfung besser als nichts tun.
-2
Marcel Bresink26.05.21 10:31
Der App Store überprüft nur, ob eine App rein äußerlich Apples Geschäftsinteressen schaden könnte. Auf Sicherheit und Datenschutz wird nicht überprüft. Das wäre teuer und würde in der Praxis sowieso nicht funktionieren.
+5
MetallSnake
MetallSnake26.05.21 10:37
therojam
füchterliche Musik liegt im Auge des Betrachters.

Nach dem Hinweis auf fürchterliche Musik wusste ich dass da Musik laufen wird die mir gefallen wird und habe deshalb das Video gestartet, und ich habe recht behalten.
Die Menschheit ist eine völlig außer Kontrolle geratene Primatenspezies.
+4
Frank Drebin
Frank Drebin26.05.21 10:43
Okay, also am Ende könnte man es auf Französisch sagen, "Tant de bruit pour une omelette"…

... und ja die Musik ist gruselig in dem Video, was auch übermässig lange dauert um das Problem zu zeigen. Dafür hätten auch 15 Sekunden gereicht…
-1
Krypton26.05.21 11:02
Robby555
Marcel Bresink
Robby555
Was Apple aber sicher machen könnte ist Software die im Store aufgenommen wird darauf zu prüfen, dass sie diesen Fehler nicht ausnutzt.

Nein, so etwas kann man nicht zuverlässig prüfen.

Na dann hat Apple jetzt eine Aufgabe. Solange es in der Praxis noch zu keine großen Probleme kommt ist ja alles gut aber darauf kann sich Apple nicht verlassen. Auch eine 50 % Zuverlässigkeit ist bei einer Überprüfung besser als nichts tun.

Jedes Programm kann im Programmablauf ein Unterprogramm generieren, welches ein Unterprogramm generiert, welches ein Jahr wartet und dann ein Unterprogramm generiert, welches die Datenbits nutzt. Man kann bei einer Überprüfung schlicht nicht ein komplettes Code-Review durchführen, das würde viele Spezialisten und dann pro Programm noch Monate oder Jahre dauern. Das prüfen zu wollen, ist völlig aussichtslos, daher kann man es auch gleich lassen. Hier gibt es keine Sicherheit und man kann auch keine Erwarten. Man wüsste auch nicht, wann diese 50% oder auch nur 10% an gefühlter Sicherheit erreicht wären.
Sandkörner in der Wüste zu zählen hat dagegen mehr Aussicht auf Erfolg.
+4
Niederbayern
Niederbayern26.05.21 11:32
Bin am hadern ob ich das Video wegen der Musik oder zwecks der Info anclicken soll. Ach, ich lasse es einfach…
+3
Robby55526.05.21 11:37
Krypton
Robby555
Marcel Bresink
Robby555
Was Apple aber sicher machen könnte ist Software die im Store aufgenommen wird darauf zu prüfen, dass sie diesen Fehler nicht ausnutzt.

Nein, so etwas kann man nicht zuverlässig prüfen.

Na dann hat Apple jetzt eine Aufgabe. Solange es in der Praxis noch zu keine großen Probleme kommt ist ja alles gut aber darauf kann sich Apple nicht verlassen. Auch eine 50 % Zuverlässigkeit ist bei einer Überprüfung besser als nichts tun.

Jedes Programm kann im Programmablauf ein Unterprogramm generieren, welches ein Unterprogramm generiert, welches ein Jahr wartet und dann ein Unterprogramm generiert, welches die Datenbits nutzt. Man kann bei einer Überprüfung schlicht nicht ein komplettes Code-Review durchführen, das würde viele Spezialisten und dann pro Programm noch Monate oder Jahre dauern. Das prüfen zu wollen, ist völlig aussichtslos, daher kann man es auch gleich lassen. Hier gibt es keine Sicherheit und man kann auch keine Erwarten. Man wüsste auch nicht, wann diese 50% oder auch nur 10% an gefühlter Sicherheit erreicht wären.
Sandkörner in der Wüste zu zählen hat dagegen mehr Aussicht auf Erfolg.

Super Interessant. Kann dann auf Betriebsystemebene z.B. bei einem Update nicht eine Routine eingebaut werden die prüft wenn ein Programm oder ein Treiber versucht die betroffenen Register zu nutzen ? Wenn es dann entdeckt wird sofort eine Meldung an Apple um das entsprechende Programm aus dem Store zu verbannen bis die Sache korrigiert wird ? Ich bin kein Programmierer aber ich denke Sicherheit ist schon etwas wo Apple ansetzen muss. Theoretisch könnten sie vielleicht ein entsprechendes Programm auch vom Betriebsystem aus so sperren das es gar nicht mehr ausgeführt werden kann.
-1
Pallllo26.05.21 11:58
Gibt es in den Prozessoren nicht auch Microcode der per SW upgedatet werden kann?
+1
MaddinKI26.05.21 12:23
Robby555
Ein Grund mehr auch auf MacOS keine Software mehr von außerhalb des eigenen Stores zu erlauben.
Dann bin ich bei Linux und Windows. Schlimm genug, dass es einem jetzt schon schwerer als nötig gemacht wird.
+6
te-c26.05.21 12:26
Metty
therojam
füchterliche Musik liegt im Auge des Betrachters.
Falsch ... im Ohr des Betrachters.
Wenn schon, dann im Ohr des Zuhörers?
+8
Krypton26.05.21 13:52
Robby555
Kann dann auf Betriebsystemebene z.B. bei einem Update nicht eine Routine eingebaut werden die prüft wenn ein Programm oder ein Treiber versucht die betroffenen Register zu nutzen ?

Das ist ja der Haken an der Sache. Wenn’s dich genauer interessiert, kannst du die Details auf der Seite des Entdeckers ziemlich weit unten den Absatz «Can you go into more details about the possible mitigations and why you can't just fix this in, like, 5 lines of code?» nachlesen.

So eine «Routine» würde eine komplette Änderung des Speichermodell des «Hypervisors» notwendig machen. Das wiederum wäre auf dem M1 vielfach komplizierter als auf den x86, da Apple eine Funktion bei ihren M1 ARM-Versionen gestrichen hat, die normalerweise in der ARM-Spezifikation drin ist. Der Aufwand wäre schlicht riesig.
Robby555
Wenn es dann entdeckt wird sofort eine Meldung an Apple um das entsprechende Programm aus dem Store zu verbannen bis die Sache korrigiert wird ? Ich bin kein Programmierer aber ich denke Sicherheit ist schon etwas wo Apple ansetzen muss. Theoretisch könnten sie vielleicht ein entsprechendes Programm auch vom Betriebsystem aus so sperren das es gar nicht mehr ausgeführt werden kann.
Da MacOS den Zugriff auf die Bereiche aktuell nicht entdecken kann, lässt sich auch nichts sperren. Abgesehen davon ist die Verwendung der Register ja gar nicht verboten. Man weiß jetzt nur, dass man sie nicht gegen andere Apps abschirmen kann. Wenn du also ein Programm schreibst, das hier etwas ablegt, dann bestünde nur die theoretische Gefahr, dass ein anderes Programm (auf dem selben CPU-Cluster) die zwei Bits ausliest.
Die Gefahr ist auch eher theoretischer Natur und nicht wirklich relevant. Deshalb wird Apple wohl erstmal gar nichts machen und später vielleicht eine Korrektur im nächsten M1 oder M2.

Was man gleich korrigieren könnte, wären Leerzeichen vor Satzzeichen. Außer im Französischen gehört vor ein Ausrufe- oder Fragezeichen kein Leerzeichen. Und im Französischen würde ein Typograph dort auch nur ein «narrow no-break space» setzten. Im Netzjargon wird das auch als Plenken bezeichnet.
+2
awk26.05.21 14:23
Mit der Bewertung "ist alles ganz harmlos und kein Problem" sollte man vorsichtiger sein. Derzeit mag das richtig sein. Aber Spectre und Meltdown hatten Vorläufer, die auch als eher unbedeutend eingestuft wurden, und sich somit niemand darum gekümmert hat. Bis viele Jahre später ein kluger Kopf kam und zeigte wie gefährlich das sein kann.
Apple sollte dieses Manko tunlichst sehr zügig abstellen.
0
Robby55526.05.21 14:37
Krypton
Was man gleich korrigieren könnte, wären Leerzeichen vor Satzzeichen. Außer im Französischen gehört vor ein Ausrufe- oder Fragezeichen kein Leerzeichen. Und im Französischen würde ein Typograph dort auch nur ein «narrow no-break space» setzten. Im Netzjargon wird das auch als Plenken bezeichnet.

Aha, wieder was gelernt. Als ich in der Schule war haben wir noch Schreibschrift gelernt und da war es kein Thema
-1
Lamoras26.05.21 14:41
Also Apple kann doch das Problem zumindest workaround mäßig beheben: Einfach konstant random Bits dort reinschreiben.

Wobei es das Apple vermutlich einfach nicht Wert ist
+1
lphilipp
lphilipp26.05.21 18:07
... in der Cache
die Cache, der Cache oder das Cache?
Man muß sich Sisyphos als einen glücklichen Menschen vorstellen! Albert Camus (Il faut imaginer Sisyphe heureux)
+2
ruphi26.05.21 20:16
MTN
In einem kurzen Video (mit fürchterlicher Musik)
Das nennt man wohl 'launigen Journalismus' 😆
0
Gerry
Gerry26.05.21 21:19
Naja lange hat es nicht gedauert. Aber es ist nun mal so Sicherheitslücken gibt es überall. Auch bei Apple. Von daher wäre es auch kein Wunder würde man mal eine schwere Lücke finden.
+1
Mecki
Mecki27.05.21 17:49
ohne dass macOS dies durch ein Software-Update verhindern könnte
Darauf würde ich nicht wetten. Ein Softwareupdate kann auch den Microcode einer CPU patchen. Solche Patches für Intel CPUs liefert Microsoft ständig mit Windows Updates aus und auch Apple hat das doch wegen Spectre schon getan. Oder hat der M1 keinen Microcode bzw. keinen, den man updaten kann? Und da das Register ja sonst keinen sinnvollen Zweck erfüllt, könnte der Microcode einfach bei jedem Zugriff darauf künftig eine CPU Exception werfen oder beim lesen einfach immer nur 00 zurück liefern.

Ach ja, und das Lied, das ich keineswegs furchtbar finde, hat er wohl deswegen genommen, weil der Titel des Liedes "Bad Apple" ist. Das Video hat immer hin 42 Mio Views und fast eine halbe Mio Daumen hoch, scheinen also andere auch nicht so furchtbar zu finden.
+1

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.