Intel - Hardwarebug

Mit Ausnahme der ersten Generation Atoms, aber ich kann mir schwer vorstellen, dass die noch jemand produktiv in öffentlich erreichbaren Maschinen einsetzt. Zumindest nicht in Maschinen die eine reale Chance haben überhaupt jemals einen Kernelpatch (Stichwort: Windows XP) oder bei Embedded Devices ein entsprechendes Firmware-Upgrade zu bekommen.

Zu Quark finde ich keine belastbare Aussage, aber da sie ebenfalls In-Order Kerne, entfernte Verwandte des guten 80486, sind, sind sie vermutlich ebenfalls nicht betroffen. Aber Quarks dürften abseits irgendwelcher IoT-Anwendungen, wo wir wieder bei sowieso nie kommenden Firmware-Updates sind, keine nennenswerte Verbreitung haben.
 
Ganz davon ab darf man nicht vergessen, dass das keine Remote-Lücke ist. Ist also kein Grund in akute Panik zu verfallen. Wer sich gerade nur in die Hose machen sollte sind VM-Anbieter und die sollten im Grunde sofort patchen wenn möglich..
 
Jetzt stell ich mal eine provokante Frage:

Könnte es theoretisch möglich sein, das Meltdown und Spectre gewollte Backdoors sind und diese willentlich und vorsätzlich implementiert wurden?
 
ralli schrieb:
Könnte es theoretisch möglich sein, das Meltdown und Spectre gewollte Backdoors sind und diese willentlich und vorsätzlich implementiert wurden?
Zum Vergrößern anklicken....

Das schöne an Verschwörungstheorien ist: Sie funktionieren meistens. Jedes Sicherheitsproblem kann man auch als "Absicht" auslegen und man kann nie beweisen, dass es keine Absicht war.
 
Falls die Vermutung, dass wenigstens Spectre ein Designfehler ist, den x86 aus früheren Rechnern übernommen hat, stimmt, dann ist das unwahrscheinlich. Die Vernetzung von allem möglichen Firlefanz selbst bei Oma Lieschen war in den 80ern noch kein Thema.
 
Spectre betrifft ja auch nicht nur x86 oder nur Intel. Im Prinzip betrifft es jede CPU mit spekulativer Ausführung in der Art, also auch ARM. Vermutlich jede CPU mit Out-of-Order Design, aber relevant im Massenmarkt sind ja nur x86 und ARM.
 
ralli schrieb:
Könnte es theoretisch möglich sein, das Meltdown und Spectre gewollte Backdoors sind und diese willentlich und vorsätzlich implementiert wurden?
Zum Vergrößern anklicken....
Wenn ich als Autoverkäufer ein Auto knackbar machen möchte, erledige ich es mit einer Möglichkeit in Richtung Ersatzschlüssel, nicht mit einem Loch in der Tür :)
 
Mein Problem ist, das ich nur äußerst selten an Zufälle glaube. Allerdings scheinen mir die Einwände dagegen ziemlich plausibel zu sein.
 
ralli schrieb:
Jetzt stell ich mal eine provokante Frage:

Könnte es theoretisch möglich sein, das Meltdown und Spectre gewollte Backdoors sind und diese willentlich und vorsätzlich implementiert wurden?
Zum Vergrößern anklicken....


Yeahhh ... Putin steckt dahinter! .. und natürlich Trump

Aber die machen die Rechnung - ohne die Deutschen ...
denn von der Saar stammte nicht nur Honecker, sondern auch jemand der nun an einem CPU-Durchdringungsgesetz arbeitet...
 
Muss der Angreifer eigentlich lokal auf dem Rechner angemeldet sein (mit user-Rechten) oder sind auch remote-Angriffe denkbar?
 
Schwer zu sagen. Theoretisch könnte man sicher durch den Javascript-JIT im Browser etwas machen. Praktisch weiß ich es nicht.
 
Vril schrieb:
Yeahhh ... Putin steckt dahinter! .. und natürlich Trump

Aber die machen die Rechnung - ohne die Deutschen ...
denn von der Saar stammte nicht nur Honecker, sondern auch jemand der nun an einem CPU-Durchdringungsgesetz arbeitet...
Zum Vergrößern anklicken....
Ich hab es geahnt, it's not a bug it's a feature.:D
 
midnight schrieb:
Muss der Angreifer eigentlich lokal auf dem Rechner angemeldet sein (mit user-Rechten) oder sind auch remote-Angriffe denkbar?
Zum Vergrößern anklicken....
Theoretisch kann ein unpriviligierter Prozess auf den Speicher des Kernels zugreifen, ich denke somit sollten Remote-Angriffe machbar sein (natürlich nur über Bugs in anderer Software).
 
In dem Sinne ist jede Lücke Remote, wenn es denn eine andere Remote-Lücke gibt, um die lokale Lücke auszunutzen :D An sich ein böser Bug, aber das Hauptproblem (für Intel) ist (nach dem Patch) weniger die Sicherheitslücke, sondern mehr, dass im Server-Umfeld Intel in Sachen Performance hinter AMD rutscht. Hier muss Intel erst mal zeigen, dass sie das mit gefixter Hardware wieder aufholen können.
 
FreeBSD:
Code: 
syctl net.bpf_jitter.enable ?
Beschreibung:
Code: 
sysctl -d net.bpf_jitter.enable: enable BPF JIT compiler
Dann gibt es ja auch noch das:
Code: 
sysctl -d net.bpf.zerocopy_enable: Enable new zero-copy BPF buffer sessions
 
Yamagi schrieb:
wie VW die Arschkarte in Sachen Diesel gezogen hat, hat Intel es für löchrige CPUs getan.
Zum Vergrößern anklicken....
vielleicht gibt es dann neben SW-Flicken demnächst auch gute Tauschangebote für alte CPUs gegen neu entwickelte mit sauberem Design?
...so ein klein wenig Hoffnung schadet ja nicht...

Zu dem Problem selbst. Das verstehe ich nicht richtig. Jeder Kernel arbeitet doch anders und dann müssen ja auch noch Programme im Userland gestartet werden, die diese Lücken auswerten. Oder? Eine solche Schadsoftware ist bisher nicht bekannt? Es wurde nun nur die Möglichkeit für eine solche SW erkannt?

Ist nicht das neuere Modell bei OpenBSD, Speicher im Kernel irgendwie randomisiert zuzuweisen, genau eine Entgegnung darauf? Also würde solch ein Fehler sich in OpenBSD denn überhaupt ausnutzen lassen?

Und dann: was kann ich denn selbst machen, wenn ich keine Patches haben will, weil ich um die Performance meines Systems mehr fürchte, als um die mögliche Sicherheit durch diesen Fehler? Einfach nicht mehr Updaten? keine neueren Versionen ab heute mehr einspielen?
 
pit234a schrieb:
Zu dem Problem selbst. Das verstehe ich nicht richtig. Jeder Kernel arbeitet doch anders und dann müssen ja auch noch Programme im Userland gestartet werden, die diese Lücken auswerten. Oder? Eine solche Schadsoftware ist bisher nicht bekannt? Es wurde nun nur die Möglichkeit für eine solche SW erkannt?
Zum Vergrößern anklicken....
Es gibt inzwischen ein paar Proof of Concept Implementierungen für Linux. Generell aber ja, der Schadcode muss auf den jeweiligen Kernel angepasst sein und in das Zielsystem eingeschleust werden. Problematisch ist bei sowas gerne die Verkettung von Lücken. Also das beispielsweise Malware dieses Problem nutzt um Informationen aus dem gerade laufenden Windows Kernel zu angeln, die dann für den eigentlichen Angriff genutzt werden. Oder das es jemanden gelingt ein Javascript zu schreiben, was im Zusammenspiel mit Fehlern in der Javascript-Engine des Browser Passwörter aus dem Kernel oder sogar anderen Prozessen ausliest.

Im Moment dürften aber in erster Linie große VM-Setups betroffen sein, wie sie zum Beispiel Amazon AWS einsetzt. Mit Pech ist es nur noch eine Sache von Stunden oder Tagen, bis es zuverlässigen, auch ohne besondere Kenntnisse zu nutzenden Code gibt, mit dem aus der eigenen VM ausbrechen kann. Nicht ohne Grund haben Amazon und Microsoft ja schon angekündigt die komplette Cloud in den nächsten Tagen zu rebooten.

pit234a schrieb:
Und dann: was kann ich denn selbst machen, wenn ich keine Patches haben will, weil ich um die Performance meines Systems mehr fürchte, als um die mögliche Sicherheit durch diesen Fehler? Einfach nicht mehr Updaten? keine neueren Versionen ab heute mehr einspielen?
Zum Vergrößern anklicken....
Linux kannst du mir der Option 'nopti' booten. Zu FreeBSD gibt's noch keine Aussage, aber auch dort wird es sehr wahrscheinlich abschaltbar sein. Wie es unter Windows sein wird, weiß ich nicht. Aber meist kann man Dinge unter Windows ebenfalls abschalten, muss dafür aber oft etwas in die Innereien hinabsteigen.
 
pit234a schrieb:
Ist nicht das neuere Modell bei OpenBSD, Speicher im Kernel irgendwie randomisiert zuzuweisen, genau eine Entgegnung darauf? Also würde solch ein Fehler sich in OpenBSD denn überhaupt ausnutzen lassen?
Zum Vergrößern anklicken....

Ist zu Vergleichen mit:
Code: 
chmod +r /dev/kmem
Der Angriff wird stark erschwert, aber der RAM wird wie ein Buch gelesen :)

Vorsicht: Halbwissen
 
Den größten Clusterfuck sieht mal aber natürlich mal wieder in der wunderbaren Windows-Welt: https://twitter.com/GossiTheDog/status/948833769963900929 Weil Virenscanner im Kernelmode rumrühren, müssen sie mit Microsofts Kernelpatch kompatibel sein, sonst schmiert Windows bereits beim Boot per Bluescreen ab. Da Windows Update aber erstmal nicht wissen kann ob ein Virenscanner kompatibel ist, muss der Virenscannerhersteller einen Key in der Registry hinterlegen, an dem Windows Update erkennt, ob die Kompatibilität gegeben ist. Und erst wenn es das tut spielt es den Patch ein.
 
Yamagi schrieb:
Im Moment dürften aber in erster Linie große VM-Setups betroffen sein, wie sie zum Beispiel Amazon AWS einsetzt. Mit Pech ist es nur noch eine Sache von Stunden oder Tagen, bis es zuverlässigen, auch ohne besondere Kenntnisse zu nutzenden Code gibt, mit dem aus der eigenen VM ausbrechen kann. Nicht ohne Grund haben Amazon und Microsoft ja schon angekündigt die komplette Cloud in den nächsten Tagen zu rebooten.
Zum Vergrößern anklicken....

Soweit ich weiß kann man mit beiden Lücken-Typen nur Daten beliebig aus dem RAM lesen, aber nicht modifizieren. Das ist natürlich schon schlimm genug, wenn der VM-Nachbar mal eben dein SSH-Passwort/Keyfile auslesen kann, wenn du gerade aktiv bist. Ist natürlich auch ein Ausbruch aus der VM, nur halt nicht direkt mit Shell und so einem Spaß.
 
Hallo

wie schaut es eigentlich mit Routern und ähnlichem aus (da ja auch ARM betroffen sein soll, MIPS weiß ich nicht). Ist so ne Fritzbox nicht ein interesssanteres Ziel für automatisierte Angriffe als ein Privat-PC?

Serie300
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben