{"id":30181,"date":"2023-05-31T14:44:59","date_gmt":"2023-05-31T12:44:59","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=30181"},"modified":"2023-05-31T14:44:59","modified_gmt":"2023-05-31T12:44:59","slug":"transient-cpu-eflags","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/transient-cpu-eflags\/30181\/","title":{"rendered":"Neue Hardware-Schwachstelle in Intel-Prozessoren"},"content":{"rendered":"

Forscher der University of Maryland in den USA und der Tsinghua University in China haben eine Forschungsarbeit<\/a> ver\u00f6ffentlicht, die eine neue Side-Channel-Angriffsmethode dokumentiert, die eine bislang unbekannte Hardware-Schwachstelle in Intel-Prozessoren ausnutzt. Obwohl die Schwachstelle die neuesten Prozessoren des Chip-Herstellers zu betreffen scheint, ist sie besonders effektiv bei Angriffen auf \u00e4ltere Modelle, die ebenfalls von der Schwachstelle Meltdown<\/a> betroffen sind. Das Paper w\u00e4re vermutlich von rein wissenschaftlichem Interesse, w\u00e4re da nicht folgender Umstand: Angreifer k\u00f6nnen sensible Informationen stehlen, indem sie die Daten von Statusregistern<\/a> ver\u00e4ndern.<\/p>\n

Sie verstehen nur Bahnhof?<\/h2>\n

Sicherheitsl\u00fccken in Hardware-Prozessoren, die mit der spekulativen Ausf\u00fchrung von Befehlen zusammenh\u00e4ngen, werden seit mehr als f\u00fcnf Jahren<\/a> intensiv erforscht. Um das Ganze m\u00f6glichst zu vereinfachen, kann man alle vorgeschlagenen Angriffe folgenderma\u00dfen zusammenfassen: Die CPU wird irgendwie dazu gezwungen, Daten zu lesen, auf die der Benutzer keinen Zugriff haben sollte. Stellen Sie sich folgendes theoretisches Szenario vor: Das Programm des Angreifers hat keinen Zugriff auf den Verschl\u00fcsselungsschl\u00fcssel, der zum Schutz sensibler Daten verwendet wird. Wird die CPU angewiesen, \u201eden Verschl\u00fcsselungscode einer bestimmten Adresse zu lesen\u201c, wird diese Anweisung einfach nicht befolgt. Hilfe bekommt (der Angreifer) aber in Form einer spekulativen Ausf\u00fchrung<\/a> von Befehlen \u2013 ein wichtiges Merkmal moderner CPUs, das es seit fast drei Jahrzehnten gibt: Denn zur Beschleunigung der Abl\u00e4ufe wartet der Prozessor nicht, bis ein Befehl beendet ist, sondern f\u00fchrt den n\u00e4chsten bereits parallel zum vorherigen aus.<\/p>\n

\u00dcberpr\u00fcft der erste Befehl die Zugriffsrechte auf sensible Informationen, sollte er theoretisch nicht zulassen, dass der nachfolgende Befehl diese Informationen liest. Doch daf\u00fcr ist es bereits zu sp\u00e4t, da der nachfolgende Befehl spekulativ ausgef\u00fchrt wird. Man bedenke dabei, dass wir zu diesem Zeitpunkt noch keinen Zugriff auf diese Daten haben \u2013 die CPU aber schon. Im Falle bekannter Sicherheitsl\u00fccken wie Spectre<\/a> werden die Daten vor\u00fcbergehend in den Cache der CPU geladen, k\u00f6nnen aber nicht einfach so gelesen werden. Sie lassen sich jedoch \u00fcber Seitenkan\u00e4le auslesen, z. B. durch die wiederholte Ausf\u00fchrung eines Befehls, dessen Verarbeitungszeit von den Daten im Cache abh\u00e4ngt. Die Wiederholung eines solchen Vorgangs viele (tausende!) Male erm\u00f6glicht es Angreifern, Daten wiederherzustellen, indem sie einfach beobachten, wie schnell oder langsam ein scheinbar harmloser Befehl ausgef\u00fchrt wird.<\/p>\n

Wir sind uns dar\u00fcber im Klaren, dass diese \u201eeinfache\u201c Beschreibung immer noch kompliziert klingt. In dem j\u00fcngsten Paper wird es sogar noch verwirrender, zumal die Autoren auf eine detaillierte Beschreibung des Angriffs verzichtet haben. Das nachstehende Diagramm gibt einen vollst\u00e4ndigen \u00dcberblick:<\/p>\n

\"\u00dcberblick<\/a>

\u00dcberblick \u00fcber den Seitenkanal der transienten Ausf\u00fchrungszeit. Quelle<\/a>.<\/p><\/div>\n

\u00a0<\/p>\n

Versuchen wir erneut Licht ins Dunkel zu bringen. EFLAGS ist ein Statusregistser im Intel-Prozessor, das den Betriebsstatus der CPU protokolliert. In diesem Register kann das Ergebnis von Berechnungen gespeichert<\/a> werden, insbesondere wenn es gleich Null ist (das so genannte Nullflag oder Zero Flag<\/em>). Jetzt kommt die Magie: Angenommen, ein Kollege von Ihnen denkt an eine Zahl zwischen 1 und 10 und wird aufgefordert, diese f\u00fcr sich zu behalten. Sie nennen ihm immer wieder die Zahlen von 1 bis 10 (auf der Suche nach irgendwelchen Hinweisen, die Ihren Kollegen verraten k\u00f6nnten), doch dieser will die richtige Antwort nicht mit Ihnen teilen und antwortet jedes Mal mit dem Wort \u201eChrysanthemum\u201c. Doch immer wenn Sie die richtige Zahl erw\u00e4hnen, braucht Ihr Kollege im Vergleich zu anderen Gelegenheiten etwas l\u00e4nger, um \u201eChrysanthemum\u201c zu antworten.<\/p>\n

Etwas \u00c4hnliches passiert bei diesem neuen Angriff: Wir f\u00fchren zahlreiche Berechnungen mit sensiblen Daten durch. All diese Berechnungen werden spekulativ durchgef\u00fchrt. Die Ergebnisse werden im Nullflag erfasst (gleich oder ungleich Null). Den Status dieses Flags k\u00f6nnen wir nicht direkt erfahren, bis wir einen ziemlich nutzlosen JCC-Befehl aus (speziell den JZ-Befehl \u2013 \u201ejump if zero<\/em>\u201e), der etwas langsamer ausgef\u00fchrt wird, sofern wir richtig liegen! Und genau diese messbare Verz\u00f6gerung in der Antwort macht die Schwachstelle aus.<\/p>\n

Bis dato kein Problem<\/h2>\n

Interessant an diesem Angriff ist vor allem, dass er nicht eigenst\u00e4ndig funktioniert. Um sicherzustellen, dass die spekulative Ausf\u00fchrung der erforderlichen Anweisungen m\u00f6glich ist, m\u00fcssen die Angreifer eine weitere Sicherheitsl\u00fccke ausnutzen. Das von uns behandelte Paper nutzt die 2018 entdeckte Meltdown<\/a>-Schwachstelle, die gerne Zugriff auf Informationen gew\u00e4hrt, die f\u00fcr Au\u00dfenstehende tabu sind. So konnten sensible Daten mit 100%iger Zuverl\u00e4ssigkeit auf allen alten CPUs gelesen werden, die von dieser Schwachstelle betroffen waren (in der Studie wurden Intel Core i7 der sechsten und siebten Generation verwendet). Zwar schlug das Experiment bei CPUs der zehnten Generation fehl, doch auch bei ihnen kam es zu einer gewissen Verz\u00f6gerung bei der Ausf\u00fchrung eines bestimmten Befehls der JCC-Klasse.<\/p>\n

Tats\u00e4chlich haben selbst flexiblere Angriffstypen wie Spectre, bei denen Informationen aus dem Cache der CPU gestohlen werden, einen eher begrenzten Anwendungsbereich. Doch zumindest in ihrem Fall war es offensichtlich, dass etwas unternommen werden musste: Die Wahrscheinlichkeit eines fortgeschrittenen Angriffs auf sensible Daten war nicht gleich null. In der neuen Studie geht es eher um eine Idee, die, wenn sie \u00fcberhaupt funktioniert, auf \u00e4ltere Intel-Prozessoren zutrifft.<\/p>\n

Die Neuigkeiten selbst sind jedoch bedeutsam: Es gibt nun einen neuen Side-Channel-Mechanismus zum Extrahieren von Daten unter Verwendung des Flag-Statusregisters. Man kann nicht ausschlie\u00dfen, dass dieser Ansatz, in Kombination mit einer anderen Sicherheitsl\u00fccke, in Zukunft auch neue CPUs betreffen wird. M\u00f6glicherweise wird das Problem aber auch gel\u00f6st, bevor wir einen neuen Angriff zu Gesicht bekommen: immerhin ist die Abh\u00e4ngigkeit der Befehlsausf\u00fchrungszeit von den Daten ein ziemlich gravierendes Problem. Es gibt eine ganze Unterdisziplin der Kryptographie, die sich mit dem Schutz von Verschl\u00fcsselungsalgorithmen vor Timing-Attacken<\/a> besch\u00e4ftigt.<\/p>\n

In jedem Fall wird die Forschung im Hinblick auf die Besonderheiten moderner CPUs fortgesetzt. Zum Gl\u00fcck ist es genauso schwierig, Angriffe auf Hardware-Schwachstellen auszuf\u00fchren, wie sie zu verstehen. Und auch wenn wir bisher keinerlei M\u00f6glichkeiten zur massiven Anwendung gesehen haben, sollten Sicherheitsbeauftragte in Unternehmen, die mit hochsensiblen Daten arbeiten, solche Bedrohungen einkalkulieren und zumindest deren Entwicklung beobachten.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Eine kurze, verst\u00e4ndliche Erkl\u00e4rung einer fortgeschrittenen Methode des Datendiebstahls unter Einsatz von Funktionen moderner CPUs.<\/p>\n","protected":false},"author":665,"featured_media":30182,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[3185,4069,1498],"class_list":{"0":"post-30181","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-cpu","11":"tag-prozessoren","12":"tag-schwachstellen"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/transient-cpu-eflags\/30181\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/transient-cpu-eflags\/25691\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/transient-cpu-eflags\/21110\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/transient-cpu-eflags\/28346\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/transient-cpu-eflags\/25991\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/transient-cpu-eflags\/26367\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/transient-cpu-eflags\/28862\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/transient-cpu-eflags\/35326\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/transient-cpu-eflags\/48229\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/transient-cpu-eflags\/20650\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/transient-cpu-eflags\/21345\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/transient-cpu-eflags\/26296\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/transient-cpu-eflags\/31998\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/transient-cpu-eflags\/31686\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/schwachstellen\/","name":"Schwachstellen"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=30181"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30181\/revisions"}],"predecessor-version":[{"id":30184,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30181\/revisions\/30184"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/30182"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=30181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=30181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=30181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}