News Intel CPUs über Cache Poisoning angreifbar

Die Sicherheitsexperten <a href="http://www.blogger.com/profile/07657268181166351141" target="b">Joanna Rutkowska</a> und Rafal Wojtczuk von InvisibleThingsLab.com haben wie angekündigt ihr Paper zum Thema "Attacking SMM Memory via Intel CPU Cache Poisoning" veröffentlicht (<a href="http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf" target="b">PDF</a>, 157 KB). Darin wird beschrieben, wie mittels eines Cache-Poisoning-Angriffs Schadcode auf Intel-Prozessoren ausgeführt werden kann. Das kritische an dieser Sicherheitslücke ist die Tatsache, dass der Angriff über System Management Mode Code erfolgt und somit im geschützten SMRAM residiert. Bei SMM handelt es sich um den priviligiertesten Betriebsmodus einer x86/x86_64 CPU, die Autoren sprechen von "Ring -2" um zu betonen, dass SMM selbst priviligierter ist als Hardware Hypervisors, die in der Regel im "Ring -1" operieren.

Voraussetzung für einen erfolgreichen Angriff sind Administratorrechte auf dem betreffenden System, da ein Zugriff auf die MSR-Register erfolgen muss. Zudem ist ein Intel-Chipsatz von Nöten. Der Trick liegt darin, dem Mikroprozessor den Schadcode unterzuschieben, ihn zu cachen (was im SMRAM/SMM Ring -2 eigentlich nicht funktionieren darf) und anschließend via SMI die Ausführung von SMM-Code zu triggern. Dieser übernimmt anschließend ohne weitere Integritäts- oder Kohärenzprüfung den Schadecode aus dem Cache und führt diesen im Ring -2 aus. Ein solcher Angriff ist von außen nicht ohne weiteres erkennbar, da es keinen priviligierteren Modus als "Ring -2" gibt. Die Autoren sprechen somit korrekterweise von "SMM rootkits, hypervisor compromises, or OS kernel protection bypassing".

Betroffen sind alle Intel-Prozessoren, die auf Mainboards mit Chipsätzen bis zur einschließlich der 35-Serie (P35, Q35, etc.) laufen. Neuere Chipsätze der 45-Serie sollen nicht mehr betroffen sein. Intel hat auf das Paper reagiert und bekannt gegeben, dass bereits seit längerem an einer Lösung gearbeitet würde und man diesbezüglich auch sehr eng mit OEMs und BIOS-Herstellern kooperiert. Obwohl, laut Intel, die meisten aktuellen Systeme davon nicht mehr betroffen sein sollten, gelang es den Autoren, den Angriff erfolgreich auf einem DQ35-Mainboard durchzuführen. Doch selbst wenn alle neuen Mainboards als sicher gelten, die installierte Basis ist besorgniserregend, da nicht damit zu rechnen ist, dass jeder betroffene Rechner via BIOS-Update oder Hardwareupgrade repariert wird, falls dies vom Hersteller überhaupt angeboten wird - potenziell ist auch ein Hinweis à la "im neuen Produkt aber schon behoben, bitte kaufen" möglich und nach Ablauf der Garantiezeit auch recht wahrscheinlich. Man kann also davon ausgehen, dass die installierte Basis noch über mehrere Jahre existieren und somit ein potenzielles Sicherheitsrisiko darstellen wird. Vorausgesetzt natürlich dass entsprechende Angriffe erfolgen werden.

Weitere Informationen, sowie Exploits und eine Demonstration des Problems befinden sich auf der <a href="http://invisiblethingslab.com/itl/Resources.html" target="b">Webseite von Invisible Things Lab</a>.

Die Ausführungen der guten Frau sind mir leider zu hoch. Könnte jemand ein Beispiel für mich konstruieren, bei dem es jem. mit Adminrechten hilft, der CPU Code unterzuschieben?

mit 24h Verspätung (http://www.planet3dnow.de/vbulletin/showthread.php?t=359022)

da kann Intel sich schonma "warm" anziehen ...

hier stand nichts zur Sache. Hatte es zuerst nur überflogen

wintermute_3dc schrieb:

Die Ausführungen der guten Frau sind mir leider zu hoch. Könnte jemand ein Beispiel für mich konstruieren, bei dem es jem. mit Adminrechten hilft, der CPU Code unterzuschieben?

Zum Vergrößern anklicken....

Das könnte durch schon unter Vista und beim Installieren von infizierten Anwendungsprogrammen oder Treibern geschehen oder ?

'Neuer Chipsatztreiber für Intel mit verbotenen Einstellmöglichkeiten' ...

Prinzipiell dürfte der Bug aber nicht größer sein als ein typ. Bug in Windows.
Ist mal ungewöhnlich, dass Hardware direkt beteiligt ist aber sonst auch nicht.

Ich bin kein Intel-Freund, aber man sollte Restrisiken nicht überbetonen.

rkinet schrieb:

Prinzipiell dürfte der Bug aber nicht größer sein als ein typ. Bug in Windows.
Ist mal ungewöhnlich, dass Hardware direkt beteiligt ist aber sonst auch nicht.

Ich bin kein Intel-Freund, aber man sollte Restrisiken nicht überbetonen.

Zum Vergrößern anklicken....

so wie ich das verstanden habe ist das problem aber dass ein schadcode der über einen solchen mechanismus ausgeführt wird prinzipiell BS unabhängig fungieren kann. im dem Paper von der guten Frau ist es ja unter linux gemacht worden, mit win wäre es natürlich aber auch gegangen.
Zitat aus dem paper

Of course on different systems than Linux, e.g.
Windows, one doesn't have such a convenient
access to /proc/mtrr pseudo-file. This is
however only a minor technicality, as one can very
well modify the MTRRs mapping using the
standard WRMSR instructions

Zum Vergrößern anklicken....

eine plattformunabhängige mäglichkeit der schadcode ausführen ist doch relativ ungewöhnlich, oder habe ich das falsch verstanden?

hab noch ein p35 board. tauscht mir intel das jetzt kostenlos gegen ein p45?

auch wenns bisher kaum auf News-Seiten zufinden ist,

heise hats schonmal

heavy-Ions@boinc schrieb:

so wie ich das verstanden habe ist das problem aber dass ein schadcode der über einen solchen mechanismus ausgeführt wird prinzipiell BS unabhängig fungieren kann. im dem Paper von der guten Frau ist es ja unter linux gemacht worden, mit win wäre es natürlich aber auch gegangen.

eine plattformunabhängige mäglichkeit der schadcode ausführen ist doch relativ ungewöhnlich, oder habe ich das falsch verstanden?

Zum Vergrößern anklicken....

Der ist damit sogar weitaus gefährlicher. Der Bug lässt sich weder leicht weg patchen noch erkennen, wenn ihn jemand ausgenutzt hat. Damit lassen sich Systeme kompromittieren, ohne dass der Betroffene eine Chance zur Gegenwehr hat.

Ohne jetzt Flamen zu wollen, sollte man mit AMD wohl auf der sichererererererereren Seite sein?

Schon hart, was die Leute so alles rausfinden...

deshalb wird auch Intel weiterhin versuchen es zu "vertuschen" - dies wird (evtl) ein viel größerer Imageschaden als der "unwichtige" TLB-Bug bei AMD ...

oder habt ihr schon auf allen wichtigen Seiten etwas über den Intel-Ring?-Bug gefunden ?

heise ja ... aber die anderen ?

Voraussetzung für einen erfolgreichen Angriff sind Administratorrechte

Zum Vergrößern anklicken....

Wenn ich doch schon Administratorrechte habe bringt mir der Angriff doch nichts mehr. Natürlich kann man im "Ring -2" noch viel mehr anstellen, aber praktisch ist es doch schon vorbei wenn ein Angriffer "nur" Administratorrechte erlangt hat. Oder liegt das Problem hier ganz woanders?

auch Admins können unter Windows nicht alles - "Godmode" wäre zB LocalSystem;

versuch doch mal unter Windows die Subkeys von HKLM\SAM zu öffnen ... (sofern man die überhaupt sieht)

Das ist mir schon klar, mir will nur keine reale Bedrohung einfallen. Das Ziel eines Angreifers ist doch entweder das Erlangen von kritischen Resourcen oder das Zerstören derselbigen. Hat man erstmal Administratorrechte braucht man dazu doch nicht noch mehr Rechte. Der beschriebene Angriff ist ja kein Schlupfloch an den etablierten Schutzmechanismen vorbei sondern gräbt nur tiefer nachdem alle Mauern schon überwunden sind. Mir würden nur "Einsatzmöglichkeiten" einfallen wenn es bei einem System darum geht als Administrator etwas zu tun was ein anderer Administrator nicht sehen soll.

EDIT: Argh, Freitag Nachmittag geht bei mir eben nichts mehr

Skandal ist das! Ich bin entrüstet, schockiert, fassungslos! Zumindest bei AMD wäre es das halbe Forum ebenfalls.

Ich finds übrigens klasse, dass bei Problemen mit Intel-HW die Diskussionen hier recht gesittet ablaufen und man nicht in Polemik verfällt. Ich denke das ist den beherrschten AMD-Fans zu verdanken. Würde mir sowas auch anders herum wünschen.

unbekannt verzogen schrieb:

Zumindest bei AMD wäre es das halbe Forum ebenfalls.

Zum Vergrößern anklicken....

Und im Forumdeluxx zum Beispiel wurde das Thema dazu nach ein paar „Langweilig!“-, „Unwichtig“- und „Olle Kamellen“-Beiträgen kommentarlos geschlossen.

Haruspex schrieb:

Und im Forumdeluxx zum Beispiel wurde das Thema dazu nach ein paar „Langweilig!“-, „Unwichtig“- und „Olle Kamellen“-Beiträgen kommentarlos geschlossen.

Zum Vergrößern anklicken....

Eigentlich wollte ich "no comment" schreiben, aber jetzt kommentiere ich doch:

"Genial" ...

ciao

Alex

Peinlich für Intel ist - die haben es selbst entdeckt und den fix dazu sogar patentiert aber jahrelang nix dagegen getan (http://www.tomshardware.com/de/foren/241192-3-angriffe-intel-architekturen)

Crashtest schrieb:

deshalb wird auch Intel weiterhin versuchen es zu "vertuschen" ...

Zum Vergrößern anklicken....

Liest du eigentlich den P3D-Thread "Schwerwiegende Intel CPU Sicherheitslücke" mit den Postings auch durch? Seit wann vertuscht man eine Schwachstelle, wenn dies in den Dokumentationen ... ja sogar in öffentlich einsehbaren Patentbeschreibungen nachlesen kann?

... the very same cache poisoning problem we abuse in our attack against SMM has been identified a few years ago by Intel employees, who even decided to describe it in at least two different patent applications ...

Zum Vergrößern anklicken....

Die beiden Sicherheitsteams beschreiben ihren Angriff und sind von Intel bestätigt worden, dass bei einigen Chipsatz-Prozessor-Kombinationen das funktionieren könnte. Deswegen hatte Intel ja auch schon einige Workaraonds zur Verfügung gestellt und angeblich soll der Angriff bei neueren Chipsätzen nicht mehr möglich sein.

Vergleicht man das mit dem TLB-Bug bei AMD, dann herrschte bei Intel eine höhere Transparenz gegenüber Entwicklern.

Darüber hinaus hatte AMD Schwierigkeiten den TLB-Bug genauer zu lokalisieren - Einige enge Barcelona-Systempartner (ich vermute da Sun und Cray) stellten offenbar "irgendwelche Fehler fest ... die AMD aber erst gar nicht sicher eingrenzen konnte.

Ein unbekannter Fehler ist daher als schwerwiegend einzustufen, als ein Fehler, der sehr präzise nachzustellen ist. Das ist wie mit Gefahrenschild "Achtung Gefahr" , die "nur warnen" (-> sehr gefährlich), gegenüber Gefahrenschildern mit konkreten Gefahren wie "Steinschlag", "Steilufer".

Die Gefahr bleibt aber und ist als schwerwiegend einzustufen, weil viele Intel-Computer auf der 35`-Chipsatzgeneration laufen. Immerhin ist der Angriffs-Weg eindeutig, was Gegenmassnahmen leichter macht, als unbekannte Bugs, die Fehler provozieren.

MFG Bobo(2009)

mußte grad lachen, die signatur des netten herren moderators, der den threat bei hardwareluxx geschlossen hat, da er ja soo langweilig ist. *g*

"Intel Core i7-920 @ 3990MHz (24/7 @ 3,7GHz 1,2V)"

na, auf intel läßt man dann eben nix kommen *gg*

Das klingt ja schon doll wie Bobo das ganze wieder zu Gunsten Intel relativiert. Allerdings ist ihm in der Argumentation scheinbar entgangen, dass AMD sehr schnell mit einem Fix reagiert hatte, Intel aber jahrelange gar nichts in Richtung Problem/Gefahr Lösung unternahm.

Was ist gefährlicher?

Sehr witzig in dem Zusammenhang von Threat statt Thread zu schreiben

So wie ich das verstehe, kann man Admin-Rechte erlangen, wenn bestimmter Code (oder Daten) geladen wird.

Diese Sache mit Administratorrechten ist eigentlich nur reine Formalie, ich weiß gar nicht warum hier darauf so herumgeritten wird. Der Code muss mit Administratorrechten ausgeführt werden, da sonst die Register nicht geöffnet werden können. Allerdings ist dies auch nichts besonderes, fast alle Schädlinge benötigen Administratorrechte um ihre Schadroutine zu aktivieren. Unter Windows XP ist dies auch kein Hindernis, denn dort hat jeder bei der Installation angelegte User volle Adminrechte.

Bobo hat es doch gut erklärt, es wird nichts vertuscht aber auch nicht beschönigt.

The G schrieb:

"Einsatzmöglichkeiten"

Zum Vergrößern anklicken....

die wohl interessantes Einsatzmöglichkeit ist es Schadecode von einem Gastsystem aus auf dem Hostsystem auszuführen. Dafür reicht normalerweise keine Adminstratorrechte auf dem Gastsystem. DAS ist wirklich Kritisch, zumal der Schadcode Platformunabhängig ist. Windows VM-Ware image schädigt deinen Linux-Host-Server. Für viele Webseiten-SharedMaschine-Hoster ist allein die Möglichkeit eine Katastrophe.