Intel processzorok sebezhetőségét tervezi bemutatni Kris Kaspersky

Intel

A számítógépes biztonsággal foglalkozó Kris Kaspersky azt tervezi, hogy az októberben a malajziai Kuala Lumpurban megrendezésre kerülő Hack In The Box biztonsági konferencián bemutatja azt az Intel processzorokban megbúvó sebezhetőséget, amelyet operációs rendszertől függetlenül, távolról ki lehet használni Javascript vagy TCP csomagok segítségével.

A szakember szerint egyre nő a processzorokban található sebezhetőségek kihasználására írt malware programokból fakadó fenyegetettség. Kaspersky állítása szerint működő kóddal (exploit) fog előállni, amelyet majd nyilvánossá is tesz.

A bemutató teljesen felpatchelt Windows XP, Vista, Windows Server 2003, Windows Server 2008, Linux és BSD rendszerek ellen fog zajlani. A részletek itt olvashatók.

( _peter_ | 2008. 07. 15., k – 14:53 )

Azért fain lett volna, ha az INTEL védelmében -> legalább ennyit még oda biggyesztel ->

Intel to release anti-theft technology in Q4

http://hup.hu/node/53375

--

"No trees were destroyed in the sending of this message. However,
a large number of electrons were terribly inconvenienced."

"de az meg -> nicns itt -> ugyhogy vegulis -> jo igy is -> atvenni slashdotrol -> ugye?"

Vazz NagyZ -> hadd ne keresem elő, de vagy 3 helyen beszóltál a "rámutató" nyilacskáim miatt. Most meg ezt kell LÁTNOM ->

LOL

--

"No trees were destroyed in the sending of this message. However,
a large number of electrons were terribly inconvenienced."

( subchee | 2008. 07. 15., k – 14:55 )

Elolvastam az eredeti cikket is, de nem igazán világos számomra, hogy miről is van szó. A chip -ek tervezési hibája ("errata") mit jelent? Az utasításkészlet tervezésével van a baj (=bekerült olyan utasítás, amit fel lehet használni támadásra)? Vagy fizikai tervezéssel (ha ezzel, akkor a hibás területek miért működnek?)?

Hozzáteszem, nagyon alapfokon van csak képem arról, hogy mi történik egy processzoron belül. (=amit a programtervező infósoknak bevezetőként elmesélnek a logikai kapukról és azok megvalósításáról)

Ha az első eset áll fenn (utasításkészlet), akkor ez most Intel specifikus, vagy érint minden x86 kompatibilis procit? Miért nem ad választ erre az eredeti cikk? :)
(vagy csak egyedül én értetlenkedek ezen, másnak világos??)

Az Intel® Atom™ procik vonatkozó doksijából a nevezéktani részből kiemelve:

Errata are design defects or errors. These may cause the Intel® Atom™ processor
Z5xx series on 45-nm process behavior to deviate from published specifications.
Hardware and software designed to be used with any given stepping must assume
that all errata documented for that stepping are present on all devices.

( Hiena v | 2008. 07. 15., k – 15:51 )

Mar vartam az ilyen jellegu kartevok megjeleneset. Az x86 visszafele kompatibilitasanak az eroltetesevel egyre nagyobb az eselye, hogy valami hiba csuszik a microcode-ba. Ahogy no a processzor komplexitasa egyre nagyobb ujabb hibak bekerulesenek, es ezt egyre kevesbe tesztelik.
Emellett az egyre jobb OS szintu vedelmek, plusz az OS diverzitas novekedese egyre inkabb celzotta teszi az architekturat magat.

Maga az errata a microcode, az utasitas dekoder, es az egyeb procin beluli hibak osszessege, (ilyen volt pl. a Pentiumok FDIV bugja). Ezen hibaknak, adott esetben nincs kozvetlen hatassa a proci normal mukodesere, de remekul kihasznalhatoak (prociverzio fuggo kodfuttatasi lehetoseg kiaknazasa, egy "be nem tervezett" extra ugrasi utasitas miatt, vagy hatekonyabb memoriamuveletek egy extra aritmetikai kod miatt)

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( emberk | 2008. 07. 15., k – 15:55 )

\összeesküvéselmélet indul
Kris Kaspersky produced by AMD
\összeesküvéselmélet vége.

De az ökörséget félretéve. Kíváncsi vagyok hogy ez mi lehet? Pláne hogy oprendszerfüggetlenül. Valami memória injektálás? Na majd kiderül.

Néhány érdekesebb errata az Atom prociból:

  • Using 2M/4M Pages When A20M# Is Asserted May Result in Incorrect Address Translations
  • Values for LBR/BTS/BTM will be Incorrect after an Exit from SMM
  • Incorrect Address Computed For Last Byte of FXSAVE/FXRSTOR Image Leads to Partial Memory Update
  • Fault on ENTER Instruction May Result in Unexpected Values on Stack Frame
  • Code Segment Limit/Canonical Faults on RSM May be Serviced before Higher Priority Interrupts/Exceptions and May Push the Wrong Address Onto the Stack
  • BTS(Branch Trace Store) and PEBS(Precise Event Based Sampling) May Update Memory outside the BTS/PEBS Buffer

"Arra nem találtam még választ, hogy az ilyen patch-ek teljesen házi barkács dolgok, vagy a proci gyártó is besegít, legalább doksival?"

Nem, ezek szinte mindig gyariak (annal is inkabb, mert az intel nagyon komolyan vedi a microcode-t, es az update routine-jat a reverse engineering-tol).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

core 2 elso szeriaiban volt igen durva hiba, azt hiszem valami olyasmi, hogy ha az egyik mag ir a L2 cachebe, es a masik olvas belole ugyanonnan, akkor hulyeseget olvas, vagy megfagy vagy ilyesmi :) bios frissitessel javitottak a doksi (es emlekeim) szerint.

szerk: ja, valami hasonlo, lasd itt AI39
- Use the Source Luke ! -

( log69 | 2008. 07. 15., k – 17:01 )

Ha ilyen hibákat produkál a vezető processzor gyártó, akkor ehhez nincs mit hozzátenni. Vagy Kaspersky kollégának több ideje meg pénz/humán kapacitása van eljátszadozni a lehetséges exploitok felderítésével?

Nem tudom hogy ez másnak hogyan jön le, de nagyon olyan szaga van, hogy az Intel is nagyon hamar gyorsan akar bevételre szert tenni, közben meg eladja a hulladék termékét.

Nem azt mondom hogy nem hibázhat, de kicsit bele kell gondolni, hogy 1 dolgot kell megtervezni, a legyártás utána már más kérdés. A terv legyen jó. És meggyőződésem hogy nem fordítanak elég időt és pénzt rá (nem mintha nem lenne), hogy megfelelően tesztelve legyen a termékük. Legalábbis ha bebizonyosodik hogy ilyen durva hibákat tartalmaz.

Engem csak ott bosszant a dolog, hogy gyakorlatilag az Intel-en meg AMD bácsin kívül nincs választási lehetőségem. Mert egyébként rendben lenne ha én válogathatnék sok gyártó közül, hogy melyiket veszem.

Látszik, hogy nem jársz demoscene partikra. Pont most volt szó a Scenecon-on, hogy a Genesi ppc alapon akar gyártani egy 10" koruli notebookot.
Raadasul az a vas amit bele akarnak tenni, jelen pillanatban framebuferrel kepes a nagyfelbontasu videokat lejatszani anelkul, hogy az ativec-et hasznalna.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Raadasul az a vas amit bele akarnak tenni, jelen pillanatban framebuferrel kepes a nagyfelbontasu videokat lejatszani anelkul, hogy az ativec-et hasznalna.

most vagy fuzios eromurol fog menni a notebook, vagy valami nagyon primko video volt amit lejatszott (720p24 1Kbit/s)

- Use the Source Luke ! -

Ha jol emlekszem a bemutatott ket gep kozul az egyik MPC8610@1.3GHz a masik egy MPC5121e@400MHz alapu volt. A nagyobbik a Big Buck Bunny 1080p 24fps valtozatat nyomta.
A kisebbik lap, osszesen 10W-ot kert, maga a proci mindenfele hutes nelkul ment, tapintometrikusan kisse langysnak tunt.
A nagyobbik gepnel a parti elejen volt par fagyas a videolejatszasban, aminek az oka a ratakolt ventillator leallasa volt. A freescale adatlapja szerint 1333MHz-en irgalmatlan 15W-ot eszik ez a proci.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

mar bocs de ez 1080p24 1.3Ghz-en altivec nelkul eleg hihetetlenul hangzik.
Eleve hogy jelenitette meg az 1080p kepet ? Az mpc8610 display controllere nem tamogatja mar azt a felbontast.

Szoval egy hd videohoz mar kell egy kb. 3Ghz-s core 2 egy magja, sse-vel meg mindennel. Nem hiszem, hogy a ppc architektura kb 6-szor olyan gyors/orajel mint a core 2.

- Use the Source Luke ! -

"Integrated Display Controller supports up to SXGA 1280 x 1024 resolution and 24 bits per pixel"

Emlekeim szerint az adott gepben valamilyen Ati Radeon PCI-Express kartya volt. Hogy pontosan milyen, azt nem tudom.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

akkor is lehetetlenul hangzik, hogy a cpu azt ugy dekodolja, hiszen a core 2-nek meg ennek a ppc magnak ugyanugy pl. 3 integer unitja van (ugye a h264/mpeg2 dekodolas integer muveletek foleg), csak pl. a core 2-e okosabbak (mindegyik tud szorozni is pl.) - szoval a proci leirasok alapjan egyaltalan nem tunik gyorsabbnak ez a freescale cucc mint a core 2, sot, plane nem 6-szor olyan gyorsnak (mikozben fele annyit fogyaszt ;D).

- Use the Source Luke ! -

nem hiszem, hogy itt hatranyban lenne a core 2, leven hogy azon is az sse2 utasitasok nagy reszenek a throughputja max 1, foleg uj core 2-n a latencyje is, viszont itt tobb/okosabb vector unitok vannak, szoval sok sse2 utasitas throughputja kevesebb, 1/5 vagy 1/3-ad orajel.
Amit te mondasz az inkabb a p4-re igaz szerintem (arra igaz is teljesen).

- Use the Source Luke ! -

Frissites!
Leveleztem a bemutatót tartó sráccal, tehát itt vannak a "hivatalos" adatok a devboardrol:
A video 720p volt, ezért mea culpa, a részemrol.
A video az integrált videon futott, frambuffer meghajtóval.
512MB memória volt a lapon.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ooooo... Egyreszt 720p-s valtozat ment (1280x720, vagy vmi ilyesmi). Masreszt meg az MPlayer nyilvan AltiVec tamogatassal lett forditva. Az optimalizalas nelkul az arra vonatkozott, hogy tok mezei framebuffer, semmi hardveres magia, vagy az adott chipre optimalizalas nem volt benne. Asszem. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Tud. Bar azert ha a procin kell csinalni a color space conversiont (framebuffer van!), akkor azzal izzad a C2 is csunyan... :) Amugy a bemutato annak szolt, hogy a G4-es cuccok nem tudtak jellemzoen eddig ilyet. :) De a 8610 ala betoltak egy nagyjabol epkezlab buszt vegre a tortenelem elotti 604/MPX helyett, oszt hirtelen kijott az AltiVecbol a kraft. Pedig a procmag ugyanaz. Ki erti... :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Pl. a CAS által továbbfejleszett MIPS klón, x86 támogatással. Az előadást stílusszerűen Godson2-s kis eee klónon, RedOffice-al csinálta. Egyébként igen, övék a Lenovo többségi tulajdona is. Bárcsak pl. a Neumann társaság, a BME, ELTE meg az MTA (CAS) is számítástechnikával foglalkozna...

Még egy dolog. Számomra nem világos (nem értek hozzá), de nem biztos hogy jó ha maga a hardver válik bloatware-ré. Ha bővül az utasítás készlet, akkor az architektúra bonyolódik és a feldolgozási idő megnő --> lassúl.

Kicsit eltúlozva: Nem azt mondom hogy egy RISC a megoldás, de nem kellene sok a prociba. Legyen load + store + bitshift meg a logikai, az fpu-ban meg legyen szögfüggvény, logaritmus meg 0..1 hatvány. Ezt huzalozzák le, viszont fénysebessen menjen. Az optimalizációt meg bízzuk a szoftveres megoldásokra. Így könnyebb lenne sokáig hardveres kompatibilitást tartani. A prociba amúgy is egy rakás dolgot kell fejleszteniük (pl. régen asszem a cyrix-oknál kezdték el azt, hogy bizonyos loop-okat kihagyott ill. a cache-be az előre megjósolt ágat rántotta be - de pesze nem akarom a maiakat ezzel hasonlítani). Meg persze 10 éve el kellett volna hagyniuk a 8086 kompatibilitást.

Szóval nem biztos hogy úgy kéne gyorsítani, hogy majd natívan fog futni a Java. Minél kisebb az utasításkészlet, annál jobban lehet célspecifikusan optimalizálni szerintem és kisebb is lenne az exploit lehetőség.

A fenn emlitett BTS hiba, pont a prefetch/elagazas-prediktalas resze.
Amugy en is a RISC jellegu megoldasok hive vagyok. Kisebb utasitaskeszlet, kevesebb kapu a magban, ergo magasabb orajelfreki, mindez kismeretu cachekkel megfuszerezve igen gyors architekturat eredmenyezne.
Mondjuk a cache maniarol egy regi G4 PPC reklam/cikk jutott az eszembe ahol a kismeretu cache-t egy egerhez, a nagymeretu cache-t meg egy elefanthoz hasonlitotta.
Ha a ket allat, ugyanazt a kajamennyiseget (kod) kezdi el enni, es ebben romlott reszek vannak (hibas elagazas prediktalas), akkor az eger hamarabb fog vegezni az evessel es kiszarni az eredmenyt, mint az elefant, mert ha romlott reszt eszik valamelyik, akkor azt ki kell hanynia (cache urites), es kajanak vegig kell mennie a teljes emesztorendszeren (pipeline), ami egy elefant esetben igen hosszu.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szép ez az egeres-elefántos hasonlat... De azt is vedd figyelembe, hogy egy valamirevaló x86 leszármazott processzorban jó adag szilícium dolgozik azon, hogy a feltételes elágazásokat megbecsülje, a PPC meg még a feltétel nélküli ugrásokat se tudja, ezért szegény egérkét még akkor is elkapja a heves hányinger, amikor az elefánt lazán kihajítja a romlott részeket az ormányával.

( willy v | 2008. 07. 15., k – 19:05 )

Csak aztan nehogy kideruljon, hogy nem volvo, hanem volga, es nem oslo, hanem moszkva, es nem osztogatnak, hanem fosztogatnak...