Dunkle Wolken ziehen am Horizont auf, zumindest wenn man einer Vorankündigung zur Verantstaltung "Hack in the Box" vom 27. bis 30. Oktboer glauben darf. Dort will nämlich der, nicht unbekannte, russische Hacker Kris Kaspersky (nein, er hat nichts mit dem AV-Hersteller zu tun) einen Weg zeigen um Intel-CPUs, genauer gesagt aktuelle Core2Duos zu hacken.
Nein, das war jetzt kein Schreibfehler, er will nicht das Betriebssystem oder eine darauf laufende Anwendung hacken, sondern die CPU direkt.
Um ein bißchen auszuholen: Es gab in letzter Zeit viel Rummel um den TLB-Bug bei AMDs Phenom-Prozessoren, einem Bug in der Chip-Hardware, welcher für einen Fehler bei Berechnungen in ganz bestimmten Konstellationen sorgt. Ältere Forenteilnehmer erinnern sich vielleicht auch nocht an den legändären FDIV-Bug des Pentium I, der damals für Intel nicht nur peinlich, sondenr auch teuer wurde.
Nun ist es aber nicht so, dass diese Bugs in Hardware die Ausnahme wären, sondern eigentlich sind sie eher die Regel und jeder Chip dürfte einige davon mit sich herum tragen. Intel ist nun so nett die erkannten Bugs in ihren Chips für Entwickler zu veröffentlichen, damit diese darauf vorbereitet sind und die Probleme umschiffen zu können. Diese Veröffentlichungen werden als Specification Updates bzw Errata bezeichnet und ein aktueller C2D kann z.B. auf eine Liste von (afair) 186 dieser Bugs verweisen, ein aktueller Itanium (ein Server-Chip von Intel mit IA64-Archtiektur) gar auf 230.
Genau hier will Kaspersky ansetzen, denn seiner Ankündigung nach lassen sich einige dieser Bugs ausnutzen, um eine CPU mittels bestimmter Befehlssequenzen zu manipulieren, und zwar unabhängig von verwendeten Betriebssystem und eingespielten Patches, dies klingt auch erst einmal verständlich wenn man bedenkt, dass die Vorgehensweise darin besteht der CPU bestimmten Maschinencode unter zu jubeln. Nun ist es aber so, dass sich moderne Rechner nicht einfach so Maschinencode unterjubeln lassen, der Angreifer wäre wohl (Achtung, hier beginne ich mit Hypothesen) darauf angewiesen, diese Befehlssequenzen "vor Ort" zu erzeugen und da er in der Regel auf der Maschine keinen Compiler zur Verfügung hat, bzw ein Compiler solchen Code ohnehin nicht erzeugen würde und selbst wenn, er nicht plattformunabhängig wäre, muss der Weg anderweitig funktionieren.
Da Kaspersky einen Verweis auf Java machte ist wohl davon auszugehen, dass er für seine Demonstration wohl den JAVA-Just-in-time Compiler missbrauchen wird, denn dieser ist plattformunabhängig, breit verfügbar und es ist leicht vorher auszuarbeiten, was man ihm füttern muss um bestimmte Befehlssequenzen zu erzeugen.
Interessant dürfte das Ganze allein schon werden, weil Kaspersky angekündigt hat nicht nur eine Demonstration abzuliefern, sondern in gleichem Zuge auch lauffähigen Exploitcode veröffentlichen will. Eine ziemlich gewagte Ankündigung um sie nicht zumindest ernster zu nehmen.
Nochmal zurück zu den CPU-Bugs. Mancher wird sich jetzt fragen wie es sein kann, dass defekte Hardware massenhaft verkauft wird, vor allem wenn bekannt ist dass diese defekt ist und warum sein Rechner dann nicht ständig abstürzt.
Zum einen sind Chips (nicht nur CPUs, sondern Chips allgemein) heute so komplex, dass sich Fehler wohl nie werden vermeiden lassen, zum anderen gibt es durchaus Wege auch eine defekte CPU zu zuverlässiger Arbeit zu bewegen. Vielleicht hat der ein oder andere bei einem etwaigen BIOS-Update seines Mainboards schon einmal etwas von einem Microcode-Update gelesen. Microcodes sind eine Art "Mini-Software", welche ins ROM des Rechners geladen werden und die Ansteuerung der CPU in bestimmten Grenzen verändern können (etwas laienhaft ausgedrückt). Es werden somit also defekte Funktionen "umschifft", zu Fehlern führende Code-Sequenzen umgestellt oder schlicht fehlerhafte Einheiten still gelegt und / oder deren Funktionalität mittels anderer Befehlssequenzen ersetzt. Allerdings sind Microcodes nur bei der x86-Architektur vorhanden (afaik).
Weiterhin können diese Probleme auch auf Betriebssystemseite umschifft werden, denn auch z.B. Windows kann softwareseitig Microcode-Updates laden (update.sys) und bestimmte Funktionen ändern, oder auch der Linux-Kernel wurde und wird gegen solche Hardware-Bugs gepatcht. Falls es jemand mitbekommen hat, so gab es einen Kernel-Patch gegen den TLB-Bug des Phenom, welcher dann dummerweise für bis zu 10% Performanceverlust sorgen konnte.
Falls jetzt jemand mit AMD-CPU sich ins Fäustchen lachen sollte: Die Wahl des Intel C2D dürfte rein aufgrund Publicity-Wirksamkeit und Verbreitung der betroffenen CPUs bei lohnenden Zielen gefallen sein. Es hätte wohl ebensogut AMD, Sun oder einen beliebigen anderen Hersteller treffen können und sollte es wirklich dazu führen, dass Ende Oktober lauffähiger Exploitcode präsentiert wird, so dürfte es nicht lange dauern bis ähnliches auch für AMD-Prozessoren auftauchen wird.
Letztendlich besteht aber immer noch die Möglichkeit, dass Kaspersky hier nur mächtig dick aufgetragen hat und sich alles relativiert oder als Marketing-Gag herausstellt. Allerdings ist er nicht der erste, der auf die Möglichkeit der Ausnutzung von Hardwarefehlern oder Designfehlern in Hardware hinweist (sieheSide-Channel-Attack), so haben sich auch die BSD-Entwickler schon zu bösen Worten bezüglich der Sicherheit von Intel-CPUs hinreissen lassen (Shared Caches).
Hack in the Box, Ankündigung Kris Kaspersky
Viren, Spyware, Datenschutz 11.213 Themen, 94.186 Beiträge
Es gab in der Vergangenheit schon öfters Code, der Hardware angegriffen hat, z.B. ein Virus, der die Festplatten-Elektronik so umprogrammiert hat, dass diese beim nächsten einschalten die Schreib/Leseköpfe mit Vollgas ans Gehäuse haben laufen lassen, was natürlich ihr Ende bedeutete.
Hast Du dafür eine Quelle? Sowas dürfte rein mechanisch gar nicht möglich sein.
Hast Du dafür eine Quelle? Sowas dürfte rein mechanisch gar nicht möglich sein.