Hyper-Threading sebezhetőség - az összes operációs rendszer érintett

Bug

Colin Percival FreeBSD fejlesztő és security team tag súlyos, helyileg kihasználható sebezhetőséget talált az Intel jelenlegi Hyper-Threading implementációjában.``A Hyper-Threading, ahogy jelenleg implementálva van az Intel Pentium Extreme Edition, Pentium 4, Mobile Pentium 4 és Xeon processzorokban, súlyos hibában szenved.''

A hiba kihasználásának következtében helyi információ szivárgás léphet fel. Például a rosszindulatú, privilégium nélküli, helyi felhasználó számára lehetővé válik, hogy ellopja a gépen levő RSA privát kulcsokat. A szakember a többfelhasználós rendszereket üzemeltető adminisztrátoroknak azt ajánlja, hogy azonnal tiltsák le a Hyper-Threading-et!

A sebezhetőségről - ahogy korábban ígérte - ma beszélt a fejlesztő a BSDCan 2005 rendezvényen. A későbbiekben Colin azt ígérte, hogy kiad egy részletes leírást a támadás kihasználhatóságának részleteiről. A hiba minden olyan operációs rendszert érint, ahol a Hyper-Threading be van kapcsolva. Bővebb infók itt várhatók... A KernelTrap cikke itt.

( kohinoor | 2005. 05. 13., p – 08:12 )

Remelem, vissza tudom cserelni az Intel P4 640-esemet egy bugfixedre :-)

( trey | 2005. 05. 13., p – 08:23 )

``Disclosure timeline

Late October, 2004: Initial discovery.

December 2004: Proof-of-concept exploit written and tested.

December 31, 2004: FreeBSD Security Officer Team notified of upcoming security issue.

February 2005: First draft of paper completed.

February 27, 2005 - March 18, 2005: Other security teams contacted.

May 13, 2005 @ 00:00 UTC: Official public disclosure that a security flaw exists in Hyper-Threading.

May 13, 2005 @ 15:00 UTC: Full details to be released. ''

Erdekes, hogy vendort nem ertesitette. Vajon miert? Lehetoseg lett volna a hibat javitani minel elobb. Kicsit ez nekem onzesre vall...

( Chain-Q v | 2005. 05. 13., p – 09:34 )

Hat ez csodalatos. Intel rulez. Es tessekmondani, fognak majd processzort is gyartani egyszer, vagy csak ilyen annak latszo micsodakat?

( gipszjakab | 2005. 05. 13., p – 10:44 )

Haat azert a kerneltrap megnezhetne idonkent, hogy ki mit kommentel a cikkhez...

Ez most vicc, vagy komoly? (marmint a hozzaszolas a kerneltrap-en) mert viccnek eleg sz@r.

( PaXTeam | 2005. 05. 13., p – 11:16 )

na latom, megint tobb a spekulacio mint a tenyleges info :-). szoval:

1. Colin ertesitette az Intel-t akik vegul egy ido utan bedobtak a torolkozot es azt mondtak, hogy

2. ok ezt a hibat bizony nem tudjak kijavitani (marmint gondolom ugy ertettek, hogy nem eri meg nekik), tehat nem lesz uj proci.

3. ego trip: hat igen, van egy ilyen szaga, de tekintve, hogy milyen fiatal es munkakereses elott all, talan megbocsathato, legalabb nem tartotta meg maganak.

( trey | 2005. 05. 13., p – 16:21 )

Ahogy nezem nagyobb a fustje, mint a langja. Az egyik biztonsagi oldal a kovetkezoket adta ra:

FrSIRT Advisory : FrSIRT/ADV-2005-0540

CVE Reference : CAN-2005-0109

Rated as : Low Risk

Remotely Exploitable : No

Locally Exploitable : Yes

Release Date : 2005-05-13

Amekkora volt a titkolozas elotte, azt hittem valami egetrengeto bejelentes lesz.

Az se biztos, hogy a sarki-sec advistoryjának kell hinni... ;P

Egyébként ez nyilván a téves besorolásnak köszönhető, sokan úgy gondolják, hogy az info leak bugok nem veszélyesek...

Halvar Flake once said, "No good hacker just looks for one bug." An information leak can make even a difficult bug possible. Even PaX (the advanced kernel-based memory protection patch) is easily defeated with a good enough information leak.

Feltettem a kerdest az LKML-en (mivel en nem tudom megitelni mennyire komoly). Itt vannak a valaszok:

http://marc.theaimsgroup.com/?t=111596371300004&r=1&w=2

Azt irjak, hogy valos a problema de nehezen kihasznalhato.

``In-the-wild exploitation is difficult, though; your timing gets screwed up if you get scheduled away from your victim, and you don't even know, because you can't tell where you were scheduled, so on any reasonably busy multiuser system it's not

clear that the attack is practical.''

De ezt ugye te is látod, hogy kamu?! (ha jól értelmezem a smiley-t...)

Csak kompatibilitási célzattal van beállítva a cpuid bitje, mert az SSE3-ban van két utasítás, ami HT specifikus és az AMD-nek az SSE3 supporthoz HT supportot is kell hazudnia.

Ez kb olyan, mint amikor régebben az AMD processzorokban megjelent még az SSE1 támogatás és a programok nem a cpuid bitek, hanem a vendor string alapján döntötték el, hogy van-e SSE, ezért nem használták ki.

Az egyik munkam most egy Samsung ARM9 procis Win CE-t futtato eszkozhoz kapcsolodik. Mivel a fejlesztokornyezet SAJNOS embedded VC++, ezert egy egyszer javitason ittfelejtett IBM 300GL-t uzemeltem be a celra. Integralt AGP-s S3 Trio, 433-as Cerka, 160MB RAM, egyeb nyalanksagok... Kepzelhetitek, mennyire le vagyok nyugozve tole... ;) Foleg hogy ittvan pl. a PowerMac Linuxszal [bigworm.homelinux.net], meg az Amigak [scenergy.dfmk.hu], meg par mas gep, es akkor ezt a mocsok talicskat kell tologatni fel-ala...

Ja, egyebkent ezt a hozzaszolast az A2000 [amiga.resource.cx]-mrol irtam. Copyright Commodore 1988. Motorola Inside. Nnna, ezek ernek valamit! :)