{"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\/news\/retbleed-novaya-ataka-na-mehanizm-spekulyativnogo-vypolneniya-cpu-intel-i-amd","title":{"rendered":"Retbleed \u2014 ein neuer Angriff auf die Mechanik der spekulativen Ausf\u00fchrung von Intel- und AMD-CPUs","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, die es erm\u00f6glicht, Informationen aus dem Kernspeicher zu extrahieren oder Angriffe auf das Host-System aus virtuellen Maschinen durchzuf\u00fchren. Die Schwachstellen wurden mit dem Codenamen Retbleed (CVE-2022-29900, CVE-2022-29901) versehen und sind in ihrem Wesen den Spectre-v2-Angriffen \u00e4hnlich. Der Unterschied besteht darin, dass bei der Ausf\u00fchrung des spekulativen Codes ein R\u00fcckgabebefehl \u201eret\u201c verwendet wird, der die Adresse aus dem Stack extrahiert, anstelle eines indirekten Sprungs durch einen \u201ejmp\u201c-Befehl, der die Adresse aus dem Speicher oder dem CPU-Register l\u00e4dt. <\/p>\n
Der Angreifer kann Bedingungen schaffen, die zu falschen Vorhersagen des Sprunges f\u00fchren, und einen gezielten spekulativen Sprung auf einen Codeblock durchf\u00fchren, der nicht in der Programmlogik vorgesehen ist. Letztendlich wird der Prozessor feststellen, dass die Vorhersage der Verzweigung nicht zutraf und die Operation in den urspr\u00fcnglichen Zustand zur\u00fcckkehrt, jedoch werden die w\u00e4hrend der spekulativen Ausf\u00fchrung verarbeiteten Daten im Cache und in mikroarchitektonischen Puffern verbleiben. Sollte der fehlerhaft ausgef\u00fchrte Block auf den Speicher zugreifen, f\u00fchrt seine spekulative Ausf\u00fchrung zu einem Verweilen in dem gemeinsamen Cache und den aus dem Speicher ausgelesenen Daten. <\/p>\n
Um die Daten zu bestimmen, die nach der spekulativen Ausf\u00fchrung von Operationen im Cache geblieben sind, kann der Angreifer Methoden zur Ermittlung von Restdaten durch Seitenkan\u00e4le verwenden, zum Beispiel durch die Analyse der Zugriffszeiten auf zwischengespeicherte und nicht zwischengespeicherte Daten. F\u00fcr gezielte Informationen aus Bereichen mit anderer Berechtigungsstufe (zum Beispiel aus dem Kernspeicher) werden \u201eGadgets\u201c verwendet \u2013 im Kern vorhandene Befehlsketten, die zur spekulativen Datenlesung aus dem Speicher geeignet sind, abh\u00e4ngig von externen Bedingungen, auf die der Angreifer Einfluss nehmen kann. <\/p>\n
Zum Schutz vor klassischen Spectre-Angriffen, die bedingte und indirekte Sprungbefehle verwenden, wird in den meisten Betriebssystemen die Technik \u201eretpoline\u201c angewendet, die darauf basiert, die indirekten Sprungoperationen durch den Befehl \u201eret\u201c zu ersetzen, f\u00fcr den in den Prozessoren ein separater Stack-Zustandsvorhersageblock verwendet wird, der keinen Sprungvorhersageblock nutzt. Bei der Einf\u00fchrung von retpoline im Jahr 2018 wurde angenommen, dass \u00e4hnliche Adressmanipulationen wie bei Spectre in der Praxis f\u00fcr spekulative Spr\u00fcnge mit dem Befehl \u201eret\u201c nicht anwendbar sind. <\/p>\n
Die Forscher, die die Retbleed-Angriffsmetode entwickelt haben, haben die M\u00f6glichkeit demonstriert, mikroarchitektonische Bedingungen f\u00fcr die Initiierung eines spekulativen Sprungs mit dem Befehl \u201eret\u201c zu schaffen, und ver\u00f6ffentlichten ein fertiges Toolkit zur Identifizierung von in Linux-Kernel geeigneten Schwachstellen in den Befehlsketten (Gadgets), 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 beliebige Daten aus dem Kernel-Speicher mit einer Geschwindigkeit von 219 Byte pro Sekunde und einer Genauigkeit von 98 % zu extrahieren. Auf AMD-Prozessoren ist die Effizienz des Exploits erheblich h\u00f6her \u2013 die Leak-Geschwindigkeit betr\u00e4gt 3,9 KB pro Sekunde. Als praktisches Beispiel wird gezeigt, wie mit dem vorgeschlagenen Exploit der Inhalt der Datei \/etc\/shadow bestimmt werden kann. Auf Systemen mit Intel-CPUs wurde der Angriff zur Bestimmung des Hashs des Root-Passworts in 28 Minuten durchgef\u00fchrt, w\u00e4hrend es auf Systemen mit AMD-CPUs nur 6 Minuten dauerte.
\r\n \r\n
<\/div>\r\n <\/div><\/center> <\/p>\n
Die M\u00f6glichkeit des Angriffs wurde f\u00fcr die 6. bis 8. Generation der Intel-Prozessoren best\u00e4tigt, die bis zum 3. Quartal 2019 hergestellt wurden (einschlie\u00dflich Skylake), sowie f\u00fcr AMD-Prozessoren auf Basis der Mikroarchitekturen Zen 1, Zen 1+ und Zen 2, die bis zum 2. Quartal 2021 produziert wurden. In neueren Prozessor-Modellen wie AMD Zen3 und Intel Alder Lake sowie in ARM-Prozessoren wird das Problem durch vorhandene Schutzmechanismen blockiert. Beispielsweise hilft die Verwendung von IBRS-Anweisungen (Indirect Branch Restricted Speculation), sich gegen den Angriff zu sch\u00fctzen. <\/p>\n
F\u00fcr den Linux-Kernel und den Hypervisor Xen wurde ein Satz von \u00c4nderungen vorbereitet, die auf \u00e4lteren CPUs das Problem softwareseitig blockieren. Der vorgeschlagene Patch f\u00fcr den Linux-Kernel ver\u00e4ndert 68 Dateien, f\u00fcgt 1783 Zeilen hinzu und entfernt 387 Zeilen. Leider f\u00fchrt der Schutz zu erheblichen Overheadkosten \u2013 in durchgef\u00fchrten Tests wird auf AMD- und Intel-Prozessoren eine Leistungsreduzierung von 14 % bis 39 % festgestellt. Eine bevorzugte L\u00f6sung ist der Schutz auf Basis von IBRS-Anweisungen, die in neuen Generationen von Intel-CPUs verf\u00fcgbar sind und ab Linux-Kernel 4.19 unterst\u00fctzt werden. <\/p>\n
Bei Intel-Prozessoren erfolgt die Adressersetzung f\u00fcr spekulative indirekte Spr\u00fcnge aufgrund einer Eigenschaft, die sich bei einem Underflow im Return Stack Buffer zeigt. Unter diesen Bedingungen beginnt die Logik zur Adresswahl f\u00fcr die 'ret'-Anweisung, \u00e4hnlich wie bei normalen indirekten Spr\u00fcngen, angewendet zu werden. Im Linux-Kernel wurden \u00fcber tausend Stellen gefunden, die Bedingungen schaffen, die ein solches Reverse-Overflow initiieren und \u00fcber Systemaufrufe erreichbar sind. <\/p>\n
Auf AMD-Prozessoren erfolgt die spekulative Ausf\u00fchrung der 'ret'-Anweisung ohne Bindung an einen spezifischen R\u00fcckgabepuffer (Return Address Stack), und der Branch-Prediction-Block betrachtet die 'ret'-Anweisung nicht als R\u00fcckkehr der Kontrolle, sondern als indirekten Sprung und verwendet entsprechend die Daten zur Vorhersage f\u00fcr indirekte Spr\u00fcnge. Unter solchen Bedingungen kann jede 'ret'-Operation, die \u00fcber einen Systemaufruf erreichbar ist, tats\u00e4chlich f\u00fcr einen Exploit verwendet werden. <\/p>\n
Zus\u00e4tzlich wurde im AMD CPU ein weiteres Problem (CVE-2022-23825, Branch Type Confusion) entdeckt, das mit der Ausf\u00fchrung von spekulativen Spr\u00fcngen zusammenh\u00e4ngt \u2014 Bedingungen f\u00fcr die Sprungvorhersage k\u00f6nnen auch ohne die erforderlichen Verzweigungsanweisungen auftreten, was es erm\u00f6glicht, den Sprungvorhersagepuffer ohne die Anweisung \u201eret\u201c zu beeinflussen. Diese Eigenschaft erschwert die Implementierung von Schutzma\u00dfnahmen erheblich und erfordert eine aktivere Bereinigung des Sprungvorhersagepuffers. Es wird erwartet, dass die vollst\u00e4ndige Implementierung des Schutzes im Kernel zu einer Erh\u00f6hung der Overhead-Kosten um 209 % f\u00fchren wird. \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