Gepatcht werden muss natürlich zeitnah, was ich aber als "Wochen" und nicht als "Tage" auffasse.
Theoretisch ist der Angriffsvektor da. Damit besteht die Möglichkeit aus seiner Netcup VM auszubrechen und Daten anderer VMs anzusehen - läuft ja auf dem selben Prozessor. Wenn meine VM jetzt Daten verarbeitet (Adressen, Mailadressen, Kontodaten, Nutzerzugänge, Betriebsvorgänge) und du könntest mitlesen - das gefällt keinem. Deshalb sind "Tage" besser als "Wochen"...
Theoretisch ist der Angriffsvektor da.
Den gibt es immer. Hinreichend komplexe Systeme verfügen immer über Sicherheitslücken. Einige davon sind garantiert einfacher auszunutzen als Spectre, für das eine Implementierung wohl als verdammt schwierig gilt. Meltdown betrifft KVM wohl nicht.
Wenn meine VM jetzt Daten verarbeitet (Adressen, Mailadressen, Kontodaten, Nutzerzugänge, Betriebsvorgänge) und du könntest mitlesen
Kann ich nicht. Weil es für Spectre keine Implementierung gibt. Und da diese als sehr schwer gilt, wird das wohl auch noch eine Weile so bleiben. Nicht, dass man nicht patchen sollte. Das übrigens nicht nur einmal, da es heißt, dass wohl noch nicht alles im grünen Bereich ist.
Ich bin bei dem ganzen Thema allerdings etwas anderer Meinung als felix. Zum einen bin ich nicht sicher, ob das alles so dringend sein muss, da noch niemand von Implementierungen spricht, die die Lücke nutzen. Gepatcht werden muss natürlich zeitnah, was ich aber als "Wochen" und nicht als "Tage" auffasse. Ich werde meine Server sicher diese Woche noch patchen, mache mir deshalb aber keine schlaflosen Nächte.
Ich finde es gut, dass netcup hier zügig reagiert. Die Entscheidung, wie wichtig die Daten sind, und die Abwägung, wie schnell man patcht, kann nur jeder für sich beantworten. Der Provider kann einem das nicht abnehmen und hat die Aufgabe, von seiner Seite aus alles zu tun, um für die bestmögliche Sicherheit zu sorgen. Dann hat er seine Pflicht getan. Für weitere Updates auf den (virtuellen) Servern selbst muss dann jeder Kunde selbst sorgen und kann das natürlich nach eigenen Vorstellungen tun und planen.
Was das Ausnutzen der Lücke angeht: Wenn Implementierungen bekannt werden, ist es i. d. R. zu spät, denn dann reden wir über die Ausnutzung der Lücke auch in der Vergangenheitsform. Je mehr Lücken geschlossen sind, bevor sie ausgenutzt werden, umso besser.
Weil es für Spectre keine Implementierung gibt. Und da diese als sehr schwer gilt, wird das wohl auch noch eine Weile so bleiben.
Wobei man nicht weiß, wie lange die Lücke im Verborgenen bereits bekannt ist. Insofern könnte es durchaus funktionierende Exploits für alles geben, eventuell seit Jahrzehnten. Man weiß es einfach nicht.
Ich finde, dass netcup mit einem zügigen Patch absolut richtig reagiert.
wobei die Meltdown Geschichte um es sarkastisch zu formulieren, hausgemacht ist;
es sollte einem schon zu denken geben, daß bereits der i386er mit 64 TByte virt. Speicher umgehen konnte
(auch der i286er mit 16-bit auch deutlich mehr virt. Speicher adressieren konnte als damals überhaupt denkbar war: 1 GByte)
aber keine einzige OS-Implementierung - auch nicht Linux/Unix - das auch nur in Ansätzen verwendete;
ich will hier Intel nicht in Schutz nehmen, aber Schuld an dem Ganzen hat hier Intel keine;
auch sollte man sich hinterfragen, wie es sein kann, daß unter einem aktuelles OS - z.B. Windows 10 - Anwendungen kürzere Laufzeiten haben, wo doch das OS - der OS-Kern - deutlich schwerfälliger ist, als ältere OS Varianten - z.B. Windows XP;
ebenfalls hinterfragen sollte man sich, bei Betrachtung der CPU-Spezifikationen aktuellerer CPUs, was es mit dem 'Execute Disable Bit' auf sich hat ...
(es wär mir neu, daß ein Datensegment ausführbar wäre - aus der Reinheit der Lehre des Protected-mode aus Zeiten des i386er, der von einem 'Execute Disable Bits' nichts wußte ...)
Hat zufällig gerade noch wer Probleme mit dem WCP? Es lädt bei mir leider nicht...
Edit: Ah sehe gerade auf der Statusseite einen Eintrag, alles easy 
Hat zufällig gerade noch wer Probleme mit dem WCP? Es lädt bei mir leider nicht...
Edit: Ah sehe gerade auf der Statusseite einen Eintrag, alles easy
Ich gehe davon aus es ist das WCP für die alten Tarife gemeint?! Das erreiche ich aktuell nur mit ewigen Ladezeiten.... Die neue Umgebung funktioniert bei mir aber einwandfrei...
Edit: Ah sehe gerade auf der Statusseite einen Eintrag, alles easy
Der Status ist aber doch von Gestern und auch schon behoben...
Ich gehe davon aus es ist das WCP für die alten Tarife gemeint?! Das erreiche ich aktuell nur mit ewigen Ladezeiten.... Die neue Umgebung funktioniert bei mir aber einwandfrei...
Meine Webhostingtarife stammen aus 2016/2017 - ob das nun alte oder neue Umgebung ist kann ich leider garnicht sagen... Aktuell erhalte ich 5XXer Fehlermeldungen auf webhostingcontrolpanel.de und das ccp ist im Produktbereich auch sehr träge. Mal abwarten
ich will hier Intel nicht in Schutz nehmen, aber Schuld an dem Ganzen hat hier Intel keine;
intel hat für ein Security Problem in ihren Prozessoren keine Schuld, sondern die OS-Entwickler, weil sie nicht alle Kapazitäten des Prozessors nutzen?
Auch das mit den schnelleren Laufzeiten... Techniken verändern sich, $Dinge werden optimiert. Das hat eigentlich seine Richtigkeit so.
I don't get it.
intel hat für ein Security Problem in ihren Prozessoren keine Schuld, sondern die OS-Entwickler, weil sie nicht alle Kapazitäten des Prozessors nutzen?
Auch das mit den schnelleren Laufzeiten... Techniken verändern sich, $Dinge werden optimiert. Das hat eigentlich seine Richtigkeit so.
Genau; nur das mit den schnelleren Laufzeiten ... und Techniken verändern sich, widerspricht sich etwas ...
oder anders gesagt: die Laufzeiteinbußen, welche diese Bugfixes jetzt mit sich bringen,
wurde vorher durch Schlamperei gewonnen ...
Hay,
wurde vorher durch Schlamperei gewonnen ...
richtig. Die Laufzeiteinbußen kommen, weil die OS jetzt um Intels Schlamperei herumprogrammieren müssen. Ob es mit der Prüfung durch die CPU selbst jetzt schneller wäre als durch angepasste Software, ist erst einmal Spekulation - die CPU-interne Prüfung wird auch ein paar Taktzyklen zusätzlich brauchen.
Bitte mal mit dem Bug als solchem beschäftigen... die CPU macht was von sich aus, um besonders schnell daher zu kommen und verzichtet auf eine nachträgliche Prüfung, ob das überhaupt so erlaubt ist, sobald sie "geraten" hat, wie es im Code weitergeht.
Der Pentium-Bug von 1990(?) war dann auch nicht Intels Schuld - der verdammte, nachlässige Programmierer hätte ja nicht den FDIV-Befehl benutzen müssen, das kann man ja auch zu Fuß ausrechnen, statt der CPU die passende Instruktion zu geben. Zwei CPUs habe ich damals getauscht bekommen... da ist Intel noch anders mit solchen Themen umgegangen.
CU, Peter
+1 für CmdrXay.
Ich sehe da auch keine Schuld bei den OS-Devs, und auch keinen Widerspruch.
Hay,
richtig.
Die Laufzeiteinbußen kommen, weil die OS jetzt um Intels Schlamperei herumprogrammieren müssen. Ob es mit der Prüfung durch die CPU selbst jetzt schneller wäre als durch angepasste Software, ist erst einmal Spekulation - die CPU-interne Prüfung wird auch ein paar Taktzyklen zusätzlich brauchen.
mit Schlamperei meinte ich übrigens nicht die von Intel ...
macht einen Unterschied, ob Du der Schlamperwei wegen alles nur FLAT machst,
weil performant oder segmentierst und damit die internen Prüfmechanismen¹ der CPU richtig ausspielst;
ist es ja nicht Intel alleine sondern auch ARM und bei AMD ist man sich auch nicht sicher,
ob auch hier Probleme existieren ...
nebenbei: der Vergleich mit dem FDIV-Bug hinkt
¹ die Existenz des 'Execute Disable Bits' machte erst Microsoft notwendig;
Was mich interessiert ob die neue Generation (2018) von Intel Prozessoren auch diesen Bug haben wird. 
Wenn du über Meltdown sprichst, ist defakto aber nur Intel betroffen. ARM/AMD und co sind nur von Spectre betroffen, nicht Meltdown.
Davon mal ganz abgesehen, ist es aktiv ein Problem, was die CPU als solche verursacht. Ein Problem, dass dadurch entsteht, dass der Hersteller auf die Packung schreiben will, dass mit seiner CPU alles super duper toll schnell ist.
Die OS-Kernel gehen zu recht davon aus, dass die CPU ihren Job tut, und nicht wild in der Gegend rum rät. Vor allem geht der Kernel zurecht nicht davon aus, dass die CPU bei diesem Raten mal eben den Security-Check weg lässt.
So seltsam es auch scheinen mag, aber die Testroutine
https://github.com/ionescu007/SpecuCheck
welche einem sagt, ob man tatsächlich mit Meltdown (unter anderem) ein Problem hat,
läuft mit älteren Windows Versionen gar nicht ...
Ist das wirklich ein Problem der CPU?
(z.B. WinXP kann mit SSE gar kein Problem haben,
es verwendet diesen Instruction Set gar nicht; WinXP x64 hingegen schon)
welche einem sagt, ob man tatsächlich mit Meltdown (unter anderem) ein Problem hat,
läuft mit älteren Windows Versionen gar nicht ...
Ist das wirklich ein Problem der CPU?
Uiuiuiuiui, da glüht der Aluhut.
Nein, Spaß bei Seite und mal ehrlich: Es ist ein Bug, den die CPU mit einem "Feature", das sie anbietet, auslöst.Daran gibt es einfach nichts zu rütteln, da kannst du noch so windige Argumente bringen.
Wenn dieses Feature genutzt wird, kommt es zu einem ziemlich unschönem Bug. Ende der Gesichte.
Warum sollte der Entwickler des Testes eine seit mehreren Jahren als deprecated einzustufende Windows Version unterstützen?
Wie du ja bereits sagst läuft das Tool überhaupt nicht. Dann von einer "Unverwundbarkeit" zu sprechen ist als würdest du ohne Messwerkzeug in eine Säure greifen weil "die Flüssigkeit ja aussieht wie Wasser, und da ich nichts zum Messen habe, was mir was anderes anzeigt, muss es ja Wasser sein".
Um mal das Thema zu wechseln (ich glaube die Mitarbeiter können Meltdown und Spectre nicht mehr hören 
).
Mir ist aufgefallen, dass das Routing von netcup weiter auf Anexia umgestellt wurde. Der Standort in Frankfurt ist bereits nur noch über Anexia zu erreichen, selbst von Nürnberg aus:
traceroute to 188.68.63.xx (188.68.63.xx), 30 hops max, 60 byte packets
1 gw01.netcup.net (46.38.225.2) 0.431 ms 0.406 ms 0.381 ms
2 ae3-4018.bbr01.anx84.nue.de.anexia-it.net (144.208.211.26) 0.404 ms 0.424 ms 0.399 ms
3 ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141) 4.004 ms 4.115 ms 4.261 ms
4 188.68.63.xx (188.68.63.xx) 3.552 ms 3.527 ms 3.523 msSoll das RZ in Nürnberg auch komplett über den Anexia Backbone angebunden werden oder werdet ihr auch weiterhin eigene Transit-Provider haben und an Knoten wie dem DE-CIX vertreten sein?
Wie kann ich das Logging für ACPI Shutdowns/Neustarts unter Debian einschalten?
