Um welchen Bug es sich genau handelt ist nämlich zu diesem Zeitpunkt gar nicht klar. Nicht weil wir alle so blöd sind und die genauen Details und Fakten nicht nennen wollen, sondern weil sie bisher gar nicht veröffentlicht wurden. In diesem Sinne ist es natürlich richtig, dass viele Dinge hier Spekulation sind und am Ende auch falsch sein könnten. Allerdings muss man sich im Klaren darüber sein, dass das gewählte Vorgehen in diesem Fall* sehr eindeutig auf einen schwerwiegenden Fehler hinweist. Es gibt ausreichend Indizien, die für mich jedenfalls die Spekulationen nur stärken und kaum schwächen.
Wirklich Klarheit um was es genau geht, wird man erst am 4. Jänner um 12 Uhr UTC (also 13 Uhr Mitteleuropäischer Zeit) haben. Bis dahin wird der Bug unter Verschluss gehalten, was nicht nur Entwicklern Zeit gibt, die Sicherheitsmängel zu beheben sondern auch jenen Unternehmen die Erstellung eines Zeitplanes erlaubt, die davon am stärksten betroffen sind.
Gehen wir mal davon aus, dass es sich dabei wirklich um einen Hardware-Fehler im virtuellen Speichersystem handelt, vielleicht auch in der Virtualisierung VT-x. Dann ist es sehr wahrscheinlich, dass ein großer Teil aller laufenden Cloud-Lösungen genauso wie viele VPS davon betroffen sind. Und nicht nur das: wenn es sich wirklich um einen Rowhammer-Fehler handelt, dann sind potenziell viel mehr Systeme betroffen, weil man diese Sicherheitslücke auf mehreren Wegen ausnutzen kann, zum Beispiel sogar in einer JavaScript-Umgebung. Das betrifft in erster Linie wohl Server mit Node.js Komponenten, aber es impliziert auch, dass so ein Angriff über jeden herkömmlichen Browser möglich sein könnte. Aber das ist leichter gesagt als getan.
*) Mit Vorgehen im Fall meine ich folgendes: es handelt sich hier um Änderungen an einem Teil Code, der nicht mal schnell in ein paar Wochen komplett umgeschrieben wird wenn das nicht unbedingt nötig ist. Meist vergehen mehrere Monate wenn nicht gar Jahre, bis derart massive Änderungen vollzogen werden. Kurioserweise gibt es auch Reboots von VM Instanzen zum Beispiel bei Amazon oder Microsoft, was ebenfalls diesem Bug zugeschrieben wird. Interessant ist auch, dass jene Leute der Technischen Universität Graz nicht nur an den Änderungen des Kernels mitgearbeitet haben, sondern scheinbar unabhängig davon einen neuen Bug veröffentlicht haben (Zitat: "Our Rowhammer enclave can be used for coordinated denial-of-service attacks in the cloud and for privilege escalation on personal computers.").
Wenn die Spekulationen richtig sind, ist dies alles Teil einer hastig choreographierten Panikreaktion, um die Sicherheit der Systeme gewährleisten zu können bevor Informationen über die Schwachstelle öffentlich werden.
Abschließend den Geschwindigkeitseinbruch betreffend: es geht hier darum, dass die Performance von system calls leidet weil der CPU Cache der Adressen speichert mit jedem neuen call geleert werden muss. Wenn man also unter Linux einen Benchmark nutzt der fast ausschließlich das tut, dann werden die Einbußen natürlich ziemlich groß sein. Mich überraschen da auch 50-60% keineswegs, schließlich setzt man damit Methoden (und Tricks) außer Kraft die CPUs auf Kosten der Sicherheit beschleunigen. In der Praxis dürfte das Problem wesentlich geringer sein, aber selbst 5% oder 10% können unter bestimmten Umständen zum großen Problem werden.
