Intels HyperThreading immanent unsicher auf Mehrbenutzermaschinen?

Wie auf Slashdot gepostet wurde, stellt Intels "virtuelles SMP", genannt HyperThreading, in seiner derzeitigen Implementation ein "grobes Sicherheitsloch" dar. Auf Mehrbenutzermaschinen soll es dadurch zB moeglich sein, als unprivilegierter User A vertrauliche Daten eines anderen Users B auszulesen. Der Entdecker des Bugs in der pseudo-multiprocessoring-Technologie hat angekuendigt, den genauen Modus Operandi zur erfolgreichen Attacke gemeinsam mit Schadensbegrenzungsvorschlaegen auf der BSDCon 2005 in Kanada zu demonstrieren.

Im Moment kann die Datensicherheit auf Systemen mit aktiviertem Hyperthreading nur durch Abschaltung des Features - und damit teilweise betraechtlichem Performanceverlust in parallelisierbaren Berechnungen - im BIOS des Motherboards gewaehrleistet werden.

mach braucht nicht jeden crap glauben der auf /. gepostet wird.

Zitat

# Where do you work?

I'm unemployed. For the past three months, I've spent almost all of my time working on this security flaw -- investigating how serious it was, contacting all of the affected vendors, explaining how this should be fixed, et cetera. I simply haven't had time to go out and get a job -- and I decided that making sure that this issue was properly reported and fixed was far more important than earning some money.
# I think it's really great that you spent three months doing unpaid work to improve the security of other peoples' computers. What can I do to thank you for your efforts?

Money is always good. In all seriousness, there is a considerable amount of security-related work which I'd like to spend time doing, but if I can't get any money I'm going to have to get a Real Job instead. If you think you or your company could offer me some funding to allow me to continue my work, please let me know.

quelle: hp vom typen der ders entdeckt haben willt.

da er bis jetzt keine details genannt hat ist es höchstunwahrscheinlich daß es auch nur irgendeinen nenneswerten einfluß haben wird. höchstwahrscheinlich sind es eher bugs in schedulern oder dergleichen. das feature "SMT aka HT" ansich ist definitv unproblematisch.

sieht für mich aber mehr nach nem hardwarebug aus
die softwerker sollten intel einfach ne böse mail schreiben und sich nicht weiter drum kümmern.
'95 is ja auch keiner auf die idee gekommen den pentium divisionsfehler in der endanwendung zu korrigiern

mein tip is mal das intel ne neue version vom microcode rausgibt und alle die sich von dem bug betroffen fühln n neues bios flashen müssen.

soweit ich das verstehe funkt das so:

man flusht die cach line für die adresse A (für den anderen thread), aber nicht für B. dann kann man darüber theoretisch sagen welche adressen der andere thread verwendet hatindem man schaut wie viele schleifeniterationen man ausführen kann. wenn jetzt der andere thread A verwendet will kommt es zur einer stall-situation und der andere thread kann mehr cpu cycles verwenden.


kann man das gleiche sogar mit einem UP system machen mit interrupts und/oder task switches die das per mitstoppen von ausführungszyklen machen die auf die cache lines vom anderen thread machen.

theoretisch hast du gleiche möglichkeit bei einem smp system, nur is es nicht so leicht die daten ranzukommen.


@gue: true! nichts neues dahinter eigentlich. vor allem braucht man für brute-force knacken von ~200 bits auf heutiger technik mehr jahre als es atome im universum gibt.

oder der attacker efindet einen algorithmus der in polynomieller zeit primfaktoren von beliebig zahlen in der größenordnung von 10^60 - 10^70 ausspucken kann. der attacker der dieses problem löst hat wohl für den rest seines lebens ausgesorgt und kann dann mit mehreren fields medallien in der gegend spatzieren gehen

Zitat von madp

Soweit ich das Verstanden habe gehts aber nicht um reines brute-force Knacken.

Die "310 von 512" Bits von denen im Paper die Rede ist beziehen sich nicht direkt auf den Private Key (der ja bei OpenSSL eh grösser ist, 1024 bits oder?).

hm, das ist anscheinend richtig. wobei ich eher glaube daß >4096 bits durchaus kein problem für die neueren kryptographiesysteme darstellen und afaik wird den usern auch empholen die längeren/längstmöglichen keys zu verwenden.

Zitat von madp

Die 310/512 Bits bezieht sich auf die beiden Faktoren in N = p * q

die fundamentale (vereinfachte) RSA verschlüsselungsgleichung ist doch:
C = (T^E) MOD PQ

PQ wobei P und Q > 1024 bit bei RSA sind (default = 2048bit?)
E < PQ und E mit (P-1)(Q-1) prim.

und entschlüsseln mit

T = (C^D) MOD PQ

PQ wie gehabt
D = (X(P-1)(Q-1) + 1)/E (muß in N liegen)

wenn man nur PQ & E hat, kann man weder P noch Q jemals herausfinden!
(weil PQ so groß ist)

und so wie ich es verstanden habe hat er einen kleinen teil von PQ und den rest müßte man brute-forcen.

aber kein gewähr drauf

sysmatrix: mein fachgebiet is nicht mal ansatzweise kryptographie oder die dazugehörige mathematik, aber:

wenn ich von einer primzahl, von der ich ungefähr die anzahl der stelln kenn, jetzt auch einen block der enthaltenen stellen weis sollte man doch anhand von dem die möglichen zahln filtern können. so häufig sind primzahln in der größenordnung ja auch wieder nicht. klar, ich brauch ne große datenbank dafür. und ich würd mal sagen wenn man die anzahl der kandidaten auf hausnummer ne einstellige mio-zahl einschränken kann is das sogut wie geknackt.

--------------------edit--------------------
mal ne ganz andere sache
unter win (und warscheinlich auch anderen systemem) werden die rechte über security-tokens gehandhabt.
das is ja n datensatz der sich nciht ändert solang der task läuft. und wenn man nen server hernimmt der 24/7 läuft hat ein virus auch genug zeit um sich die daten schön langsam zusammenzuklauben.
und wenn man mal ne kopie von nem root-level-token hat sollt man damit doch schon gehörig scheiße baun können, oder lieg ich da falsch?