Meltdown

Vorab: Frohes Neues Jahr!

Aus gegebenem Anlaß ein kurzes Statement zum Computerproblem »Meltdown« (und »Spectre«).

Es ging letzten Donnerstag ja sogar durch Funk und Fernsehen (ab 00:14:53):

Tja … Die Art und Weise, wie die Prozessoren in Computern (PCs, Laptops; ja, selbst Smartphones sind z. T. betroffen) in den letzten 10 Jahren immer leistungsfähiger wurden, hat leider einen unerwünschten Nebeneffekt, denn sie öffnet auf vielen Systemen ein Sicherheitsloch: Bei Intel-Prozessoren ein größeres, bei anderen ein nicht unerhebliches — oder gar keines, siehe Raspberry Pi (da gibt’s auch eine anschauliche Beschreibung des eigentlichen Problems; allerdings auf Englisch).

Ohne ins Detail gehen zu wollen nur soviel: auch unsere Serversysteme sind von den »Meltdown« und »Spectre« getauften Problemen betroffen. Dies bedeutet ein wenig Arbeit für uns, denn alle gut 50 virtuellen Maschinen sowie die auf verschiedene Rechenzentren verteilten ca. 10 physischen Serversysteme, auf denen jene VMs laufen, müssen aktualisiert, und dabei neu gestartet, werden. Da auf jedem physischen Serversystem mehrere VMs laufen, wir aber nicht in allen Rechenzentren mehrere Serversysteme haben und zur Absicherung sowieso jedes System neu gestartet werden muß, werden einige Dienste kurzzeitig ausfallen. Die Arbeiten werden voraussichtlich in den Abendstunden bzw. an Wochenenden vorgenommen werden.

Wichtig: Das Freifunknetz an sich sollte in der Zeit weiterhin funktionieren ;-)

Aktuell ist die Faktenlage noch etwas unklar, und daher auch noch keine konkreteren Pläne vorhanden; die Entwickler der generischen Virtualisierungslösung QEMU schreiben zum Beispiel, daß über die »Meltdown«-Lücke aus virtuellen Maschinen kein Zugriff auf Speicher des Serversystems (des sog. Hypervisors) möglich wäre. Auch die Virtualisierungstechnik Xen (worauf z. B. die Amazon-Wolke setzt) meldet, daß bei hardware-gestützter Virtualisierung kein Zugriff von einem Gast-System auf den Speicher des Hypervisors möglich wäre.
Wir setzen die Virtualisierungslösung KVM mit hardware-gestützter Virtualisierung ein. Somit könnten wir uns Zeit lassen mit dem Aktualisieren, denn es wäre kein Zugriff auf Daten anderer VMs möglich.
Allerdings: Über die »Spectre«-Lücke soll dies auch bei hardware-gestützter Virtualisierung möglich sein — nur daß es gegen diese Lücke zur Zeit noch wenig bis gar keine Korrekturen (vgl. Abschnitt zu »Spectre«) gibt.

Alles in allem schätzen wir die Gefahr bezogen auf unsere Freifunk-Infrastruktur nach aktuellem Kenntnisstand aber als gering ein; bis auf bei 4 VMs (VMs für zwei Nachbarcommunities sowie unsere mtr.sh-Node) hat kein Dritter Zugriff auf unsere Systeme; jene Systeme werden wir sicherheitshalber vorübergehend auf einem Host zusammenziehen. Da wir nur auf »eigener« Hardware arbeiten (Bare-Metal-Virtualisierung, keine angemieteten VMs), geht eine Gefahr nur von eigenen System aus (mit obiger Ausnahme).

Letztlich gibt es auch nicht sonderlich viele lohnende »Geheimnisse« auf unseren Systemen, die auszuspähen sich lohnte: der Traffic, den wir transportieren, stammt aus einem unverschlüsselten WLAN und kommt/geht unverschlüsselt aus dem/ins Internet – weshalb wir ja seit Jahr und Tag den Einsatz von Ende-zu-Ende-Verschlüsselung (HTTPS, IMAPS, SMTPS/SMTP mit STARTTLS usw.) predigen –, die meisten Statistiken sind öffentlich zugänglich, wir arbeiten nicht mit System-Passwörtern, …
Eine Veränderung von Daten ist nach aktuellem Informationsstand nicht möglich, ›nur‹ ggf. das Auslesen von eigentlich nicht zugänglichen Speicherbereichen (und auch dies vergleichsweise langsam).
Dennoch werden natürlich auch wir unsere Systeme zeitnah aktualisieren (ab dem 9. Januar sollen erste Fixes verfügbar sein; es werden über die nächsten Wochen noch weitere Aktualisierungen jener erwartet, die etwaige neue Probleme adressieren) — und leider wird’s an der einen oder anderen Stelle in den nächsten Wochen daher etwas rumpeln.
Und Ihr wißt nun auch Bescheid, warum ;)