eEye vs. Microsoft: Ki az oka?

Titkosítás, biztonság, privát szféra

Történt augusztus elején, hogy a Microsoft IE sebezhetőségeket javított az MS06-042 névre hallgató patch-ében. A patch elvileg 8 IE hibát tett volna hidegre, de... Közben kiderült, hogy a javított hibák mellett a patch olyan sebezhetőséget "épít" a Windows operációs rendszerek egyes verzióiba, ami miatt az IE összeomolhat, mitöbb biztonsági szakemberek megtalálták a módját, hogy a hibát kihasználva kódot futtathassnak az érintett rendszereken.

Az eEye Digital Security vezető kutatója, Marc Maiffret elmondta, hogy a patch kiadása után a levlisták tele voltak olyan jelzésekkel, miszerint az IE összeomlik. Ezután az eEye egyik kutatója rájött, hogy hogyan lehet a sebezhetőséget kihasználni.

Az eEye értesítette az MS-t, hogy kihasználható hiba van a hibajavító patch-ben. Ezután a Microsoft egy online figyelmeztetőben értesítette az ügyfeleit, hogy a patch-elt IE bizonyos esetekben összeomlik weboldalak meglátogatásakor, majd ígéretet tett, hogy újra kiadja a patch-et, javítva. A javított patch kiadásáig csak a fizető ügyfelek részére tett elérhetővé egy hotfix-et.

A javított patch kiadásáig a Microsoft titkolni akarta a hiba konkrét jellegét és súlyosságát. Az infó kiszivárgott de vajon ki hibázott?

A Microsoft két embere, Tony Chor és Stephen Toulouse az eEye-t, és személy szerint Marc Maiffret-et okolja az infók "felelőtlen kiszivárogtatásáért". Maiffret szerint pedig a Microsoft az oka az infók kiszivárogtatásának, hiszen a figyelmeztetőjében leírt mindent, ami ahhoz kell, hogy az exploit írók tudják hol kelljen keresgélni.

Maiffret szerint a Microsoft négyszeresen hibázott: a minőség-ellenőrzésnél, azzal, hogy hibát tettek a patch-be, azzal, hogy megpróbálták eltitkolni, és végül azzal, hogy a figyelmeztetőben maguk mutattak utat az exploit íróknak.

Szóval ment az egymásra mutogatás. Egy dologban értettek csak egyet, a felhasználóknak védeniük kell magukat.

Bővebben itt.

Ezen előzmények után a Microsoft tegnap végre kiadta a javított patch-et. Bővebben itt.

( Csigaa | 2006. 08. 25., p – 11:42 )

lol...
Vajon a MS-t is magyar politikusok vezetik? :D

( anr | 2006. 08. 25., p – 14:36 )

omlik ossze a cucc, nem tartja mar ossze a cellux;))

Távoli kódfuttatás vs. elneminduló Xserver. Eközött az a különbség, mint a víziló és a kabátgomb közt: egyikben sincs mazsola.
--
Mortal Kombat's gimmikk was to replake all instankes of the letter 'C' with the letter 'K' (bekause of that feature, it was one of the first applikations to bekome part of KDE).

Na, ezért meg fogod kapni a magadét. :-)
Amúgy meg jogos észrevétel, de én ilyen Microsoft-féle maszlagokat úgysem olvasok (ld. másik hír).
--
Mortal Kombat's gimmikk was to replake all instankes of the letter 'C' with the letter 'K' (bekause of that feature, it was one of the first applikations to bekome part of KDE).

( Morzel | 2006. 08. 25., p – 21:58 )

Én ezen nem csodálkozok. Egy általam nagyra becsült biztonságtechnikával foglalkozó emberke mondotta egyszer azt, hogy egy átlagos hibajavítás három új hibát hoz a szoftverbe. Ergo, ha van 100 hibád, amit javítasz, csinálsz sokszáz másikat a helyére, ésígytovább, ésígytovább....

Morzel

Azert azt tegyuk hozza, hogy ebben a formaban ez nem feltetlenul igaz, hiszen gondolj csak bele, egy szoftver fejlesztese is ugy zajlik, hogy lepesrol-lepesre beleteszel egy funkciot, teszteled, ha van benne hiba korrigalod, ha neincs akkor epited bele a kovetkezo funkciot (pongyolan fogalmaztam, ne tessek szabogatni engemet erzekeny lelku kollegak :-) ). Tehat, ha a fenti altalanos problema lenne, akkor meg mukodokepes szoftver nem szuletett volna. :-)

A fenti allitas _altalaban_ akkor igaz, amikor mar volt egy vagy tobb release es vigyazgatnod kell az API-kra, hogy a leheto legkevesebb dolgot erintse a patch (ha olyan a szitu), esetleg workaroundot kell bevetni, hogy az API sertetlen maradjon. Ugye a workaround meg olyan, hogy ha halmozod akkor magadat nehezited meg a kesobbi karbantartasoknal.

Nem vedem az MS-t de ilyen szempontbol ok sajat maguknak astak vermet a zart technologiakkal, hiszen rengetegen raepitkeztek es vannak alapok (API-k) amelyekhez egyszeruen nem nyulhatnak, mert borul az egesz "haz" is ami ra epult es ma mar a patcheles jobbara workaround-bol all. Ezert tart egy minosegellenorzesi procedura is hetekig-honapokig sokszor, mert az API-t vedeni kell. Ez abban is megneheziti a dolgukat, hogy alapveto konstrukcios hibakat dolgozzanak at, mert ha nem figyelnek a kompatibilitasra visszafele es a usernek ujra kell netan iratni egy szoftvert akkor nagy ra az esely, hogy legkozelebb (ha mar egyszer nagyobb melorol van szo) egy nyilt szabvanyokon allo platformra fog epitkezni.

---------------------
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

Azert azt tegyuk hozza, hogy ebben a formaban ez nem feltetlenul igaz, hiszen gondolj csak bele, egy szoftver fejlesztese is ugy zajlik, hogy lepesrol-lepesre beleteszel egy funkciot, teszteled, ha van benne hiba korrigalod, ha neincs akkor epited bele a kovetkezo funkciot (pongyolan fogalmaztam, ne tessek szabogatni engemet erzekeny lelku kollegak :-) ). Tehat, ha a fenti altalanos problema lenne, akkor meg mukodokepes szoftver nem szuletett volna. :-)

Hááát, azért ezzel vitatkoznék. Ha így menne a szoftverfejlesztés, akkor kíváncsi vagyok, hogy egy nagyobb project mennyi idő alatt készülne el. A fejlesztés menetében (ha nem számítjuk az ad-hoc módszert), nagyon a fejlesztési fázis vége fele van már a kódolás és a hibatesztelés.

Morzel

"Értem. És szerinted 100 000 kódsoronként kell tesztelni?"

Nem. Szerinted kell 100 000 soronként tesztelni: 'A fejlesztés menetében (ha nem számítjuk az ad-hoc módszert), nagyon a fejlesztési fázis vége fele van már a kódolás és a hibatesztelés.'

"És szerinted a program tervében nincsen hajszál pontosan leírva, hogy a program melyik része mit fog csinálni?"

Én még sohasem láttam olyan specifikációt, ami pontosan leírta volna, mit is kell csinálni. De ez nyilván az én problémám. Viszont teszteket (unit teszteket) azért ír az ember, hogy megbizonyosodjon arról, a kód azt csinálja, amit kell (ami a specifikációban áll), vagyis nem hibás a kód, amit írtunk. Gyengébbek kedvéért: a kód mindig hibás, amit írunk, csak idővel kijavítjuk. Ha vannak tesztek, hamar. Ha nincsenek... bukott projekt.

KisKresz