{"id":104644,"date":"2022-07-13T15:36:38","date_gmt":"2022-07-13T13:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/retbleed-novaya-ataka-na-mehanizm-spekulyativnogo-vypolneniya-cpu-intel-i-amd"},"modified":"2022-07-13T15:36:38","modified_gmt":"2022-07-13T13:36:38","slug":"retbleed-novaya-ataka-na-mehanizm-spekulyativnogo-vypolneniya-cpu-intel-i-amd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/retbleed-novaya-ataka-na-mehanizm-spekulyativnogo-vypolneniya-cpu-intel-i-amd","title":{"rendered":"Retbleed \u2014 ein neuer Angriff auf den Mechanismus der spekulativen Ausf\u00fchrung von Intel- und AMD-Prozessoren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Eine Gruppe von Forschern der ETH Z\u00fcrich hat eine neue Angriffsvariante auf den Mechanismus der spekulativen Ausf\u00fchrung indirekter Spr\u00fcnge in CPUs entdeckt. Dieser Angriffsvektor erm\u00f6glicht es, Informationen aus dem Kernel-Speicher zu extrahieren oder Angriffe auf das Host-System von virtuellen Maschinen aus zu starten. Die Schwachstellen tragen die Codenamen Retbleed (CVE-2022-29900, CVE-2022-29901) und sind in ihrer Natur vergleichbar mit den Spectre-v2-Angriffen. Der Unterschied liegt in der Spekulation \u00fcber die Ausf\u00fchrung beliebigen Codes bei der Verarbeitung des Befehls \u201eret\u201c (return), der die Adresse f\u00fcr den \u00dcbergang aus dem Stack extrahiert, im Gegensatz zum indirekten Sprung mittels des Befehls \u201ejmp\u201c, bei dem die Adresse aus dem Speicher oder einem CPU-Register geladen wird. <\/p>\n
Ein Angreifer kann Bedingungen schaffen, die zu einer falschen Vorhersage des Sprunges f\u00fchren, und einen gezielten spekulativen Sprung zu einem Codeblock organisieren, der nicht durch die Programmlogik vorgesehen ist. Letztendlich wird der Prozessor feststellen, dass die Vorhersage der Verzweigung nicht korrekt war und die Operation in ihren urspr\u00fcnglichen Zustand zur\u00fccksetzen. Die w\u00e4hrend der spekulativen Ausf\u00fchrung bearbeiteten Daten werden jedoch im Cache und in mikroarchitektonischen Puffern verbleiben. Wenn der fehlerhaft ausgef\u00fchrte Block auf den Speicher zugreift, f\u00fchrt dessen spekulative Ausf\u00fchrung zu einer Ablagerung im allgemeinen Cache und zu Daten, die aus dem Speicher gelesen wurden. <\/p>\n
Um Daten zu identifizieren, die nach spekulativer Ausf\u00fchrung von Operationen im Cache verbleiben, kann ein Angreifer Methoden zur Identifizierung von Restdaten \u00fcber externe Kan\u00e4le verwenden, beispielsweise indem er die Zugriffszeit auf gecachte und nicht gecachte Daten analysiert. F\u00fcr gezielte Informationen aus Bereichen mit einem anderen Berechtigungsniveau (z. B. aus dem Kernspeicher) werden \u201eGadgets\u201c eingesetzt \u2013 im Kernel vorhandene Befehlselemente, die sich f\u00fcr spekulatives Auslesen von Daten aus dem Speicher eignen, abh\u00e4ngig von \u00e4u\u00dferen Bedingungen, die vom Angreifer beeinflusst werden k\u00f6nnen. <\/p>\n
Um sich vor klassischen Spectre-Angriffen zu sch\u00fctzen, bei denen bedingte und indirekte Sprungbefehle verwendet werden, setzen die meisten Betriebssysteme die Technik \u201eretpoline\u201c ein. Diese basiert darauf, indirekte Sprungbefehle durch den Befehl \u201eret\u201c zu ersetzen, f\u00fcr den Prozessoren einen speziellen Stapelvorhersage-Block verwenden, der keinen Sprungvorhersage-Block nutzt. Bei der Einf\u00fchrung von retpoline im Jahr 2018 ging man davon aus, dass \u00e4hnliche Manipulationen wie bei Spectre in der Praxis nicht f\u00fcr spekulative Spr\u00fcnge mit dem Befehl \u201eret\u201c zusagbar sind. <\/p>\n
Die Forscher, die die Angriffsmethode Retbleed entwickelt haben, demonstrierten die M\u00f6glichkeit, mikroarchitektonische Bedingungen zu schaffen, um spekulative Spr\u00fcnge mit dem Befehl \u201eret\u201c zu initiieren. Au\u00dferdem ver\u00f6ffentlichten sie umfangreiche Werkzeuge zur Identifizierung von Schwachstellen in der Linux-Kernel-Umgebung, welche geeignete Gadget-Sequenzen enthalten, in denen solche Bedingungen auftreten. <\/p>\n
Im Rahmen der Untersuchung wurde ein funktionierender Exploit entwickelt, der es erm\u00f6glicht, auf Systemen mit Intel-CPUs aus einem nicht privilegierten Benutzerprozess zuf\u00e4llige Daten mit einer Geschwindigkeit von 219 Bytes pro Sekunde und einer Genauigkeit von 98 % aus dem Kernel-Speicher auszulesen. Bei AMD-Prozessoren ist die Effizienz des Exploits wesentlich h\u00f6her \u2013 die Leckagegeschwindigkeit betr\u00e4gt 3,9 KB pro Sekunde. Als praktisches Beispiel wird gezeigt, wie man mit dem vorgeschlagenen Exploit den Inhalt der Datei \/etc\/shadow bestimmen kann. Auf Systemen mit Intel-CPUs wurde der Angriff zur Bestimmung des Passwort-Hashes des Root-Benutzers innerhalb von 28 Minuten durchgef\u00fchrt, w\u00e4hrend dies auf Systemen mit AMD-CPUs in nur 6 Minuten gelang.
\r\n \r\n
<\/div>\r\n <\/div><\/center> <\/p>\n
Die M\u00f6glichkeit eines Angriffs wurde f\u00fcr die 6. bis 8. Generation von Intel-Prozessoren best\u00e4tigt, die bis zum dritten Quartal 2019 (einschlie\u00dflich Skylake) hergestellt wurden, sowie f\u00fcr AMD-Prozessoren basierend auf den Mikroarchitekturen Zen 1, Zen 1+ und Zen 2, die bis zum zweiten Quartal 2021 produziert wurden. Bei neueren Prozessor-Modellen, wie AMD Zen3 und Intel Alder Lake, sowie bei ARM-Prozessoren, wird das Problem durch vorhandene Schutzmechanismen blockiert. Zum Beispiel hilft die Anwendung von IBRS-Instruktionen (Indirect Branch Restricted Speculation), sich gegen solche Angriffe zu sch\u00fctzen. <\/p>\n
F\u00fcr den Linux-Kernel und den Hypervisor Xen wurde eine Reihe von \u00c4nderungen vorbereitet, die auf \u00e4lteren CPUs das Problem softwareseitig beheben. Der f\u00fcr den Linux-Kernel vorgeschlagene Patch \u00e4ndert 68 Dateien, f\u00fcgt 1783 Zeilen hinzu und entfernt 387 Zeilen. Leider f\u00fchrt der Schutz zu erheblichen overhead-Kosten \u2014 in durchgef\u00fchrten Tests auf AMD- und Intel-Prozessoren wird der Leistungsabfall mit 14 % bis 39 % beziffert. Eine bevorzugte L\u00f6sung ist die Anwendung eines auf IBRS-Instruktionen basierenden Schutzmechanismus, der in neuen Generationen von Intel-CPUs verf\u00fcgbar ist und ab Kernel-Version 4.19 unterst\u00fctzt wird. <\/p>\n
Bei Intel-Prozessoren erfolgt die Adresssubstitution f\u00fcr spekulative indirekte Spr\u00fcnge aufgrund einer Besonderheit, die beim Unterlauf (underflow) im R\u00fcckgabestapel (Return Stack Buffer) auftritt. Unter solchen Bedingungen beginnt die Logik zur Adressauswahl f\u00fcr die 'ret'-Anweisung, \u00e4hnlich wie bei regul\u00e4ren indirekten Spr\u00fcngen, angewendet zu werden. Im Linux-Kernel wurden \u00fcber tausend Stellen gefunden, die Bedingungen f\u00fcr das Ausl\u00f6sen eines solchen R\u00fccklaufunterlaufs schaffen und \u00fcber Systemaufrufe zug\u00e4nglich sind. <\/p>\n
Auf AMD-Prozessoren erfolgt die spekulative Ausf\u00fchrung der R\u00fcckgabeinstruktion «ret» unabh\u00e4ngig von einem stack-spezifischen R\u00fcckadresse-Stack. Der Vorhersageblock betrachtet die Instruktion «ret» nicht als R\u00fccksprung, sondern als indirekten Sprung, und nutzt entsprechend Daten f\u00fcr indirekte Spr\u00fcnge bei der Vorhersage. In diesen Bedingungen kann praktisch jede «ret»-Operation, die \u00fcber einen Systemaufruf erreichbar ist, zur Ausnutzung verwendet werden. <\/p>\n
Zus\u00e4tzlich wurde bei AMD-CPUs ein weiteres Problem (CVE-2022-23825, Branch Type Confusion) festgestellt, das mit dem Ausf\u00fchren von falschen Spr\u00fcngen zusammenh\u00e4ngt \u2013 Vorhersagebedingungen k\u00f6nnen auch ohne die notwendigen Branching-Instruktionen auftreten, was es erm\u00f6glicht, den Vorhersagepuffer ohne die «ret»-Instruktion zu beeinflussen. Diese Eigenschaft erschwert die Implementierung von Schutzma\u00dfnahmen erheblich und erfordert eine aktivere Bereinigung des Vorhersagebuffers. Es wird erwartet, dass die vollst\u00e4ndige Implementierung von Schutzma\u00dfnahmen im Kernel zu einer Steigerung der Overhead-Kosten um 209% f\u00fchrt. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Video](\"https:\/\/img.youtube.com\/vi\/dmSPvJxPm80\/hqdefault.jpg\")
\r\n