Vihar a teáscsészében? A Pentium gépek sebezhetőek a cybertámadások által

Intel

A múlt héten a CanSecWest/core06 biztonsággal foglalkozó konferencián azzal a felfedezéssel álltak elő biztonsági szakemberek, hogy rosszindulatúan ki lehet használni azt a mechanizmust, amelyet a Pentium kategóriájú processzorok használnak saját maguk és az alaplapjuk védelmére. Az ilyen processzorok, ha azt észlelik hogy túlhevültek, vagy egyéb olyan helyzet állhat elő, amely az alaplap károsodásához vezethet, egy védelmi folyamatot indítanak el.

E folyamat közben a számítógép megszakítások ideiglenesen leállításra kerülnek és aktuális állapotuk eltárolásra kerül. Loïc Duflot, a francia kormány Secretary General for National Defense IT laborjának szakértője szerint ebben az eljárásban olyan hiba van, amelyet rosszindulatú támadó kihasználva adminisztrátori jogokat szerezhet az adott számítógépen.

A hiba minden olyan számítógépet érinthet, amelyben x86 architektúrát használtak fel, beleértve az amerikai kormányzat és ipar több millió számítógépét. - mondta Dragos Ruiu a konferencia szervezője.

A cikk itt.

A bejelentés hatására internet-szerte viták kezdődtek a hiba komolyságáról. A többségi vélemény az, hogy az a számítógép, amelyhez fizikailag hozzá lehet férni, az nem biztonságos, tehát a felfedezés semmi újdonsággal sem szolgál.

( Joco8192 v | 2006. 04. 12., sze – 11:19 )

Ha távolról nem root jogon adsz a procinak olyan feladatot amivel turterheled és olyan adat láncot olvastatsz végtelen ciklusban vele ami admin joggal lépteti ki akkor csak admin jogu kilépés esetén fogg a végtelen ciklus megszakadni. Lehet egy ideig görcsöl a gép de utána adminjoggal jön rendbe. No para AMD a Király:)

Apropó az FSN Gép az opteronos procival mikor kezd dolgozni ?

Amennyiben különbözik, az kizárja, hogy ami az egyiken működik, az a másikon is? Sehol nem írták, hogy XY gyártó processzora, hanem azt, hogy x86 processzor.

"This entire exploit is based on documented x86 functions."

Nekem ebből a kevés infóból nem látszik, hogy csak XY gyártó processzoráról lenne szó.

"security issues related to Pentium SMM"

Ha ezt vesszük alapul, akkor elképzelhető, hogy az Intel processszorokra szűkíthető a kör, de ezt sehol nem láttam leírva. Kevés az infó (és ami van az is ellentmondásos, és zavaros) ahhoz, hogy konkrétan ki lehessen jelenteni, hogy wtf. Jó lenne látni a prezentációt magát.

Ja és azt is jó volna tudni konkrétan, hogy ennek milyen biztonsági kockázata van, de attól félek, hogy ez ismét olyan "nagy felfedezés", mint a Colin Percival féle HT sebezhetőség.

--
trey @ gépház

A Pentium az Intel regisztrált védjegye ha jól tudom.
Ha Pentiumot emlegetnek valahol, az kifejezetten az Intel procikról kell(ene), hogy szóljon.
Egyébként meg... a leírt hiba(?) leginkább a mikrokód hibája ha jól látom. Nehezen tudom elképzelni, hogy a 486-osok után következő proci generációban az AMD-nél megjelentek volna az Intel fejlesztései, így kicsi az esélye, hogy ilyen téren megegyezzenek.
Rosszul gondolom?
Az utolsó AMD procim még 486-os volt, azóta kizárólag Intelt használok, AMD-ről még a híreket se nagyon szoktam elolvasni.
---------------------------------------------------
Fel! Támadunk!

Egyszer már leírtam a véleményemet. A rendelkezésre álló adatok alapján _én_ nem tudom megállapítani egyértelműen. Ha te meg tudod, akkor nyilván jobban értesz hozzá mint én. Gondolom te birtokában vagy azoknak az infóknak, ami alapján ki mered jelenteni, hogy ez a "hiba" vagy nevezzük bárminek, csak az Intel processzorokat érinti.

Én azért szeretném látni az eredeti prezentációt is. Pusztán csak érdeklődés szinten.

--
trey @ gépház

Te írtad:

"Jah, még szerecse, hogy az AMD processzorok "nem" x86 processzorok :-))"

Én csak erre reagáltam. De amint látom, mások is megerősítették, hogy az AMD gyakorlatilag egy x86 emulátort működtet a processzoraiban.

---------------------------------------------------
Fel! Támadunk!

bar ide irok, nem csak neked szol, hanem a tobbi erdeklodonek is, mert eleg sok a zavar, ahogy elnezem.

eloszor is, ugy altalaban erdemes elolvasni az eredeti cansecwest prezentaciokat, az SMM cucc meg itt van.

ez az egesz SMM dolog olyan 1990 korul indult, amikor az Intel kihozta a laptopokba szant 386SL procikat. es ha mar laptop, akkor legyen egy kis power mgmt is. lett is, meghozza egy uj proci megszakitas bevezetesevel (SMI = System Mgmt Interrupt), amit csak hw tud generalni, es a procit egy uj uzemmodba kenyszeritve (SMM = System Mgmt Mode) hajtatja vegre a specialis SMI kezelo kodot. a hw konkret esetben a proci korul levo chipsetet jelenti (north bridge es south bridge, reszletek az Intel chipset doksikban), ami manapsag eleg valtozatos esemenyeket kepes egy SMI-vel "honoralni" (pl. i/o egy adott portra, memoria hozzaferes egy adott fizikai cim tartomanyra, IRQ aktivitas, stb).

az SMI kezelo normalis esetben a BIOS-ban van, ezt a bootolas soran a BIOS bemasolja egy erre a celra elkulonitett fizikai memoria tartomanyba (ami amugy csak SMM-ben "lathato" a proci szamara). mivel az SMI barmilyen kodot kepes megszakitani (akar egy eppen futo NMI kezelot is!), ezert az SMI kezelonek nagyon ovatosnak kell lennie, cserebe viszont totalis kontrollja van a proci ill. az egesz chipset felett.

csak erdekessegkeppen, amikor a proci meghiv egy normalis megszakitaskezelot, akkor ugye lementi a megszakitott kod allapotanak egy reszet a veremre (programszamlalo, veremmutato, stb) mielott vegrehajtana a kezelot. SMI eseten az a helyzet, hogy ez a lementett allapot sokkal nagyobb, olyan belso regisztereket is tartalmaz, amikhez normalisan a programozo hozza sem fer (akinek mond vmit: segment descriptor shadow regiszterek). minderre azert van szukseg, mert az SMI kezelonek vissza kell tudnia allitani a teljes megszakitott proci allapotot fuggetlenul a megszakitott OS-tol.

az SMM/SMI biztonsagi vonatkozasa az, hogy ha vki kepes SMM-ben kodot vegrehajtani, akkor "barmit" megtehet, pl. az adott demonstracioban modosithatja a securelevel-t. ami gyakorlativa teszi a problemat az az, hogy bizonyos korulmenyek kozott akar normal user modu kod is kepes ugy felprogramozni a hw-t, hogy az SMI-t generaljon es vegrehajtsa a tamado kodjat (megjegyzem, hogy az adott tamadas eleg proof of concept jellegu, van benne par feltetelezes, amit egy megbizhato exploitnal nem lehetne).

amugy az SMM-t masra is fel lehet hasznalni, pl. tuti jo (OS-fuggetlen) debuggert lehetne irni benne (egy ilyenbe kezdtem bele 98-ban, aztan elfogyott a lendulet), vagy szolgalhatna TCB-kent (Trusted Computing Base, az Intel mar alkotott is vmit, PaX-ban tervbe van veve, hosszu tavon ;), lehet hw emulaciora felhasznalni (az USB billentyuzetekhez legacy tamogatast ado BIOS-ok pl. ezt teszik), vagy akar lehet egy teljes OS-t is futtatni a hatterben.

vegul mas gyartokrol: amennyire emlekszem, AMD K5-tol kezdve ott is van SMM/SMI tamogatas (es a hozza valo chipsetekben is persze), Cyrixnal meg az M1-tol.

a reszletekert olvasd el a prezentaciot es az Intel chipset doksikat ;-).

roviden arrol van szo, hogy az SMM-hez kapcsolodo chipset funkciokat normal PCI buszos tranzakciokkal lehet elerni. ez elso korben i386-ra epulo rendszereken port i/o-t jelent (in/out asm utasitasok a 0xcf8/0xcfc portokra). a north bridge tobbek kozott tud olyat, hogy egy bizonyos fizikai cimtartomanyt (alapertelmezesben 0xa0000-0xbffff, regi VGA memoria tartomany, de at lehet programozni mashova) "eldugjon" ill. lathatova tegyen a proci szamara. vagyis a programozastol fuggoen ha a proci megprobalja elerni ezt a memoriatartomanyt, akkor a north bridge a memoriahozzaferes tranzakciot vagy atiranyitja a fizikai RAM-ba (ez tortenik, amikor a proci SMM modban van ill. amikor a BIOS felprogramozza az SMI kezelot), vagy tovabbadja a PCI busznak (ahol jo esellyel egy videokartya fog ra reagalni).

tehat a BIOS altal "telepitett" SMI kezelo atirasahoz nincs tobbre szukseg, mint felprogramozni a north bridge-t, hogy tegye lathatova ezt a RAM teruletet, bemasolni a sajat kododat, aztan ujra elrejteni ezt a teruletet. az SMI generalast hasonlo modon chipset programozassal lehet megoldani (south bridge-t ez esetben) ill. SMP rendszereken lehet olyan IPI-t (Inter-Processor Interrupt) is kuldeni, ami SMI-t okoz. hozzatennem, hogy legalabb az Intel chipseteknel lehetoseg van az SMM terulet lezarasara, vagyis egy bit beallitasaval az SMM memoriaterulethez tobbe nem lehet hozzaferni SMM-en kivul (es persze ezt a bitet sem lehet atirni, csak egy teljes reset torli ki).

ha mar chipset programozasrol van szo, kecsa kerdezte, hogy ezt egy user processz mennyire teheti meg. a valasz az, hogy OS-tol fugg, hogy a ring-0-ban futo kernel hogyan teszi lehetove ring-3-ban futo kodnak, hogy vagy direkt port i/o-t hasznaljon vagy vmi kozvetett kernel szolgaltatast nyujtson ra. unix/linux rendszereken erre vannak az iopl/ioperm rendszerhivasok, amit csak root tud hasznalni (pont azert, mert port i/o-val sok mas mindent is lehet csinalni). tehat ez az egesz arrol szol, hogy hogyan lehet egy korlatozott root kornyezetbol kitorni (BSD securelevel, vagy grsec/selinux/stb). a magam reszerol meg annyit, hogy kb 3 evvel ezelott mar felvetettem spendernek a problemat, ill. hogy hogyan lehetne megoldani, de sajna a dolog nem egyszeru (ACL rendszert meg kene tanitani port i/o kovetesere), ugyhogy a dolog annyiban maradt akkor (meg mondjuk ha mar a kernel onvedelmerol van szo, akkor nem ez a legegetobb problema).

( trey | 2006. 04. 12., sze – 12:49 )

Részletek:

"cansecwest/core06: "security issues related to Pentium SMM"

Loic Duflot
Title: Security Issues Related to Pentium System Mgmt Mode

It is day 2 at Cansecwest and this talk wins for ‘so frightening that you want to hide under your desk in the fetal position’.

I’ll go through the high level technical and then end with pointing out a principal that is one of those universal truths I carry around with me everywhere.

This entire exploit is based on documented x86 functions.

Your CPU runs in a few modes, one of those modes is known as Protected mode, other known as System Mgmt Mode. When your OS is running, your in Protected mode and this is how much of the security is performed and you’ll hear of ring0 and ring3. Just know that your in-world universe is in protected mode.

System Management Mode (SMM) is used so that when there is something external to your OS world like say a thermal condition that needs to communicate some message, the CPU saves all its protected mode state out, does all this SMM stuff and then return to its regular scheduled program in protected mode.

There are details that evolve registry addresses and very low level operations but for the most part, a system in a very secure state can be circumvented via this SMM facility. I’m talking free access to all memory and IO.

The song goes a little like this:
Enable SMI
Open SMRAM space
Replace default SMI Handler by custom one (do your duty)
Close SMRAM space
Trigger SMI
Gain access to restricted operations.

In the wider picture: works on most systems. Turns out that Linux and the *BSD’s will fall victim to this attack strategy, however, Windows XP is not known to be exploitable because of a few system calls that are not present and more importantly a certain memory range in protected mode is not shared addresses to SMM.

So, for the demo, they did not pick some shabby OS to exploit. How about OpenBSD at level2 (high security) with allowaperture=1
Ummm…it worked. Theo, microphone please?

Theo spoke to this OPENBSD issue and said he and the team have known about it for a year. They are between a rock and a hard-place because Xserver is really the core of the problem. It has too much damn access to regesters and is in the most unfortunate address space in protected mode because when in SMM, what is in that address range can be used to exploit.
Solution is for Xserver people to abstract sufficiently so that the kernel can have more governance on the Xservers logic.

Closing TK comments:
A system or a world that has a policy governed by in-world mechanisms cannot be effective when a process in-world can reach to the out-world to cause in-world change. You could also say that since a problem cannot be resolved at the same logical realm it has been created, then it is also the case that the most effective governance of a world can only come from outside that world. Think about all the crazy things we do in the physical world. As soon as we could get to the strong and weak forces at the atomic level, we created a incredibly destructive device. I just hope that if string theory is right and there really are energy strings at the lowest level of the universe, that no one in our world get control of them. The negative outcome caused by the power hungry is too high a risk to even consider the positive benefits.

Its late and I have been blogging way too much today I am certain that my mental packet loss is abnormally high. I’ll return to this in-game out-game concepts later in another blog entry, when I am less sleep deprived.

--tk "

--
trey @ gépház