Spectre will einfach nicht tot bleiben

Kurz nachdem der Exploit-Code in einem öffentlichen Repository gefunden wurdegefunden wurde, wurden zwei neue Sicherheitslücken (CVE-2020-27170 und CVE-2020-27171) im Code des Linux-Kernels gefunden, der vor diesem Problem schützt.

Beide Schwachstellen ermöglichen es einem lokalen Benutzer, den Kernel-Speicher zu lesen, der sensible Informationen wie Verschlüsselungsschlüssel enthalten könnte. Proof-of-Concept-Code wurde ebenfalls privat zur Verfügung gestellt, aber es ist davon auszugehen, dass er irgendwann an die Öffentlichkeit gelangen wird.

Der Code-Fehler ist in allen Kernel-Versionen bis zu 5.12-rc3, dem aktuellsten Release Candidate, vorhanden. Alle Distributionen sind verwundbar. 

KernelCare-Patches für alle unterstützten Distributionen sind in Vorbereitung und sollten ab nächster Woche zur Verfügung stehen.

Die erste Sicherheitslücke, CVE-2020-27170betrifft die Art und Weise, wie die Kernel-Abschwächung gegen spekulative Out-of-bounds-Loads funktioniert. Unprivilegierter Code, der eine bestimmte Kernel-BPF-Funktionalität (Berkeley Packet Filtering) erweitert, hatte Zugriff auf Zeiger und konnte ungebundene Zeigerarithmetik durchführen, die wiederum als Angriffsvektor für die Exfiltration von Kernel-Speicherinhalten genutzt werden konnte. Die Zeigeroperationen konnten verwendet werden, weil einige der Zeiger, die die BPF offenlegt, nicht korrekt begrenzt wurden.

Die zweite Sicherheitslücke, CVE-2020-27171verwendet dieselbe Art von BPF-Programmerweiterung auf 64-Bit-Systemen, wo wiederum eine Zeigeroperation unter einem Off-by-One-Fehler leidet. Aufgrund der Beschaffenheit von Computergeräten ist die erste Zahl 0 und nicht die natürlichere 1, und ein häufiger Programmierfehler besteht darin, dies bei der Durchführung mathematischer Operationen nicht zu berücksichtigen. Durch diesen Off-by-One-Fehler könnte ein Zeiger so verändert werden, dass er einen 4-GB-Block des Kernelspeichers freigibt. Bei korrektem Timing könnte dies einem unprivilegierten Benutzer den Zugriff auf geschützte Speicherplätze ermöglichen.

In den detaillierten Schwachstellenberichten wird für jede Schwachstelle das Vorhandensein eines privat veröffentlichten Proof-of-Concept erwähnt, aber ein ausreichend motivierter Angreifer könnte dem Bericht genügend Informationen über das Problem entnehmen, um seinen eigenen Angriffscode zu entwickeln.