
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-Isolation umbenannt 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.