Software::Security
Sicherheitslücke mit Hyperthreading
In einem Vortrag am Freitag, den 13., auf der BSD Canada (BSDCan)-Konferenz hat Colin Percival eine Sicherheitslücke in Prozessoren aufgedeckt, die Hyperthreading mit gemeinsamem Cache verwenden.
Diese Kombination kommt in Intels Pentium 4-Prozessoren zur Anwendung, die Hyperthreading-fähig sind. Ob AMD-Prozessoren oder PowerPCs betroffen sind, ist noch nicht bekannt.
Unter dem Titel »Hyper-Threading Considered Harmful« hat der nach eigenen Angaben momentan arbeitslose Sicherheitsexperte ein zwölfseitiges Papier Cache Missing for Fun and Profit vorgestellt, das die Vorlage für seinen auf der BSDCan gehaltenen Vortrag ist. Darin beschreibt er, wie man auf einem Hyperthreading-Prozessor zumindest theoretisch geheime Schlüssel ausspähen und knacken kann. Der Trick funktioniert nur bei Hyperthreading und nur, wenn ein gemeinsamer L1-Cache vorhanden ist. Denn es wird ein Thread benötigt, der parallel zu einem anderen Thread, der kryptografische Operationen ausführt, auf demselben Prozessor läuft und Cache-Zugriffszeiten mißt. Ohne Hyperthreading wären solche Messungen nicht durchführbar.
Das Papier beschreibt, wie beispielsweise eine Verschlüsselungsoperation mit OpenSSL sich auf das Cache-Timing auswirkt. Das Grundprinzip besteht in der Ausnutzung der Tatsache, daß das Lesen von Daten, die bereits im Cache liegen, sehr schnell ist, das Lesen von Daten, die erst nachgeladen werden müssen, dagegen meßbar langsamer vonstatten geht. Ein parallel ausgeführter Prozess, der bestimmte Stellen aus dem Cache liest, kann aus der Zeit, die dies benötigt, Rückschlüsse ziehen, ob bestimmte Bits im geheimen Schlüssel 0 oder 1 sind. Es ist möglich, von den 512 Bits über 300 in Erfahrung zu bringen, was genügt, um die Zahl in kurzer Zeit zu faktorisieren. Ob dies von einem Programm im realen Betrieb tatsächlich ausgenutzt werden könnte, sei dahingestellt.
Selbstverständlich kann ein Thread nicht direkt die Cache-Zeilen lesen, die dem anderen Thread gehören. Dies wäre eine zu offensichtliche Sicherheitslücke. Dennoch läßt sich der gemeinsame Cache zusätzlich zu obigem Problem auch noch als versteckter Kommunikationskanal zwischen zwei Prozessoren nutzen. Dazu müssen zwei Prozesse allerdings kooperieren. Durch geeignetes Lesen und ggf. Schreiben von Speicherseiten und Messen der Zugriffszeiten können zwei Threads bis zu 400 kbit/s über den L1-Cache übertragen. Bei Ausnutzung des langsameren L2-Caches sollen es immer noch bis zu 100 kbit/s sein. Zwei Prozesse könnten dies nutzen, um unentdeckt miteinander zu kommunizieren.
Abhilfe für das Problem ist sowohl in der Hardware als auch im Betriebssystem oder in den Applikationen möglich. Eine Behebung in den Applikationen ist aber, zumindest kurzfristig, kaum denkbar und ließe das Risiko von Sicherheitslücken bestehen. Da auch die existierende Hardware nicht geändert werden kann, sind die Betriebssystemanbieter gefragt, Lösungen zu implementieren, beispielsweise im Scheduler. Colin Percival hat in den letzten Monaten viele Anbieter bereits kontaktiert. Nur wenige haben bisher aber reagiert. OpenBSD empfiehlt, Hyperthreading abzuschalten, da es momentan vom Kernel ohnehin nicht unterstützt wird. FreeBSD empfiehlt das Ändern der Kernel-Konfiguration. Auf Prozessoren mit Dual-Core, die nun allmählich auf den Markt kommen, scheint jedoch ein Abschalten des Hyperthreading sinnvoller. NetBSD plant, eine Sicherheitsmeldung herauszugeben. Red Hat hat einen Fehlerbericht angelegt, in dem darauf verwiesen wird, daß das Problem nur unter sehr speziellen Umständen auftreten kann und daß OpenSSL an einer Lösung des Problems arbeitet, die dann wahrscheinlich in Red Hat integriert wird. Da andere Pakete wie beispielsweise GNU TLS ebenfalls betroffen sein könnten, untersucht Red Hat auch diese.
