Intel kämpft mit schwerer Sicherheitslücke (Update

Intel veröffentlicht Server-Benchmarks)

Vor, während und zwischen den Feiertagen herrschte ein wildes Treiben in der Linux-Community. Zunächst war nicht ganz klar, was hier genau vor sich geht, inzwischen aber scheinen die Auswirkungen deutlich zu werden: Intel hat nach einer Lücke in der Management Unit eines jeden Prozessors offenbar auch einen Designfehler in der Adressierung der virtuellen Speicherbereiche.

Dies kann dazu führen, dass nicht privilegierte Prozesse auf den Speicher des Betriebssystem-Kernels zugreifen können. Erste Hinweise gab es bereits wegen Umbauarbeiten des NT-Kernels im November. Nun aber scheinen die Auswirkungen vollends ans Tageslicht zu gelangen.

Inhaltesverzeichnis der News:

Um für etwas mehr Übersicht zu sorgen, haben wir die vielen Updates auf weitere Seiten verteilt. Daher hier ein kleines Inhaltesverzeichnis:

1. Einleitung
2. 1. Update: Benchmarks
3. 2. und 3. Update: Proof-of-Concept und Stellungnahme von Intel
4. 4. Update: Statements und Analysen
5. 5. Update: Weitere Analyse und die wichtigsten Fragen
6. 6., 7. und 8. Update: Einschätzung durch Apple, Microsoft, Amazon und Google
7. 9. Update: Überprüfung der Mitigation gegen Spectre und Meltdown
8. 10. Update: Wann kann Intel die Lücken auf Hardware-Ebene schließen?
9. 11. Update: Mehr Benchmarks
10. 12. und 13. Update: NVIDIA und Qualcomm anfällig
11. 14. und 15. Update: NVIDIA und Apple veröffentlichen weitere Updates
12. 16. und 17. Update: Intel meldet eigenen Leistungsdaten
13. 18. und 19. Update: BIOS-Updates von ASUS, Gigabyte und MSI
14. 20. Update: AMD und Intel äußern sich erneut
15. 21. Update: Intel versieht hunderte Prozessoren mit Microcode-Update

Vom Fehler betroffen sind offenbar alle CPU-Architekturen, die einen virtuellen Speicher vorsehen. Inzwischen kann dies aber auf Prozessoren aus dem Hause Intel eingeschränkt werden, da AMD bestätigt hat nicht von der Lücke betroffen zu sein:

„AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set."

Derzeit scheint es eine Responsible Disclosure zum Hardware-Bug zu geben. Dies bedeutet, dass einige Personen und Unternehmen alle Details kennen, diese aber bis zur finalen Behebung zurückhalten. Daher sind viele Details des Fehlers noch unbekannt oder basieren auf Spekulationen. Klar ist aber, dass es ein Problem bei der Zuweisung des virtuellen Speichers gibt, so dass nicht privilegierte Prozesse auf womöglich heikle Daten anderer Prozesse zugreifen können.

Bestätigt ist inzwischen auch, dass Intel den Fehler nicht durch ein BIOS/Microcode-Update beheben kann. Es handelt sich um eine fehlerhafte Hardware-Implementation, die nur durch eine Überarbeitung der entsprechenden Architektur behoben werden kann. Bis dahin sollen Updates des Virtual-Memory-Subsystem des Betriebssystems Abhilfe schaffen.

Programme können aus ihrem virtuellen Speicherbereich ausbrechen

Gefunden wurde die Sicherheitslücke offenbar von Wissenschaftlern der TU Graz, die eine Attacke untersucht haben, die zum Ziel hatte, den Speicherbereich des Kernels vom Process Page Table zu unmappen. Die Memory Management Hardware des Prozessors soll sicherstellen, dass der Kernel Address Space nicht Teil des nicht privilegierten Userspace wird – dies schlägt hier fehl. Eine Zugriffsprüfung findet nicht mehr statt.

Einige Core-Kernel-Entwickler haben daraufhin einen Patch namens KASLR entwickelt. Dieser Patch versteckt den Kernel Address Space vor der Memory Management Hardware des Prozessors – macht ihn für andere Prozesse damit unsichtbar. Zudem ist der Address Space Layout Randomization (ASLR) weiterhin in der Lage einem Prozess zufällige Daten für den Adressbereich  zu liefern.

KASLR implementiert den ASLR direkt im Kernel. Mit jedem Reboot wird der Adressbereich für den Kernel neu erstellt. Angreifern ist es damit nicht mehr möglich aus einem laufenden Prozess heraus auf den Adressbereich des Kernels zuzugreifen. Auch andere, weniger direkte Methoden sollen damit ausgeschlossen werden.

Software-Workaround kostet Leistung

Der Software-Workaround für Linux, inzwischen auch als Kernel Page-Table Isolation oder kurz PTI, bzw. KPTI bekannt, trennt den Speicherbereich des Kernels von dem der oder des Nutzers. Dies wird üblicherweise nicht getan, so dass die Memory Management Hardware des Prozessors schnell und einfach zwischen dem Adressbereich des Nutzers und des Kernels wechseln kann. Caches des Prozessors müssen dazu nicht geleert werden.

Da der KPTI-Patch das Virtual Memory Layout nun aber ändert und zwei getrennte Bereiche erstellt, kann der Translation Lookaside Buffer (TLB), der virtuelle Adressen den echten Speicheradresse zuteilt, bzw. diese Werte im Cache hat, nicht mehr von der Memory Management Hardware des Prozessors verarbeitet werden. Der TLB beschleunigt die Speicherzugriffe, was nicht mehr möglich ist, wenn der Kernel- und Nutzer-Speicherbereich getrennt voneinander behandelt werden müssen. Jedes mal, wenn nun der Kernel und Nutzer auf den Speicher zugreifen muss, werden die Caches mit der Zuordnung des virtuellen Speichers gelöscht und neu geladen, was natürlich Leistung kostet.

Am Beispiel eines AMD-Prozessors wurde das Abschalten des TLB gemessen:

Nun handelt es sich dabei um eine AMD-Prozessor, die Auswirkungen bei den Modellen von Intel sind aber ähnlich. Inzwischen gibt es aber einige Benchmarks mit Intel-Prozessor unter Verwendung des ungepatchten und gepatchten Kernels.

Die von Phoronix gemachten Benchmarks zeigen einen Leistungsverlust von bis zu 30 % unter Verwendung synthetischer Syscall-Anfragen, die in der Praxis aber einen Worst-Case darstellen. Anwendungen, die wenige Speicherzugriffe vorsehen, zum Beispiel des Transcodieren von Videos mittels FFmpeg oder das Compilen von Programmen, sehen geringe Einbußen. Datenbankzugriffe und Anwendungen, die auf eine hohe I/O-Leistung angewiesen sind, werden aber stärker beeinflusst.

Bisher ist Linux aber das einzige Betriebssystem, welches ein Update für den Kernel vorsieht, bzw. für das bereits ein Update vorhanden ist. Windows und macOS müssen ebenfalls ein Update erhalten, um die Lücke zu schließen. Derzeit ist aber nicht bekannt, wann dies geschehen wird und wie groß die Auswirkungen auf die Leistung hier sein werden. Erste Messungen der Spieleleistung unter Linux sehen keine große Leistungsverluste.

In den kommenden Stunden werden sicherlich weitere Informationen folgen. Offiziell soll die Lücke am 4. Januar veröffentlicht werden. Derzeit haben sich wieder Intel, noch Software-Unternehmen wie Microsoft und Apple zum Thema geäußert. Die größten Probleme dürften ohnehin die Cloud-Anbieter wie Amazon mit EC2, Microsoft mit Azure und Google mit der Compute Engine haben, denn hier laufen auf einem Server gleich mehrere Instanzen, deren Schutz vor Zugriffen aus anderen Instanzen heraus nun nicht mehr sichergestellt ist.

Der Linux-Kernel 4.14.11 mit KPTI-Implementierung kann bereits heruntergeladen werden. Hier ist KPTI allerdings für alle Prozessoren aktiv, auch für solche von AMD. Da dieser aber nicht vom Fehler betroffen sind, ist dies natürlich eine unnötige Einschränkung, die durch einen weiteren Patch (Linux 4.14.12) behoben werden soll.

Während der Recherche zu dieser News sind wir häufig auf folgende Aussage gestoßen, die offenbar treffender kaum sein könnte: 2018 beginnt mit der „mother of all hypervisor privilege escalation bugs".