Kürzlich haben Akademiker der Systems and Network Security Group (VUSec) der Vrije University Details über die CrossTalk- oder SRBDS-Schwachstelle (CVE-2020-0543) in Intel-Prozessoren veröffentlicht. Die CrossTalk-Schwachstelle ermöglicht es, dass von Angreifern kontrollierter Code, der auf einem CPU-Kern ausgeführt wird, vertrauliche Daten von anderer Software, die auf einem anderen Kern ausgeführt wird, preisgibt. In diesem Artikel zeigen wir Ihnen, wie Sie diese Intel-CPU-Schwachstelle ohne Serverneustart mindern können.
Was ist CrossTalk?
Die CrossTalk-Schwachstelle ist eine Art MDS-Angriff (Microarchitectural Data Sampling), ähnlich wie Spectre, Meltdown oder Zombieload. Es ermöglicht die Offenlegung und den Diebstahl sensibler Daten, während die Maschine auf sie zugreift. MDS-Angriffe zielen auf Benutzerdaten in einem Übergangszustand ab, da sie sich in der CPU und vielen damit verbundenen Systemen befinden.
Die SRBDS/CrossTalk-Schwachstelle ist eine vorübergehende Ausführungsschwachstelle. Von Intel als „Special Register Buffer Data Sampling“ oder SRBDS (CVE-2020-0543) bezeichnet, ermöglicht es angreifergesteuerten Code, der auf einem CPU-Kern ausgeführt wird, was dazu führt, dass vertrauliche Daten von der Opfersoftware, die auf einem anderen Kern ausgeführt wird, verloren gehen.
Abbildung 1:Design der Anweisungsprofilierungsphase von CrossTalk, mit freundlicher Genehmigung von VUSec
Jedes System, das eine Intel-CPU verwendet, kann von dieser Schwachstelle betroffen sein. Prüfen Sie hier, ob Ihre CPU betroffen ist.
Rebootless Mitigation of SRBDS (CVE-2020-0543) Vulnerability
Intel hat seine Risikominderung für die SRBDS-Schwachstelle in einem Mikrocode-Update implementiert, das am Dienstag, den 9. Juni 2020 an Softwareanbieter verteilt wird. Diese Risikominderung erfordert die Installation der neuesten Linux-Kernel-Patches und des Mikrocode-Updates. Beide Operationen werden traditionell beim Neustart durchgeführt.
Das Neustarten einiger Server klingt zwar nicht nach einem Problem, aber wenn Sie ein SysAdmin sind, der sich um mehr als 500 Server kümmert, ist es das auf jeden Fall. Der Neustart einer ganzen Serverflotte erfordert normalerweise eine gründliche Planung des Wartungsfensters. Glücklicherweise ermöglicht die Live-Patching-Technologie das Anwenden von Sicherheitsupdates auf die Systeme gegen CrossTalk ohne Neustart, sowohl für Microcode-Updates als auch für Linux-Kernel-Patch-Anwendungen.
Canonical, Red Hate und andere Distributionsanbieter haben die Sicherheitspatches für alle unterstützten Ubuntu-Distributionen, Debian, CentOS, Red Hat Enterprise Linux, veröffentlicht. Und obwohl Canonical und Red Hat ihre eigene Lösung zum Patchen von Schwachstellen ohne Neustart haben, müssen Sie im Fall von SRBDS/CrossTalk nach dem Update immer noch einen Desktop oder Server neu starten.
Das KernelCare-Team hat eine neustartfreie Risikominderung für CrossTalk/SRBDS erstellt, damit Sie den Neustart der Server zum Anwenden der Patches vermeiden können. Nachfolgend finden Sie die Anweisungen:
A) Wenn Sie Hardware verwenden, ergreifen Sie 3 Schritte, um Ihre Server ohne Neustart vor CrossTalk/SRBDS-Schwachstellen zu schützen:
Schritt 1:Melden Sie sich für eine kostenlose Testlizenz von KernelCare an
KernelCare kann 30 Tage lang kostenlos auf allen Ihren Servern verwendet werden, es ist keine Kreditkarte erforderlich, um sich für eine Testversion anzumelden. Es ist außerdem für den Rest des Jahres 2020 für Gesundheitsorganisationen kostenlos und für gemeinnützige Organisationen für immer kostenlos.
Schritt 2: Microcode ohne Neustart aktualisieren
Beispiel:Mikrocode auf RHEL aktualisieren
Dies ist das Beispiel eines Mikrocode-Updates ohne Neustart auf RHEL. Anweisungen für Debian, Ubuntu, CentOS und andere Distributionen finden Sie in der KernelCare-Dokumentation.
Bei RHEL-basierten Distributionen können Sie das Dienstprogramm microcode_ctl verwenden, um den Mikrocode zu aktualisieren.
Bevor Sie beginnen, prüfen Sie hier, ob die Patches für Ihre Distribution fertig sind. Die Seite wird stündlich aktualisiert.
1. Holen Sie sich den neuesten Mikrocode, indem Sie microcode_ctl aktualisieren Paket
yum update microcode_ctl
2. Erstellen Sie ein force-late-intel–06–4f–01 im Firmware-Verzeichnis.
touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01
3. Führen Sie das Mikrocode-Update aus
/usr/libexec/microcode_ctl/update_ucode
4. Den Kernel zwingen, den neuen Microcode zu laden
echo 1> /sys/devices/system/cpu/microcode/reload
5. Überprüfen Sie den neuen Mikrocode
dmesg | grep microcode
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12
[ 2.254820] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba
[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13
[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
6. (Optional) Überprüfen Sie die neue Microcode-Version noch einmal (Revisionen pro Kern)
cat /proc/cpuinfo | grep -e microcode
microcode : 0x21
microcode : 0x21
microcode : 0x21
microcode : 0x21
Schritt 3:KernelCare-Patches anwenden
Jetzt müssen Sie den Linux-Kernel aktualisieren, um sicherzustellen, dass der lokale Benutzer die Daten, die Sie auf der CPU ausführen, nicht lesen kann. Mit KernelCare geht das ohne Neustart. Wenn Sie sich in Schritt 1 für die Testversion angemeldet haben, sind Sie fertig und müssen nichts weiter tun.
B) Wenn Sie auf einer VM laufen:
Sie müssen nur den Linux-Kernel innerhalb der VM patchen. Stellen Sie sicher, dass Ihr Host-Knoten ebenfalls aktualisiert wird, was normalerweise von Ihrem Dienstanbieter durchgeführt wird.
Wenn Sie Ihr KernelCare verwenden, werden Ihre Patches automatisch von KernelCare geliefert und Sie müssen nichts extra tun. Wenn nicht, melden Sie sich für eine kostenlose 30-Tage-Testversion an .