Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsiLeakage × Safari: Spectre nun auch bei Apple-CPUs ein Thema
Hast du alles gelesen, oder nur die Überschrift? Der Patch ist bereits im Browser implementiert, schon lange, aber noch als instabil eingestuft und deshalb deaktiviert. Was ist daran peinlich, instabile Software, die mehr Probleme als Nutzen verursachen könnte zurück zu halten?
Das ist ein Angriffsvektor der enorm viel Zeit und Aufwand benötigt um ans Ziel zu kommen. Man kann auch sagen viel heiße Luft um (fast) nichts.
Wenn ein Angriff selbst von den Entdeckern der Lücke als äußerst unwahrscheinlich angesehen wird, ist die Priorität eben nicht besonders hoch. Ich gebe dir recht, aber peinlich finde ich das nicht. Kritischere Lücken wurden auch zeitnah geschlossen. Bspw. der Bug, sich als root ohne Passwort anzumelden. Der war innerhalb von Stunden beseitigt.
Mich beeindruckt ja immer wieder, das und wie solche Lücken gefunden werden. Laut Beschreibung muss da ja sogar ein absoluter Experte ziemlich lange "gestochert" haben, um die Lücke zu finden.
[...]
P0rn?
Dank Spectre/Meltdown gibt es wesentlich mehr Forschung in die Richtung. Da fallen halt gescheit Doktorarbeiten bei ab. Das für die entsprechende Fehlersuche Nischenwissen notwendig ist, ist auch nicht sooo verwunderlich. Das ist in der Forschung eher üblich, dass die Spezialisierung da extrem ist.
Und von wegen länger auf Seiten verbleiben. Solche Angriffsvektoren werden schwerer ausnutzbar, wenn Daten aktiv verarbeitet werden. Videoplayer oder ähnliches die ständig neue Daten buffern fallen da darunter. Eine statische Loginseite hingegen ist optimal.
Ich muss das Paper noch lesen ab hier Spekulation: Wenn es mit der Technik möglich wäre Sessioncookies zu extrahieren, würde das ganze wesentlich relevanter werden. Javascript für den Angriff unterjubeln auf einer nahezu statischen Seite versuchen Sessions zu kapern.
Viele Gründe endlich mit Fido und Passkeys voran zu machen .. damit zumindest Logins, Transaktionen, Verträge, Dokumente, Geld und vielleicht sogar irgendwann elementare Sprach/Textommunikation in sichereren Händen liegen als unseren hyperCPUs, hyperOS und hyperApps.
Mal sehen wann die ersten Angriffe auf Secure Elements berichtet werden. Spectre/Meltdown wird's da hoff ich mal nicht sein .. meine Erwartung wär ja das das chaotische Drumherum z.B. bei Accountwiederherstellungen bzw. der "sicheren Gruppenbildung innerhalb derer Passkeys weitergereicht werden" den Hauptteil der erfolgreichen Angriffe stellen. Und natürlich obfuscated Zugang von Sicherheitsforschern und Zertifizierung. Schlüsseltausch in einfach vs. sicher wie gehabt.
Das es mit sicheren CPUs oder OS und Apps noch was wird braucht man jedenfalls nicht anzunehmen. Wenn es mal nur Hase und Igel wär'n (beides nette Viecher) die sich da ein Rennen liefern.
wow - 1 Jahr ohne eine Information an die User - nur weil der Fix "instabil" wäre
aber bei Microsoft kommen dann gleich die Apple Jünger raus und motzen, wenn nicht innerhalb von 4 Wochen n Fix da ist oder Microsoft die Lücke als nicht zu problematisch ansieht und sich 2 - 3 Monate Zeit lässt.
aber bei Apple darf ja ruhig das System monate bis jahrelang sperrangelweit aufstehen, das ist ja ok.
aber bei Microsoft kommen dann gleich die Apple Jünger raus und motzen, wenn nicht innerhalb von 4 Wochen n Fix da ist oder Microsoft die Lücke als nicht zu problematisch ansieht und sich 2 - 3 Monate Zeit lässt.
aber bei Apple darf ja ruhig das System monate bis jahrelang sperrangelweit aufstehen, das ist ja ok.
Das Problem in Safari zu fixen behebt doch den Fehler in der Hardware nicht? Wenn sich das mit ein paar webkit bugs schon ausnutzen lässt steht das System doch komplett offen?
Das ist ein gigantischer Angriffsvektor um sensibelste Informationen zu bekommen, besonders wenn man lokalen Zugriff auf das Gerät hat?
Microsoft hat doch auch nicht nur den Internet Explorer gepatcht, sondern einen Haufen microcode Updates entwickelt die den ganzen Prozessor verkrüppelt haben. Natürlich hat Apple kein Interesse diese Lücke vernünftig zu schließen...
Da ein hohes kriminelles Interesse an Apples Sicherheitskonzepten hängt, nicht zuletzt auch auf staatlicher Ebene, sind alle Geräte mit entsprechender Hardware wohl als unsicher zu betrachten. Nur eine Frage der Zeit bis der Exploit dann in der breiten Masse ankommt. Besonders die Zertifizierung für Umgebungen mit hoher Sicherheit hat sich damit wohl erledigt.
Man muss solche Lücken auch immer als Basis sehen. Es wurde demonstriert, dass auch Apples M-Prozessoren anfällig für Side Channel Angriffe sind und dass sich diese aus dem Browser heraus durchführen lassen. Da kann jederzeit eine verfeinerte Version kommen und deshalb erwarte ich, dass solche Lücken trotzdem ernstgenommen werden.
Darüber hinaus wird Safari ja auch in Apps verwendet. Wer weiß, ob sich darüber nicht auch Daten abgreifen lassen. Oder der entsprechende Javascript-Code könnte über Werbung auf eine populärere Seite eingeschleust werden. Die ungefähr 5 Minuten brechen ja nicht jedes Mal neu an, wenn man auf einen anderen Artikel wechselt oder Ähnliches. So lange das als ein Gerät erkannt wird, kann man das Profiling fortsetzen. Eventuell gibt es auch mehr Muster als die Forscher bisher erkannt haben und die Zeit kann zukünftig signifikant verkürzt werden.
Es geht nicht darum, dass sie alles stehen und liegen lassen und einen extra Hotfix raushauen, aber ein Jahr und immer noch kein brauchbarer Patch ist einfach nie gut.
Wie also bei allen Schwachstellen dieser art erstmal ein eher akademisches Problem. Aber immerhin eine Grundlage für die Hersteller ihre CPUs zu verbessern.
Finde die Arbeit solche Lücken zu finden und zu veröffentlichen sehr wichtig
Das Problem in Safari zu fixen behebt doch den Fehler in der Hardware nicht? Wenn sich das mit ein paar webkit bugs schon ausnutzen lässt steht das System doch komplett offen?
Das ist ein gigantischer Angriffsvektor um sensibelste Informationen zu bekommen, besonders wenn man lokalen Zugriff auf das Gerät hat?
Es muss halt Code auf dem System ausgeführt werden können. Javascript bzw. Webasm ist da eine gute Methode. Wobei da derzeit das System nicht komplett offen ist, sondern der Angriff nur in Speicherbereichen des Selben Renderprozesses funktioniert (über mehrere Tabs hinweg, weil nicht jeder Tab/Request einen eigenen Prozess bekommt).
Komplett offen ist das System nicht.
Und wenn Code, der die Lücke laufen lässt auf einem Max läuft, dann hat der Angreifer sowieso Code im Userspace laufen und kann da in der Regel mehr Daten extrahieren, als über die gezeigte Schwachstelle. Selbst bei Apps in iOS dürfte der Seitenkanalangriff in der Schwere wesentlich weniger wichtig sein.
Bei Servern, die mehrere VMs bzw. Container laufen lassen sind solche Lücken bedeutender. Da sind solche Lücken geeignet um Informationen von Host bzw. fremden Instanzen abzugreifen. Da die ARM Macs aber seltener in Serverrollen sind, ist das Imho weniger relevant.
Microsoft hat doch auch nicht nur den Internet Explorer gepatcht, sondern einen Haufen microcode Updates entwickelt die den ganzen Prozessor verkrüppelt haben. Natürlich hat Apple kein Interesse diese Lücke vernünftig zu schließen...
µCode kam von Intel und AMD, da hat Microsoft nur den Anteil, dass sie die Updates über Winupdate ausspielen, was MacOS und die restliche *nix Welt aber in der Regel auch machen.
Warum gibt es eigentlich für Software keine (einfache) Option zu sagen, das soll jetzt auf einen Kern ohne Spekulative Ausführung laufen wenn verfügbar, damit könnte man all diese Probleme Umgehen, einfach indem man den Teil der mit Sensiblen Daten arbeitet auf den schwächeren CPU Cores laufen lässt... Und wirklich sensibles sollte den TPM am besten nie verlassen (Was schwierig ist wenn dieser oft emuliert wird, auf einer CPU mit Spekulativer Ausführung )
Ergänzung ()
Piktogramm schrieb:
Bei Servern, die mehrere VMs bzw. Container laufen lassen sind solche Lücken bedeutender. Da sind solche Lücken geeignet um Informationen von Host bzw. fremden Instanzen abzugreifen. Da die ARM Macs aber seltener in Serverrollen sind, ist das Imho weniger relevant.
Diesbezüglich würde mich ja mal interessieren wie NitroTPM in AWS funktioniert, ist das einfach ein Process auf dem Host an den man per Seitenkanal kommen könnte (und der die Daten übertragen muss wenn die VM auf einem anderen Host läuft) oder ist das eine dedizierte Maschine/Cluster die dann für alle VMs im RZ der TPM ist...
Ich glaube tatsächlich dass zumindest die Core Vpro, ryzen Pro, threadripper pro und Xeon/EPYC CPUs einen echten coprozessor für TPM Aufgaben haben, welcher im package integriert ist. Beim Rest ist die Sache mit dem fTPM halt so eine Sache
Kann mir auch gut vorstellen dass Apple und ARM im allgemeinen ebenfalls nur emulieren und nicht nur die nicht pro Varianten von AMD und Intel ^^
Ich dachte auf dem iPhone ist Safari die einzige verfügbare Browser-Engine!? Es gibt nur verschiedene Frontends, aber im Hintergrund werkelt immer Safari. Oder hat sich das mittlerweile geändert?
Warum gibt es eigentlich für Software keine (einfache) Option zu sagen, das soll jetzt auf einen Kern ohne Spekulative Ausführung laufen wenn verfügbar, damit könnte man all diese Probleme Umgehen, einfach indem man den Teil der mit Sensiblen Daten arbeitet auf den schwächeren CPU Cores laufen lässt... [...]
Alle Prozessoren die irgend ein modernes Betriebssystem laufen lassen, egal ob Windows, *nix haben spekulative Ansätze. Selbst die lahmsten ARM 5x Cortex mit ihren InOrder Prinzip spekulieren fröhlich. Alle Prozessoren ohne jedwede Spekulation sind auf der anderen Seite derart langsam, dass sie heutzutage allenfalls als lahme µController Verwendung finden. Bei ARM hat ja bereits der Coretex M3 branch speculation..
Und sicherheitsrelevante Daten auf spezielle, nicht spekulative Prozessoren schieben ist total utopisch. Jeder verschlüsselte HTTP Request braucht zwangsweise das Schlüsselmaterial. Browser arbeiten fröhlich mit Cookies und gecachten Daten. Da müsste nach deiner Vorstellung also quasi alles auf den aller lahmsten Kernen laufen. Kernelspace vom Betriebssystem? Ab auf die Lahmarschkerne! Browser? Entdecke die Langsamkeit!
@Piktogramm stimmt, mein Fehler, aber der Punkt bleibt ja die In Order sowohl bei x86 als auch ARM sind nicht anfällig, während die Out of Order es sind... Auch hier werden die S SiPs nicht genannt obwohl auch auf der Apple Watch Webseiten angezeigt werden können.
@AlphaKaninchen
Die letzten x86er die InOrder waren, waren glaub Bonell bzw. Saltwell und das bei denen keine Bugs gefunden werden liegt wohl vor allem daran, dass die vor zehn Jahren eingestellt worden. Da forscht schlicht und ergreifend niemand dran, was aber nicht heißt, dass da keine Bugs vorhanden sind.
Und bei ARM, die aktuellen A5x0er sind zwar InOrder, bekommen ihre Pipelines ohne spekulative Fetches und Ausführung auch nicht gescheit gefüllt: https://chipsandcheese.com/2023/10/01/arms-cortex-a510-two-kids-in-a-trench-coat/
Tendenziell, waren bisher nur OoO Systeme betroffen, es würde mich aber nicht wundern, wenn InOrder Systeme zunehmen auch betroffen sind, wenn sie sich vom dogmatischem InOrder lösen um Performance zu schinden.
Das die Apple Watch nicht genannt wurde, die wird im Paper nicht erwähnt, also war sie kein Untersuchungsgegenstand. Die Nichtnennung ist also kein Indiz, dass deren SoC nicht betroffen ist. Zudem die Apple die Tempest Cores aus dem A12 für den S8 SoC der Watch wiederverwendet. Tempest ist OoO.
Ich dachte auf dem iPhone ist Safari die einzige verfügbare Browser-Engine!? Es gibt nur verschiedene Frontends, aber im Hintergrund werkelt immer Safari. Oder hat sich das mittlerweile geändert?
Meines Wissens nach sollte das mit iOS 17 geändert werden, da sollte der Zwang zur Nutzung der WebKit-Engine wegfallen.
Ob das wirklich passiert ist weiß ich nicht, bin einfach mal davon ausgegangen das es der Fall ist.
)
