Bild: „IntelPentium4_Northwood_SL6SB_2015-05-09-17.26.07_-_ZS-PMax_-_Stack-DSC03946-DSC04026“ von Fritzchens Fritz Lizenz: CC-0
Die Auswirkungen des CPU-Super-Gau, der in den letzten Tagen immer deutlicher die Züge einer IT-Katastrophe annahm sind noch nicht völlig überschaubar. Klar ist aber, dass letztendlich nur der Austausch der CPU die ultimative Lösung ist. Aber selbst wer sowieso in naher Zukunft die Anschaffung einer neuen CPU oder eines neuen Rechners geplant hat, wird seine zeitliche Planung neu überdenken müssen.
Intel-Mitarbeiter klärt auf
Die Tweet-Serie des ehemaligen Intel-Mitarbeiters Joe Fitz klärt uns darüber auf, dass hier mit Jahren und nicht mit Monaten zu rechnen ist, bis korrigiertes Silizium die Kunden erreicht. Aufgrund der gegebenen und über Jahrzehnte gewachsenen Komplexität heutiger Prozessoren ist es sehr aufwendig, das Layout auch nur in kleinsten Schritten zu ändern. Jedes sogenannte Stepping – bei Software würde man von einem Build-Vorgang sprechen – kostet einige Millionen Dollar und dauert einige Monate. Es ist jedoch mit einem Stepping nicht getan, ganz abgesehen von dem darauf folgenden Testzeitraum und der Auslieferung an die OEMs und der Händler für den Endkundenmarkt.
Die Zahl der Steppings ist relativ eng begrenzt, will man profitabel bleiben. Den Änderungen am Layout sind zudem enge Grenzen gesetzt, was das Ausmaß pro Stepping angeht. Es sind bei weitem nicht alles »full layer steppings«. So können etwa keine logischen Gatter geändert werden, ohne weitreichende Regressionen hervorzurufen. Bestenfalls kann man die Art, wie die Gatter angebunden sind, verändern.
Kleine Änderungen und hohe Kosten pro Stepping
Die Grenzen der möglichen Veränderungen sind von einem Bit bis hin zu wenigen Byte eng gesteckt. Instruktionen können ausgetauscht, die Richtung eines Branch angepasst werden. Verändert man mehr, beeinflusst man alles drum herum. Somit liegt der Zeitrahmen selbst für kleinste Veränderungen bei mehreren Monaten für die Steppings, weitere Monate für interne Tests des Fixes. Dann folgen Regressions-Tests gegen 50 Jahre Code, die die CPU unterstützt. Ist das alles erfolgreich durchlaufen, folgt noch einmal ein halbes Jahr für die Produktion, gefolgt von der Auslieferung.
Das beschriebene Szenario mag zur Reperatur der jetzt aufgefundenen Fehler im Design unter Umständen aber auch nicht ausreichen. Dann müsste man bei den Chip-Herstellern von der Entwicklungsphase zurück in die Planunsgsphase. Dann würden aus 1-2 Jahren der oben beschriebenen Änderungen und Steppings, die alle in die im Schaubild gelbe Entwicklungsphase fallen schnell 5-6 Jahre unter Einbeziehung der rosa Planungsphase.
Teurer Design-Fehler
Für Intel und die anderen betroffenen Hersteller bedeutet das, dass der Absatz der bereits produzierten und im aktuellen Stepping noch zu produzierenden CPUs wahrscheinlich hohe Verluste nach sich ziehen werden, die von den Entwicklungskosten für eine bereinigte Architektur nochmals erhöht werden. Zudem sieht sich Intel bereits ersten Klagen gegenüber, die ebenfalls die Kasse strapazieren werden. Die bisherigen Klagen beziehen sich darauf, dass Intel in den letzten Monaten bewusst schadhafte CPUs verkauft habe ohne dies den Kunden mitzuteilen.
Zwar sind die Sicherheitslücken in modernen CPUs von Intel, ARM, Apple, AMD und IBM noch nicht völlig in der Tiefe ausgelotet, es reicht aber aus, um eine erste Analyse des Gefahrenpotentials zu wagen, das von Spectre und Meltdown ausgeht. Derzeit sind drei Fehler mit verschiedenen Angriffsvektoren bekannt:
Dabei entsprechen die Varianten 1 und 2 dem Angriffsvector Spectre, Variante 3 entspricht Meltdown. Von Meltdown sind alle Intel CPUs seit 1995 mit wenigen Ausnahmen betroffen. Ausgenommen sind lediglich Atom-CPUs vor 2013 und Itanium-Prozessoren. Google hat eine Liste der betroffenen Prozessoren bereitgestellt. Die von Hause aus schwachen Atom-CPUs wurden bewusst nicht mit dieser Technik ausgestattet, da sie die Rechenleistungseffizienz pro Watt verringern kann.
Meltdown
Meltdown ist die am einfachsten zu behebende Variante. Diese Variante durchbricht die grundlegende Isolierung zwischen Anwendungen und dem Betriebssystem. Dieser Angriff ermöglicht es einem Programm, auf den Speicher und damit auch auf die Geheimnisse anderer Programme und des Betriebssystems zuzugreifen.
Wenn ein Computer über einen verwundbaren Prozessor verfügt und ein nicht gepatchtes Betriebssystem verwendet, ist es möglich, dass Informationen der gerade aktiven Anwendung durchsickern, die im Kernelspeicher vorgehalten werden. Dies gilt sowohl für Personal Computer als auch für die Cloud-Infrastruktur. Dazu muss allerdings bereits Zugriff auf das Gerät bestehen. Das Problem solle durch Kernel-Patches mittlerweile für alle Plattformen eingedämmt sein.
Spectre
Spectre dagegen betrifft alle CPUs von Intel, AMD und ARM in angegegebenen Zeitraum, Es ist schwerer, Spectre auszunutzen, allerdings trifft das auch auf die Gegenmaßnahmen zu. Spectre nutzt die bei modernen CPUs zur Leistungssteigerung eingesetzte «spekulative Ausführung« aus. Dabei berechnet die CPU die wahrscheinlichste nächste Berechnung. Diese werden in einem extra Zweig (branch) gespeichert. Liegt die CPU richtig, was überwiegend der Fall ist, wird mit diesem Branch weitergemacht. Wenn nicht, werden die Daten verworfen und in einem anderen Branch fortgefahren.
Attacke per Browser
Hier können nun manipulierte Anwendungen lokal oder als Web-App oder Browser mittels einer sehr präzise getimten Side-Channel-Attack Daten aus dem Cache abgegriffen werden. Diese Lücke lässt sich allein mit Kernel-Patches nicht schliessen, dazu müssen viele Anwendungen mit einem aktualisierten Compiler neu gebaut werden. Deshalb werden wir mit Spectre noch lange zu tun haben. Denkt man beispielsweise an Debian, so müssen alle Pakete für jede der derzeit unterstützten zehn Architekturen gebaut werden.
Bei virtuellen Maschinen und Containern ist die Situation nochmals kritischer. Hier kann unter Umständen sowohl der Speicher der Host-Mschine und der von anderen VMs auf dem gleichen Host gefährdet sein. Zudem können in solchen Umgebungen die Leistungseinbußen wie bei großen Datenbanken besonders zu Buche schlagen.
Kernel, Browser und Microcode aktualisieren
Wichtig ist es, Browser so gut wie möglich abzusichern. Firefox 57.0.4 liegt da momentan vorne, da es Versuche, per Sprectre Daten abzugreifen, erschwert. Bei Chrome/Chromium und den auf der gleichen Engine basierenden Opera und Vivaldi kann über chrome://flags die Funktion enable-site-per-process aktiviert werden, die jede offene Webseite in einem eigenen Prozess rendert. Google Chrome 64 erscheint am 23. Januar und hat diese Einstellung von Hause aus aktiviert. Microsoft Edge wird am 9 Januar gegen Spectre aktualisiert.
Anwender egal welcher Distribution sollten neben dem Browser auch ihre Kernel aktualisieren. Intel bietet zudem einen ersten aktualisierten Microcode mit der Versionnummer 3.20171215.1 an, der in Debian Unstable und anderen Distributionen bereits verfügbar ist. Weitere werden folgen. Mit einem Update des Microcodes kann Intel Fehlfunktionen beheben, ohne dass die CPU ausgetauscht wird. Wie weit das für Spectre gelingt ist noch unklar. Bei Debian könnte dies die Diskussion um nicht um freie Software erneut anfeuern, handelt es sich doch beim Micocode um Software aus dem Non-free-Repository.
Am dritten Tag nach der Veröffentlichung des mit Fug und Recht als Super-GAU bezeichneten Bugs in den meisten seit 1995 produzierten Prozessoren wird das gesamte Ausmaß des katastrophalen Fehlers klar: es handelt sich um einen in Silizium gegossenen Design-Fehler, der Milliarden von Geräten betrifft, von denen viele niemals einen Fix sehen werden. Dazu zählen vor allem viele Android-Smartphones. Über den Umfang der Auswirkungen auf AMD-Prozessoren besteht weiterhin Unklarheit. AMD selbst hatte die Chance, die Lücken beträfen auch AMD-CPUs als nahe Null bezeichnet.
Entwarnung für Heimanwender
Etwas Entwarnung gibt es dagegen bei den zu erwartenden Performance-Einbrüchen für durchschnittliche Heimanwender. Wer an seinem Rechner hauptsächliche surft, spielt und Office-Aufgaben erledigt, wird kaum einen Verlust an Geschwindigkeit verspüren, die Werte sollten im niedrigen einstelligen Bereich liegen. Anders kann das im Büro aussehen, wenn etwa große Datenbanken betrieben werden. Hier kann die Höchststrafe unter Umständen bei bis zu 30 Prozent liegen. Das liegt hauptsächlich daran, dass die Fixes für die Lücken die I/O-Last nach oben treiben.
Intel in bekannter Manier
Viele Hersteller haben sich zu Wort gemeldet, Intel gleich zwei Mal. Die Nachricht aus dem Intel Newsroom ist ähnlich vage und nichtssagend wie die vom Vortag. Dort heißt es:
»Intel hat Updates für alle Arten von Intel-basierten Computersystemen – einschließlich PCs und Servern – entwickelt und veröffentlicht, die diese Systeme gegen beide von Google Project Zero gemeldeten Exploits (als „Spectre“ und „Meltdown“ bezeichnet) immun machen. Intel und seine Partner haben bedeutende Fortschritte bei der Bereitstellung von Updates erzielt, sowohl bei Software-Patches als auch bei Firmware-Updates.«
In weiteren Verlauf der Verlautbarung stellt sich Intel an die Speerspitze derer, die Lösungen für das Problem anbieten, ohne dabei konkret zu sagen, was Intel den Betroffenen anbietet. Am Ende gibt es einen Link, der zumindest weitere technische Einzelheiten enthält, aber nichts an den Tag bringt, was nicht bereits bekannt war und von anderer Seite mit wesentlich mehr Details veröffentlicht wurde. Zudem behauptet Intel dort weiterhin, es handle sich nicht um einen Fehler in Intels Hardware. Die Begründung lautet, es seien auch andere Hersteller betroffen. Diese Logik wirkt zumindest befremdlich.
Betroffene Intel-CPUs aufgelistet
Die zweite Veröffentlichung von Intel stammt aus dem hauseigenen Security Center und erweist sich als nützlicher, denn sie nennt im Detail die betroffenen Plattformen und Prozessoren aus eigener Produktion. Zudem bedankt sich Intel bei den Forschern von Google und der Universität Graz, die die Lücke in etwa zeitgleich entdeckt hatten.
ARM reagiert vorbildlich
ARM hat ausführlich und übersichtlich Stellung zu den betroffenen Prozessoren und dem, was ein Anwender zur Absicherung tun sollte Stellung bezogen. Dabei wird pro betroffenem Prozessor dargestellt, welche der drei Varianten auf den jeweiligen Cortex-Kern zutrifft. Leider wird das vielen betroffenen Smartphone- und Tablet-Besitzern nicht viel nützen, da es vom Hersteller des Geräts abhängt, wann ein Update angeboten wird. Für viele Geräte wird das heißen: niemals. Googles eigene Baureihen Nexus und Pixel haben bereits ein Update für Januar erhalten oder es ist in der Auslieferung und wird zeitnah aufgespielt.
Google stellt Retpoline vor
Google hat ebenfalls am gestrigen Tag weitere Details veröffentlicht. Darin geht es hauptsächlich um die von Google erstellten Gegenmaßnahmen und die zu erwartenden Leistungseinbußen. Dabei stellt Google eine neue Technik zur Entschärfung namens Retpoline vor, die gegen Spectre, auch als »Branch Target Injection« bezeichnet, eingesetzt werden kann und wenig Leistungseinbußen nach sich ziehen soll. Retropline ist ein zusammengesetzter Begriff aus den Worten »return trampoline«. Die Technik verwendet eine Endlosschleife, die nie ausgeführt wird, um die CPU daran zu hindern, auf das Ziel eines indirekten Sprunges zu spekulieren. Entwickler Paul Turner hat die Technik gestern auch den Kernel-Entwicklern vorgestellt.
Distributionen verteilen KPTI-Patches
Die großen Linux-Distributionen haben Kernel veröffentlicht, die die KPTI-Patches gegen die Lücken verteilen. Microsoft hat wegen der Brisanz der Lücken die Auslieferung weiterer Patches für Windows 10 vorgezogen, die ab dem 03. Januar 2018 ab 22 Uhr verteilt werden sollen. Patches für ältere Versionen wie Windows 7 und 8 sollen zum nächsten Microsoft Patchday folgen. Bei den jetzt für Windows 10 angebotenen Updates gab es vereinzelt Kompatibilitätsprobleme mit Anti-Viren-Software. Microsoft rät dringend dazu, das Update nicht manuell zu forcieren, sondern erst einzuspielen wenn es über die Update-Funktion angeboten wird.
Firefox vorerst abgesichert
Mozilla hat als Reaktion auf die Lücke Firefox 57.0.4 veröffentlicht. Als vorübergehende Maßnahme, bis die genaue Funktionalität der Lücken bekannt sei, hat Mozilla die Genauigkeit der Zeitintervalle über die Funktion performance.now() von 5μs auf 20μs heraufgesetzt, um Javascript-Angriffe zu erschweren, die auf die Messung präziser Zeitintervalle angewiesen sind. Zudem wurde der SharedArrayBuffer-Standard deaktiviert, um die Verwendung höher auflösender Timer zu verhindern. Auch Google, Apple und Microsoft haben ihre Browser entsprechend gepatched. Diese sind allerdinmgs im Gegensatz zu Firefox noch nicht veröffentlicht. Micosoft wird Edge am 9. Januar aktualisieren, Google Chrome 64 erscheint am 23. Januar.
Mitlesen von der Tastatur
Auf LWN gibt es einen Überblick über weitere interessante Links zum Thema. Auch ein Interview der Berliner Zeitung »Der Tagesspiegel« mit einem der Entdecker der Lücken von der Universität Graz lohnt das Lesen. Michael Schwarz erläutert darin, man könnte theoretisch alles mitlesen, was gerade auf der Tastatur eingegeben wird. Die Lücken können allerdings nur ausgenutzt werden, wenn bereits Zugriff auf den Rechner besteht.
Das trifft allerdings nur für Meltdown zu, Spectre kann bereits über den Browser ausgenutzt werden. Allerdings ist es mit Spectre wesentlich schwerer, Daten auszulesen. Hierbei müssen sehr präzise Timings eingehalten werden, zudem muss der Angreifer wissen, welche Prozesse gerade laufen und welche Daten sich im Speicher befinden. Schwarz bestätigt, dass Meltdown bisher nur auf Intel-Prozessoren reproduziert wurde. Spectre schließt auch alle Smartphones mit ARM-Prozessoren ein.
Linus Torvalds not amused
Die Kernel-Entwickler bei Linux sind alles andere als erfreut über die Art und Weise, wie die Informationspolitik im Hinblick auf die Lücken gehandhabt wurden, die Intel seit Juni 2017 bekannt waren. Linus Torvalds äußert sich für seine Verhältnisse sehr zurückhaltend zu Intels PR:
»Ich denke, dass jemand innerhalb von Intel wirklich einen langen harten Blick auf ihre CPUs werfen muss, und tatsächlich zugeben muss, dass sie Probleme haben, anstatt PR-Blurbs zu schreiben, die besagen, dass alles so funktioniert, wie es entworfen wurde….
…Oder sagt Intel im Grunde genommen, dass sie darauf abonniert sind, uns für immer und ewig Scheiße zu verkaufen und nie etwas zu reparieren? Denn wenn das der Fall ist, sollten wir vielleicht anfangen, uns mehr auf die ARM64-Leute zu konzentrieren.«
Zu spät informiert
Andere Entwickler monieren, dass die Betriebssystemhersteller viel zu spät über die Vorgänge informiert worden seien und nun zum Schutz ihrer Anwender unter Zeitdruck Gegenmaßnahmen entwerfen mussten. Nach Aussagen von Mounir Hahad, Chef der Sicherheitsanalyse bei Juniper Networks, konnte bisher in freier Wildbahn kein Fall entdeckt werden, der die Lücken ausnutzt. Da diese Lücken aber schon seit rund 20 Jahren bestehen, kann niemand mit Bestimmtheit sagen, ob sie nicht in der Vergangenheit bereits von Geheimdiensten oder Kriminellen ausgenutzt wurden.
Eines ist jedoch bereits jetzt klar: Die Auswirkungen dieses Design-Fehlers werden uns noch lange begleiten und beschäftigen. Ganz besonders im Fall von Spectre, da hier jede Anwendung einzeln gegen die Lücke abgeichert werden muss. die Kernel-Patches reichen hier nicht aus.
Bild: „Intel@Sandybridge@Ivy_Bridge-EX_(Ivytown)@Xeon_E7_V2@QDPJ_ES___Stack-DSC07905-DSC07945_-_ZS-retouched“Fritzchens Fritz Lizenz: CC0
Mittlerweile ist etwas Licht in das Dunkel um den vermeintlichen Fehler in Intel-CPUs gekommen, der gestern für mächtiges Rauschen im digitalen Blätterwald sorgte. Das ist allerdings nicht Intel zu verdanken, die sich gestern Abend zu Wort meldeten. Eigentlich sei eine Stellungnahme erst später geplant gewesen, im Licht der fehlerhaften Pressemitteilungen sehe man sich aber veranlasst, sich bereits jetzt zu äußern.
Intel wiegelt ab
Zunächst wird einmal die Gefährlichkeit der Sicherheitslücke heruntergespielt wenn Intel schreibt, nach Unternehmensansicht hätten diese Exploits nicht das Potential, Daten zu beschädigen, zu verändern oder zu löschen. Des Weiteren sei es nicht korrekt, das der Fehler, der solche Exploits erlaube, nur bei Intel-Produkten anzutreffen sei. Nach jetzigem Sachstand seien »viele Arten von Computergeräten – mit Prozessoren und Betriebssystemen verschiedener Hersteller – anfällig für diese Angriffe.« Man arbeite eng mit anderen Unternehmen, unter anderem auch AMD und ARM Holdings und mit Betriebssystemherstellern zusammen um dieses Problem schnell und konstruktiv zu beseitigen.
Die zu erwartenden Performance-Einbussen spielt Intel herunter, diese seien für Privatanwender nicht signifikant und würden mit der Zeit abgeschwächt. Hier hat Intel vermutlich sogar recht, denn die vereinzelt gemeldeten Werte von 30 bis 50 Prozent entsprechen nicht dem zu erwartenden Einbruch. Aber selbst Werte um fünf Prozent und bei NVMe-SSDs auch mehr sind nicht hinnehmbar.
Google redet Klartext
Etwas klarer wird das Bild, liest man sich die kurz darauf veröffentlichte Erklärung von Google durch, die auch mit technischen Einzelheiten aufwartet. Die Lücke sei letztes Jahr im Rahmen von Googles Forschung im Rahmen von Project Zero entdeckt worden. Dabei handelt es sich um ein Forschungsprojekt zur Sicherheit und Verhinderung von Angriffen auf Computer und Netzwerke. Bereits im zweiten Satz wird klar, dass die Aussage von Kernel-Entwickler Thomas Lendacky zutreffend war und der Hase bei der speculative execution begraben liegt. Die spekulative Ausführung verwendet untätige Ressourcen der CPU, um den folgenden Programmfluss vorauszusagen und Daten spekulativ vorzuhalten, die vermutlich demnächst gebraucht werden. Wo der bei AMD angestellte Kernel-Entwickler Lendacky – vorsichtig formuliert – vermutlich falsch lag, ist, dass AMD nicht betroffen ist.
Google stellt klar, dass fast alle modernen CPUs die »spekulative Ausführung« einsetzen. Zudem habe Jann Horn, einer der Forscher des Project Zero, demonstriert, dass Angreifer die spekulative Ausführung dafür nutzen könnten um Bereiche des Kernelspeichers auszulesen, die unprivilegiert nicht im Zugriff sein sollten. Dabei könnten Passwörter, Schlüssel und weitere Daten aus offenen Anwendungen gestohlen werden. Google widerspricht damit klar der Aussage von Intel, dass Daten nicht gefährdet seien.
Alle Hersteller betroffen
Google sagt auch klar, die Verwundbarkeit betreffe viele CPUs, unter anderem auch die von Intel, AMD und ARM. Man habe sowohl die eigenen Produkte abgesichert als auch anderen Betroffenen geholfen, deren Anwender zu schützen. Bei Android sei darauf zu achten, dass die letzten Sicherheits-Updates eingespielt seien. Das dürfte allerdings nur für Besitzer von Nexus- und Pixel-Phones so einfach zu befolgen sein. Die meisten anderen Hersteller hängen um Monate hinterher. Bei Google Chrome sei darauf zu achten, dass die aktuelle Version des Browsers genutzt wird.
Technische Ausarbeitung
Mittlerweile liegt auch Googles Papier mit der technischen Ausarbeitung der Lücke vor. Daraus geht hervor, dass Google seine Forschungsergebnisse sowie erfolgreiche Exploits gegen einige CPUs von Intel, AMD und ARM den Herstellern bereits am 1. Juni 2017 bekanntgegeben hat. Auch IBMs System Z, POWER8 (Big Endian und Little Endian) und POWER9 (Little Endian) sollen betroffen sein. Zudem wird klar, dass es mehrere Varianten gibt, die die Kennzeichnungen CVE-2017-5753, CVE-2017-5715 und CVE-2017-5754 erhalten haben. Wie mittlerweile üblich erhielt die Lücke auch Namen und drollige Icons. Dabei sind unter Spectre CVE-2017-5753 und CVE-2017-5715 zusammengefasst, Meltdown steht für CVE-2017-5754
Meltdown scheint nach jetzigem Stand Intel-CPUs seit 1995 zu betreffen, Ausgenommen sind lediglich Itanium und Atom-CPUs vor 2013. Spectre sei schwerer auszunutzen, aber auch schwerer zu stopfen. Hiervon sind laut Google alle modernen CPUS von Intel, AMD und ARM betroffen. So kann Spectre durch Page-Table Isolation im Kernel nicht ausreichend behoben werden sondern muss in vielen Anwendungen aktiv verhindert werden. Hier sieht Google die Entwicklergemeinde noch eine ganze Weile mit der Sache befasst.
Amazon, Apple, AMD
Auch Amazon meldete sich am gestrigen Abend zu Wort. AWS sei sich der Verwundbarkeiten bewusst. Die Lücke existiere seit über 20 Jahrfen in modernen Prozessor-Architekturen von Intel, AMD und ARM auf Severn, Desktops und Mobilgeräten. Der überwiegende Teil der Amazon EC2-Flotte sei bereits gegen den Fehler gepatched, die verbleibenden Server würden in den nächsten Stunden abgesichert. Für Amazon Linux liegt ein aktualisierter Kernel bereits vor. Apple meldete gestern auf Twitter, die Lücke sei teilweise bereits am 6. Dezember mit macOS 10.13.2 geschlossen worden. Die komplette Absicherung werde mit macOS 10.13.3 ausgeliefert, dass sich derzeit in der Beta-Phase befinde.
Zu guter letzt meldete sich auch AMD mit einer Stellungnahme. Der Sender CNBC meldete, AMD sehe sich nicht von allen drei Varianten der Lücke betroffen und das Risiko für AMD-Kunden sei aufgrund einer anderen Implementierung der Funktion der spekulativen Ausführung derzeit »nahe Null«. Mittlerweile hat AMD seine Ausführungen weiter konkretisiert. Linus Torvalds fordert Intel auf, die Fehler zuzugeben anstatt weiter zu leugnen
Nach den Erkenntnissen der letzten Wochen zu Intel ME scheint Intel auch 2018 nicht aus den negativen Schlagzeilen herauszukommen. In einem Blog erschien am 1. Januar ein Artikel, der Hinweise auf einen Fehler sammelte, der anscheinend alle Intel-CPUs der letzten Jahre betrifft. Der Artikel weist zwar einige Fehler und vorschnelle Annahmen auf, folgt aber generell der richtigen Spur. Eine Beseitigung der Sicherheitslücke dahinter ist nur durch teils massive Änderungen an den einzelnen Betriebssystemen möglich, er kann anscheinend nicht in Intels Microcode repariert werden.
Linux- und Windows-Patches vorhanden
Bei Linux sind die Patches teilweise in Kernel 4.15 integriert und weitere für 4.16 geplant. Seit gestern abend ist bereits Kernel 4.14.11 gepatched. Bei Windows wurden sie den Benutzern des Fast Ring bereits im alten Jahr ausgeliefert und sollen an einem der nächsten Microsoft-Patchdays offiziell ausgeliefert werden. Apple schweigt sich wie üblich aus. Aber auch Intel hüllt sich über den Fehler in Schweigen. Die Kommentare in den Patches, die die Sicherheitslücke stopfen, verschleiern die technischen Hintergründe.
Viel geteilter Blogeintrag
Aufmerksam war der Autor des ersten Berichts durch hektisches Treiben bei den Kernel-Entwicklern in den letzten Wochen und über die Feiertage geworden. Tiefgreifende Änderungen am Virtual-Memory-Subsystem des Kernels, die ansonsten oft über Monate und Jahre diskutiert werden, bevor eine Zeile Code einfließt, brauchten nur wenige Wochen um in Kernel 4.15 einzufließen, der vermutlich in zwei Wochen veröffentlicht wird.
Hektik bereits seit Oktober
Der entsprechende Bug hat derzeit den Status embargoed, was bedeutet, dass betroffene Institutionen Kenntnis davon haben, der Fehler aber noch nicht veröffentlicht ist. Die zugrundeliegende Sicherheitslücke und die seit Oktober einfließenden Patches wurden zuerst am 20. Dezember auf LWN näher gewichtet. Der dortige Artikel ist derzeit aber nur für Abonnenten zugänglich und wird erst in den nächsten Tagen freigegeben.
Torvalds lässt Patches für 4.15-rc4 zu
Linus Torvalds hatte sich zu den sogenannten KAISER-Patches, die seitdem in KPTI für Kernel-Page-Table-Isolationumbenannt wurden, am 27. November dahingehend geäußert, er würde die Patches lieber in 4.16 sehen, wies aber auch gleich auf die Notwendigkeit der Portierung in die zurückliegenden LTS-Kernel 4.9 und 4.14 hin. Trotzdem flossen in 4.15-rc4 vorbereitende Patches ein, der Großteil wird, der gebotenen Sorgfalt bei solch tiefgreifenden Änderungen geschuldet, erst mit 4.16 ausgeliefert.
Künftig getrennte Page-Table-Bereiche
Was steckt nun hinter dem ganzen geschäftigen Treiben? Die Kernel-Entwickler trennen damit strikt die Page Tables, die derzeit noch von Kernel- und User-Space gemeinsam genutzt werden, in zwei völlig getrennte Sätze auf. Damit wollen sie verhindern, dass ein unprivilegierter Prozess auf den Speicherbereich im Kernel-Space zugreifen kann. Nach bisherigem Erkenntnisstand kann ein Prozess eine Intel-CPU durch Ausnutzen der Sicherheitslücke dazu bringen, Speicherbereiche zu prefetchen und dann durch Aushebeln der Zugriffskontrolle direkten Zugriff auf den Kernel-Bereich zu erhalten. Zudem könnte auch der Sicherheitsmechanismus ASLR ausgehebelt werden. Die auslösenden Prozesse können von normalen Anwendungen wie Office-Anwendungen bis hin zum JavaScript in Web-Browsern stammen. Im schlimmsten Fall könnten manipulierte Anwendungen oder Anwender den Kernelspeicher auslesen, der alle möglichen Geheimnisse wie Passwörter und weitere Zugangsdaten enthalten kann. Stellt man sich das auf öffentlichen Cloud-Servern vor, wird das mögliche Ausmaß klar.
Systemaufrufe bald langsamer
Wenn eine Anwendung in eine Datei schreiben oder eine Netzwerkverbindung öffnen will, muss sie dazu vorübergehend die Kontrolle über den Prozessor an den Kernel abgeben. Um den Übergang vom User-Modus in den Kernel-Modus und zurück so schnell und effizient wie möglich zu gestalten, hat der Kernel Zugriff auf den virtuellen Adressraum aller Prozesse, obwohl dieser für die Anwendung unsichtbar ist. Wenn der Kernel benötigt wird, führt das Programm einen Systemaufruf (syscall) durch, der Prozessor wechselt in den Kernel-Modus und hat Zugriff auf den Kernel. Wenn das erledigt ist, wird die CPU aufgefordert, in den Benutzermodus zurückzukehren und den Prozess erneut zu starten. Im Benutzermodus bleiben der Code und die Daten des Kernels für die Anwendung unsichtbar, ist aber in den Page Tables des Prozesses vorhanden.
AMD vermutlich nicht betroffen
Diese Sicherheitslücke ist in hohem Maße für virtuelle Maschinen und Container relevant, wo Bereiche mit Kernel-Techniken isoliert werden und ein Ausbrechen daraus kritisch sein kann. Nach Angaben des Kernel-Entwicklers Thomas Lendacky, der bei AMD beschäftigt ist, sind AMD-CPUs nicht betroffen. Er schreibt dazu auf LKML: » Die AMD-Mikroarchitektur erlaubt keine Speicherreferenzen, einschließlich spekulativer Verweise, die auf höher privilegierte Daten zugreifen, wenn sie in einem weniger privilegierten Modus ausgeführt werden, wenn der Zugriff zu einem Seitenfehler führen würde.«
Mindestens 5 Prozent Strafe
Also kann, wenn sich das bewahrheitet, für AMD-Prozessoren der KPTI-Patchset entfallen. Das könnte sich als Wettbewerbsvorteil herausstellen, da mit der Trennung der Page Tables ein anwendungsabhängiger Performance-Verlust von derzeit geschätzten mindestens fünf Prozent einhergeht. Diese Geschwindigkeitseinbußen entstehen dadurch, dass pro Syscall-Kontextwechsel ein TLB-Flush notwendig wäre. In Phasen ohne Syscall soll der TLB weiter wie gewohnt arbeiten. Modernere Intel-CPUs können dem TLB-Flush mit der PCID-Technik etwas entgegenwirken. Auf Phoronix gibt es erste Benchmarks dazu.
Des Pudels Kern?
Eines der Schlüsselwörter in der Aussage von Lendacky ist »spekulative Referenzen«. Bereits bei der Durchsicht der ursprünglichen KAISER-Patches von Sicherheitsforschern der Universität zu Graz stellte der Reviewer Anders Fogh in seinem Bericht fest: »Meine Ergebnisse zeigen, dass die spekulative Ausführung trotz Verstößen gegen die Isolation zwischen Kernel- und Benutzermodus tatsächlich weiter ausgeführt wird.« Hier könnte nach heutiger Erkenntnis der auslösende Fehler in Intels Silizium liegen.
Intel schweigt
Im Moment ist vieles an dieser Sicherheitslücke noch recht spekulativ, vor allem fehlen Informationen von Intel selbst. Klar ist, dass die Lücke besonders im Unternehmensumfeld ausgenutzt werden könnte. Große Cloud-Anbieter wie Amazon und Microsoft Azure haben bereits kurzfristig Wartungsmaßnahmen und Reboots angekündigt, ohne dabei jedoch ein mögliches Problem zu erwähnen.
Klar scheint auch zu sein, dass der Patch erst beim Booten aktiviert wird und somit AMD-CPUs von dem Performance-Verlust nicht betroffen sein werden. Unklar ist noch, wie weit genau die Lücke bei Intel-CPUs zurückreicht. Bisher sieht es aber so aus, als seien mindestens alle Intel-CPUs der letzten zehn Jahre betroffen.
Das neue Jahr beginnt mit guten Nachrichten für Linux. Das Linux Journal, die erste gedruckte Publikation, die sich ausschließlich mit Linux befasste, konnte entgegen allen Erwartungen doch noch gerettet werden. Schwierig erschien das vor allem, da ein potentieller Rettter auch bestehende Schulden übernehmen muss. Vor einem Monat hatte Herausgeberin Carlie Fairchild deshalb die Einstellung der Publikation bekanntgegeben. Als Grund gab sie finanzielle Probleme an, die bereits seit Jahren am Fundament der Publikation nagten, hinter der weder ein großer Verlag noch ein Geldgeber steht. Letztendlich sei der Einbruch der Werbeeinnahmen verantwortlich für das Wegbrechen der letzten finanziellen Grundlage gewesen.
Die Print-Ausgabe wurde bereits im August 2011 eingestellt. Doc Searls, von Anfang an dabei und der bekannteste Autor der Publikation, verkündete in einem Artikel, dass das Linux Journal in der gedruckten Ausgabe mit Ausgabe 208 eingestellt werden müsse und nur noch in digitaler Form weiterbestehen werde. Letztlich erwies sich auch dieses Modell als nicht tragfähig
Doch noch gerettet
Jetzt scheint das Linux Journal doch noch gerettet zu sein. Dahinter stehen Hacker der Holding London Trust Media, speziell die Leute hinter dem VPN-Anbieter Private Internet Access (PIA), die bereits den IRC-server Freenode und weitere FOSS-Projekte unterstützen. PIA möchte das Linux Journal nicht nur wieder seetüchtig machen, sondern auch den Staub der finanziell klammen letzten Jahre abklopfen und das Magazin wieder volle Fahrt aufnehmen lassen. Zur Kursbestimmung sind nun die treuen Leser aufgerufen. Sie sollen mitbestimmen, wohin die Fahrt künftig geht.
Linux Journal seit 1994
Das Linux Journal wurde erstmals im April 1994 als Print-Magazin veröffentlicht, dem Monat, in dem Linus Torvalds v1.0 des Kernel freigab. In der ersten Ausgabe wurde dem Anlass gemäß ein Interview mit Torvalds abgedruckt. Hinter dem Magazin standen damals Red-Hat-Mitbegründer Bob Young und Phil Hughes.
Linux hat sich als eines der erfolgreichsten kollaborativen Entwicklungsprojekte der Geschichte in der Open-Source-Software-Welt durchgesetzt. Mit zunehmendem Wachstum dominiert Linux auch fast jeden Markt, in den es eintritt, einschließlich Cloud, Mobile, Embedded und Supercomputing.
Michael Larabel von Phoronix hat mittels GitStats aktuelles Zahlenmaterial über die Kernel-Entwicklung im Jahr 2017 ermittelt. Demnach gab es im vergangenen Jahr insgesamt 71.552 Commits. Dabei wurden 3.911.061 Zeilen zum Kernel hinzugefügt und 1.385.507 entfernt, was bereinigt zu einer Nettozunahme von rund 2,5 Mio. Zeilen Code führte. Die Anzahl der Commits war allerdings die niedrigste seit 2013. So wurden 2015 75.770 Commits eingereicht, während es 2016 bereits 76.892 waren. Im Jahr 2013 wurden rund 70.900 Commits verzeichnet.
Imposanter Zuwachs
Waren es 2017 auch weniger Commits als in den vergangenen Jahren, so war der Zuwachs insgesamt der größte, der je verzeichnet wurde. Das bedeutet, dass die Commits durchschnittlich in der Größe zugelegt haben. So trugen 2017 einige wenige Commits von Entwicklern wie Red Hats Dave Airlie zu AMD-Grafiktreibern wie AMDGPU DC gleich Hunderttausende neue Zeilen zum Kernel bei. Der erreichte zum Jahresende 25.359.556 Zeilen, die sich auf 62.296 Dateien verteilen.
8,5 Änderungen pro Stunde
Die 2017 veröffentlichten Kernel-Versionen reichen von 4.10 am 19. Februar bis 4.14, der am 13.11. freigegeben wurde. In diesem Zeitraum wurden pro Stunde durchschnittlich 8,5 Änderungen am Kernel angenommen, während es für 2016 noch 7,8 Änderungen pro Stunde waren. Über 4.300 Entwickler, die bei mehr als 500 Firmen angestellt waren, trugen 2017 zum Kernel bei. Davon tätigten 1.670 Entwickler 2017 ihren ersten Kerne-Commit. Die Firmen, die dabei die meisten Commits einreichten sind Intel, Red Hat, Linaro, IBM, Samsung, SUSE, Google, AMD, Renesas und Mellanox.
Neben den erwähnten GitStats finden sich viele weitere Zahlen und Fakten zur Kernel-Entwicklung im Jahr 2017 im von der Linux Foundation jährlich herausgegebenen Linux Kernel Development Report 2017.
Die letzte im ausgehenden Jahr veröffentlichte Distribution ist laut Distrowatch siduction. Die Entwickler dahinter veröffentlichen seit Jahren eine Rolling-Release-Distribution auf der Basis von Debian Unstable aka Sid. Siduction ist mit den Desktop-Umgebungen KDE, GNOME, LXQt, Cinnamon, MATE, Xfce und LXDE erhältlich. Hinzu kommen zwei kleinere Varianten, wobei Xorg einen X-Server-Stack und Fluxbox als Window-Manager mitbringt, während noX ganz ohne X daherkommt und dem Anwender völlig freie Hand lässt.
Aktueller Snapshot
Siduction 2018.1.0 ist ein Snapshot aus Debian Unstable vom 29.12.2017. Als Kernel kommt ein distributions-eigener Kernel 4.14.10 zum Einsatz, flankiert von Systemd 236-1 und X-Server 1.19.5. KDE wird in Version 5.10.5 ausgeliefert, GNOME steht bei v3.26. LXQt ist mit v0.12.0 dabei, während Xfce bei 4.12.4, Cinnamon bei 3.4.6 und MATE bei 1.18.3 stehen.
Calamares Installer
Der von siduction verwendete Installer basiert auf dem Calamares Installer Framework in der neuesten Version. Installationen mit UEFI werden unterstützt, LUKS und LVM im Calamares-Installer derzeit noch nicht, da das derzeit hier verwendete kpmcore 3.3 noch steter Entwicklung unterliegt. Siduction bringt aber mit dem cli-installer einen auf Ncurses basierenden zweiten Text-Installer mit, der hier mehr Möglichkeiten bietet.
Non-Free-Software
Während bei Debian die Diskussion über non-free-Software vor kurzem wieder aufflammte, hat sich siduction aus pragmatischen Erwägungen heraus entschieden, WLAN- und Grafiktreiber sowie AMD- und Intel-Microcode vorzuinstallieren, sodass die Hardware während der Installation voll unterstützt wird. Mit dem Tool vrms (Virtual Richard M. Stallman) kann der Anwender überprüfen, welche Pakete aus den Bereichen contrib und non-free installiert wurden und diese gegebenenfalls mittels apt purge $(vrms -s) entfernen, wenn ein DFSG-konformes System bevorzugt wird.
Guter Support
Siduction eignet sich für Linux-Anwender aller Wissensstufen, jedoch sollten Nutzer, die in Linux noch nicht so sattelfest sind, bereit sein, sich in die Debian-Paketverwaltung mittels Apt/Aptitude einzuarbeiten und der Konsole nicht völlig abgeneigt gegenüber stehen. Die Entwickler unterstützen Anwender nach besten Kräften im Forum sowie im IRC. Der Zugang zum IRC ist auf dem Desktop verlinkt und führt – je nach Spracheinstellung des Systems – in den jeweils richtigen Kanal. Images für siduction sind über die Downloadseite des Projekts verfügbar. Die Release Notes vermitteln weitere Einzelheiten.
Manjaro Linux, die seit 2011 auf Arch Linux basierende Rolling-Release-Distribution, hat kurz vor Ende des Jahres noch ein Update-Paket als stabilen Schnappschuss herausgegeben. Mit eigenem Installer und einem grafischen Frontend zur Paketverwaltung richtet es sich sowohl an Anfänger als auch fortgeschrittene Benutzer.
Viel Auswahl
Manjaro wird mit den Desktop-Umgebungen KDE, GNOME und Xfce bereitgestellt, wobei letzteres den Desktop darstellt, auf den die Entwickler den meisten Wert legen. Zudem gibt es die kleine Net-Installation »Manjaro-Architect« für die Konsole, die entweder eine der offiziellen Images installiert oder dem Anwender völlig die Paketauswahl überlässt. Ein Icon zum Starten liegt auf dem Desktop der Images. Die Community steuert darüber hinaus Editionen mit Cinnamon, Enlightenment, LXDE, MATE, Openbox sowie dem Deepin Desktop Environment hinzu. Der Anwender hat zudem die Wahl zwischen den drei Zweigen unstable, testing und stable.
Aktualiserte Desktops
Auf Manjaro Linux 17.0.3 »Gellivara« vom September folgt nun Manjaro Linux 17.1.0 »Hakoila« und liefert unter anderem Xfce 4.12.1-2, GNOME 3.26.1-1 sowie Plasma 5.11 zusammen mit KDE Apps 17.12 aus. Neben Kernel 4.14 aktualisiert es auf den Xorg-Server 1.19.6. und den aktuellen Mesa-Stack 17.3.1-2. Insgesamt unterstützt Manjaro direkt aus den Repositories neun Kernel-Generationen von 3.16 bis hin zu 4.15. Zwei davon bedienen auch die Bedürfnisse von Realtime-Anwendungen.
Installer und Paketmanagement
Der Installer basiert auf dem Calamares Installer Framework 3.1.11-10. Bei den Anwendungen wurde Firefox auf 57.03-1 angehoben, während Gimp in Version 2.8.22-1 und Wine als Vorabversion 3.0rc4-1 vorinstalliert ist. Für das Paketmanagement steht neben dem stark überarbeiteten Pamac 6.2 auch Octopi 0.8.10 bereit, das auf Pacman 5.0.2 basiert. Mit Yaourt kann das Arch User Repository AUR verwaltet werden.
Anwender, die Manjaro bereits installiert haben können über diese Werkzeuge ihre Installation auf den neuesten Stand bringen. Für Testwillige und Neueinsteiger stehen aktuelle Images auf der Download-Seite des Projekts bereit. Manjaro wird ab 17.1 nur noch in 64-Bit ausgeliefert.
Der Berliner E-Mail-Provider Posteo unterstützt seit einigen Tagen Autocrypt. In einem Newsletter wurde ich erst auf dieses neue Verschlüsselungsverfahren aufmerksam, das sich auf die Fahnen geschrieben hat, echte Ende-zu-Ende-Verschlüsselung bei E-Mail-Programmen erheblich zu vereinfachen. Die neue Verschlüsselungsmethode wird derzeit in verbreitete E-Mail-Programme wie Thunderbird mit Enigmail und K-9 Mail für Android integriert. Neue Versionen dieser Programme wie Enigmail 2.0 und K-9 Mail 5.3 werden Autocrypt unterstützen.
Automatisierter Schlüsseltausch
Verwenden Absender und Empfänger Autocrypt-fähige E-Mail-Programme, müssen sie für eine Ende-zu-Ende-verschlüsselte Kommunikation nichts mehr tun: Die E-Mail-Programme verschlüsseln E-Mails vor dem Versand automatisch mit PGP und tauschen öffentliche Schlüssel automatisch im Hintergrund aus. Das oft als kompliziert empfundene manuelle Austauschen und Verwalten von GPG-Schlüsseln entfällt damit ersatzlos.
Vor der ersten verschlüsselten Kommunikation wird stattdessen einmalig eine reguläre E-Mail ohne Inhalt zugesendet. Bei diesem Versand wird erstmals der Schlüssel im Hintergrund übertragen. Ab diesem Zeitpunkt können alle Nachrichten automatisch verschlüsselt werden. Autocrypt ist Open Source, funktioniert anbieterübergreifend und setzt auf echte Ende-zu-Ende-Verschlüsselung, bei der ein privater Schlüssel stets beim jeweiligen Nutzer verbleibt.
Posteo mit zusätzlicher Absicherung
Bisher ist es nicht vorgesehen, dass E-Mail-Provider sich an der Schlüsselverteilung von Autocrypt beteiligen. Posteo macht hier einen ersten Schritt und sichert dabei das Schlüsselaustauschverfahren weiter ab. Posteo bietet bereits verschiedene Verschlüsselungsverfahren und viele Kunden haben ihre öffentlichen PGP-Schlüssel bereits über Posteo zugänglich gemacht. Mit Autocrypt können E-Mail-Programme öffentliche Schlüssel bald automatisiert über die E-Mail-Header austauschen.
Die providerseitige Unterstützung sorgt nun dafür, dass ein Autocrypt-fähiges Programm den Schlüssel auch dann erhält, wenn der Posteo-Absender ein Programm ohne Autocrypt verwendet. Liegt der öffentliche Schlüssel des Absenders vor, fügt Posteo fügt vor jedem E-Mail-Versand den für die Verschlüsselung benötigten Autocrypt-Header selbst hinzu. Der Kommunikationspartner kann dann verschlüsselt antworten ohne einen manuellen Schlüsselaustausch vornehmen zu müssen.
Autocrypt mit DKIM
Bei jedem weiteren Versand wird der aktuelle Schlüssel im Autocrypt-Header übermittelt. In den Programmen der Kommunikationspartner sind somit stets die aktuellen Schlüssel hinterlegt. Posteo sichert den Schlüsselaustausch mit Autocrypt zusätzlich mit digitalen Signaturen über DKIM ab. Die DKIM-Signierung sorgt dafür, dass öffentliche Schlüssel auf dem Transport nicht unbemerkt manipuliert werden können. Auch Autocrypt-Header, die das lokale E-Mailprogramm gegebenenfalls hinzufügt, werden mit DKIM signiert.
