A Microsoft .ANI javítása problémát okozhat bizonyos alkalmazások futásában

Bug

A Microsoft reagált a "Microsoft Windows Animated Cursor Handling Vulnerability" néven futó hibára, és javítást tett közzé. Egyes hírek szerint azonban a javítás bizonyos programok (Realtek HD Audio Control Panel, CD-Tag) futását akadályozhatja. Ezt orovosolandó, a Microsoft fix-et készített, de az álláspontja az, hogy ezek elszigetelt problémák, így nem tervezi a fix terjesztését a Microsoft Update-en keresztül. Legalábbis így tudja a Slashdot.
Ugyanakkor a Microsoft Security Response Center Blog-ban elolvashatjuk, hogy az .ANI hiba javításának kifejlesztése miért vett igénybe 3 hónapot (a Determina 2006. december 20-án jelezte a problémát az MS-nek).

( adarazs | 2007. 04. 04., sze – 21:42 )

Elég meghökkentő dolog azért ez. Több, mint 3 hónapig tartott ezt a biztonsági hibát befoltozni.

Az egyik lehetőség, hogy rá se hederítettek 3 hónapig, aztán pár nap alatt megírták a javítást, amikor már nagyon kínos kezdett lenni a helyzet.

A másik pedig, hogy tényleg 3 hónapig tart kijavítani egy ilyen hibát. A belinkelt írás alapján ez történt. Januárban és februárban próbálták kibogozni, hogy hol a hiba. Rájöttek, hogy több modult is érint, sőt, a vizsgálódás közben 7 hibát javítottak ki, aminek ehhez az animált kurzorhoz volt köze.
Aztán egész februárban és márciusban azzal foglalkoztak, hogy megcsinálják a javítást és teszteljék. Állítólag minden Windows-zal kapcsolatos hibát 2 hónapig tesztelnek. Ebben az esetben több száz ember foglalkozott azzal, hogy különböző helyzetekben teszteljék a javítást. Eközben 80 lehetséges, frissítés során jelentkező problémát oldottak meg.

Nem akarom szapulni a Microsoftot, hogy milyen lassan reagáltak, csak elgondolkodtam rajta, hogy milyen brutális erőforrásokat emészt fel egy ilyen, nekem kisebbnek tűnő hiba. Legalább 1 ember teljes munkaidőben dolgozott rajta negyed évig!

Én átlagos bugnak egy olyat képzelek el, hogy a fejlesztő túlcímez egy tömböt, valaki észreveszi, a fejlesztő azt mondja, hogy "ja, kösz.", átír egy számot és kiad egy patchet/javítást/új verziót.

Ez az elképesztő erőforrás és időigény, ami egy ilyen hibát kísér meglepő. És meglepő lenne, ha ezzel az erőforráspazarlással fenttartható lenne a Windows fejlődése vagy egyáltalán egybentartható lenne a Windows. Hiszen a képek alapján a Vista is érintett valamilyen szinten, szóval ez a kód is egy az egyben ment át az XP-ből (és feltehetően az előző verziókból). Az XP és Vista között eltelt fejlesztési időben tehát többnyire inkább új dolgokat programoztak bele, ami megintcsak ilyen komplex és erőforrásigényes javításokat fog igényelni.

Nem sok emberélet/pénz/idő egy kicsit? Vagy az enterspájz világban ez a normális és csak opensource szemmel ilyen fura ez az elemzés, ami azt bizonygatja, hogy mennyire rendben is van az, hogy 3 hónap volt ezt összehozni?

Ez a vulnerability rengeteg alaszintű rendszerkomponenst érint, ezt azért komolyan tesztelni kell.
szerk.: egész pontosan a GDI-t.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

én sem értek hozzá (hehe)
de ha már el vannak különítve, akkor én úgy kézelném el, hogy az .anihoz tartozik egy lib, ami parszolja őket, azt megjeleníti. Gondolom a libben hiányzott valami (pl escapelés) és szépen végrehajtotta az ani-ba rejtett kódot. paff, befoltozzák a libet, és kész. Dehát vagy nem ilyen 1xű a helyzet, vagy az egész gányolva van, mert úgyis closed source.

Figyi, ha viszaolvastál, tudod, hogy nem a parser lib a hibás, hanem a GDI rétegben volt hiba, ami történetesen itt jött elő. A GDI réteg felel minden grafikus objektum kirajzolásáért a Windowsban.

Lehetségesnek tartom, hogy az animált kurzorok megjelenítésére pont egy olyan API volt használva, amit más már nem nagyon használ, mert kvázi deprecated, és csak az ilyen stuffok használták.

"LoadAniIcon függvénynél a buffert pont nem követi semmiféle canary, így könnyedén átírható a visszatérési érték másra és pl. 'return to libc' technikával (hogy a nonexec heap/stack védelmeket is meglehessen kerülni ;) saját paraméterekkel hívhat meg rendszer függvényeket az ember."

GDI milyen priv. szinten megy ?

"kvázi deprecated" a "stabil platformon" na ne viccelj :)

Több, mint 3 hónapig tartott ezt a biztonsági hibát befoltozni.

Valószínűleg nem csak ez az egy biztonsági hiba várakozott befoltozásra. Amikor pedig jóval több van, akkor annak függvényében növekszik (illetve kitolódik) az adott javítás kiadásának időpontja...

Tehát ha decemberben kétszer ennyi távoli kódfuttatást lehetővé tevő hibát jelentenek nekik, akkor csak fél év múlva adják ki a javítás hozzájuk?
Nem hiszem, hogy olyan sok hasonló kaliberű volt ezen kívül ebben az időszakban. Tehát a mennyiség nem hiszem, hogy ok a késlekedésre. Inkább tényleg a tesztidőszak. Nem voltak benne biztosak, hogy nem rontottak-e el valami mást azzal, hogy ezt kijavították. Na meg abban, hogy egyáltalán kijavították-e rendesen.

Tehát ha decemberben kétszer ennyi távoli kódfuttatást lehetővé tevő hibát jelentenek nekik, akkor csak fél év múlva adják ki a javítás hozzájuk?

A helyzet ennél komplikáltabb, mert a hibákat is osztályozni kell ekkora projektnél (és ennyi bugnál ;)

Nyilván azokat a 0day sebezhetőségeket, amelyeket már aktívan kihasználnak a támadók mindenfele nagyobb prioritással kezelik, mint azt, amelyet egy IT Security cég bejelentett és (elméletileg) rajtuk kívül más nem tud a problémáról... Az ilyenfajta súlyozás miatt épp ezért a publikum által nem ismert hibákat kisebb intenzítással javítják, így akár hónapokba (nem kritikus hiba esetén akkor 1 évbe is) beletelhet. Ez egyébként elég tipikus hozzáállás és minden szoftverfejlesztő cég így csinálja (máshogy sajnos nem nagyon lehet, max. akkor, ha rengeteg erőforrással rendelkeznek, de ilyen szempontból leginkább mindenki hiányban szenved :). Aztán persze amikor a bugról kiderül 3 hónappal később, hogy már nem csak a bejelentő tud a hibáról, hanem folyamatos visszaélések történnek szerte a világban ennek köszönhetően, akkor hirtelen megváltozik a bug besorolása és nagyobb csapat, több időt raszánva kezd el dolgozni a problémán.

Nem hiszem, hogy olyan sok hasonló kaliberű volt ezen kívül ebben az időszakban.

Hinni lehet sokmindent, de a valóság sajnos nem annyira rózsaszínű... :)

Inkább tényleg a tesztidőszak.

Amikor én a hiba befoltozását írtam, akkor abba beleértettem a hiba felderítésétől a javításán keresztül a tesztelésig és kiadásig mindent. Ez így együtt igényel sok időt, nem a folyamat első két lépcsője. Az most az MS-független ZERT javításnál is kiderült, hogy bugfixet kilehet adni gyorsan tesztelés nélkül, csak épp problémák lehetnek vele. Negyedik nekifutásra azért sikerült nekik is valami használhatót kiadni... (Vajon mit kapott volna a fejére a Microsoft, hogy ha neki is csak negyedikre sikerül, így is látszik, hogy a nem megfelelő tesztelés miatt, nagy kapkodva elrontották az első patchet és még mindig nem százas a helyzet :)

Szóval ilyen mennyiségű kódnál és ennyi third-party szoftvernél már elég lassan őrölnek a malmok.

"Nem sok emberélet/pénz/idő egy kicsit? Vagy az enterspájz világban ez a normális és csak opensource szemmel ilyen fura ez az elemzés, ami azt bizonygatja, hogy mennyire rendben is van az, hogy 3 hónap volt ezt összehozni?"

Szerintem igencsak nézőpont kérdése. Az biztos, hogy egyfelől plusz anyagi ráfordítást igényel a zárt forráskód, hiszen saját tesztereket kell alkalmazni. Nyílt forráskódnál ez valamivel egyszerűbb, hiszen a felhasználók is bekapcsolódhatnak a fejlesztésbe, küldhetnek bugreportot, véleményt, vagy akár patchet. Ahogy látom, a Linux kernellel is ezt csinálják: egy-két hetente kijön egy rc, aztán tessék küldeni bugreportokat.

Másrészt szerintem a Microsoft nem is akar ilyen állandó világméretű teszteléseket végezni (bármennyire is ez a tendencia újonban, ld. nyílt béták). Open Source körökben ugyebár a program egy folyamatossan fejlődő valami. KDE4-be is sok-sok dolog folyamatossan fog csak belekerülni. Vannak ugyan időszakok, amikor kiadnak egy-egy nagyobb változtatást, de alapvetően egy folyamatossan változó valami.

Microsoftnál (meg sok más cégnél) ritkábban a kiadási időszakok (ami most a Vista késése miatt igencsak jól elnyúlt), viszont jelentősebb változások vannak. Igen, lehet, hogy benne van a marketing is, első ránézésre is újnak hasson (pl szebb legyen). OS körökben ez is kijön, ha mondjuk veszel egy 5-6 évvel ezelőtti disztot meg egy mait. Viszont egy n. ubutnu és n-1. ubuntu kiadás között nincs olyan egetverő különbség első ránézésre.

MS-nél alapelv az, hogy ha egyszer kiadnak valamit, akkor az kész van. Igen, persze sose tökéletes, mindig vannak hibák, ki is javítják azokat úgy időnként, de attól még a cél az, hogy alapból minden működjön.

OS körökben meg gyakran előfordul az, hogy valami az n. verzióban nem működik mindenhol, n+1. verzióra viszont már javítják, viszont ott meg más újdonság nem tökéletes, amit persze az n+2-ben javítják. stb.

A három hónap meg tényleg eléggé soknak tűnik. De úgy néz ki ez az ára annak, hogy ennyien használják ezt a platformot. Viszont sok Windows 95-re, vagy akár régebbi Windowsra írt program is elfut még ma XP-n, vagy akár Vistan is. Nem azt mondom, hogy mind, mert én is szívok néhány régebbi programmal, de azért sok.

És hogy meddig tartható fenn ez? Jó kérdés. Viszont ami tetszik, az az, hogy az MS végez kutatásokat előre (Windows Nextgen), más kérdés, hogy nagyon be tudnak velük cumizni (Windows Longhorn első verziói, 4-5 Ghz-s procikról vízionáltak a gyártók 2003-4 környékére, csak azok elmaradtak, így a Longhorn is. Legalábbis ezt olvastam valahol -- talán itt a hupon írta valaki).

---
A Linux nem Windows, de a Windows se Linux.

> "Viszont sok Windows 95-re, vagy akár régebbi Windowsra írt program is elfut még ma XP-n, vagy akár Vistan is. Nem azt mondom, hogy mind, mert én is szívok néhány régebbi programmal, de azért sok."

Ez nem olyan kiemelkedő dolog azért. A Linux kernel userspace interface-e GKH állítása szerint (kernelsource/Documentation/stable_api_nonsense.txt) régóta stabil, vannak programjai, amit 0.9x-es kernel alatt fordított és a mai napig működnek a 2.6-os kernelek alatt is. (1992 márciusában jelent meg a 0.95)

Viszont én is futottam bele többször olyanba, hogy Windows XP megjelenése előtti Microsoft gondozásában megjelent program/játék nem indult el XP-n (compatibility móddal se - valamelyik Age of Empires rész volt, amire biztosan emlékszem).

A Linux kernel userspace interface-e GKH állítása szerint (kernelsource/Documentation/stable_api_nonsense.txt) régóta stabil

:)))

Az! Amikor még a 2.4 és 2.6 közötti váltást is orrba-szájba cumizza az ember a glibc-től kezdve mindennel.

vannak programjai, amit 0.9x-es kernel alatt fordított és a mai napig működnek a 2.6-os kernelek alatt is.

Jah, gondolom egy helloworld.c statikus ELF binárisra fordítva (mert az a.out formátummal már igencsak szopás lenne ;).

Viszont én is futottam bele többször olyanba, hogy Windows XP megjelenése előtti Microsoft gondozásában megjelent program/játék nem indult el XP-n (compatibility móddal se - valamelyik Age of Empires rész volt, amire biztosan emlékszem).

Igen, ez az a játék, amelyik gond nélkül működik XP-n (és akár Windows Server 2003-on) is, kivéve ha az ember egy feltört változattal próbálkozik, mert annak a crackje érvénytelen memóriaterületen akar kotorászni, amit az NT alapú kernelek nem honorálnak túl jól... ;)

Érdekes, én találkoztam AOE 1-2-3al is ami XP-n futott, nem is egy helyen és gond nem volt velük, úgy láccik warezxp+warezaoehez is érteni kell ;-). még a 64bites verzión is (bár ott csak AOE1-2t láttam futni). mondjuk matricákat, meg hasonlókat nem nagyon láttam. de biztosan minden legális volt, legalábbis én naívan ezt feltételeztem. ;-)

---------

Nem a zsömle kicsi, a pofátok nagy...

> Igen, ez az a játék, amelyik gond nélkül működik XP-n (és akár Windows Server 2003-on) is, kivéve ha az ember egy feltört változattal próbálkozik, mert annak a crackje érvénytelen memóriaterületen akar kotorászni, amit az NT alapú kernelek nem honorálnak túl jól... ;)

Khm, ezek szerint pont a CD-m biztonsági másolatáról próbáltam telepíteni. 0:-) Most, hogy mondod, tényleg elég volt új cracket leszedni és ment. 6 éve volt már az eset nagyjából. :)

"Jah, gondolom egy helloworld.c statikus ELF binárisra fordítva (mert az a.out formátummal már igencsak szopás lenne ;)."

hehe, nekem is ezek jutottak rola eszembe :)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

ketto darab symlink legyartasa utan:

# ./vim
./vim: symbol lookup error: ./vim: undefined symbol: __libc_init

pedig ez csak:
-rwxr-xr-x 1 root bin 344878 Jul 10 1997 vim

de biztosan en rontottam el valamit :)

--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.

( BlinTux v | 2007. 04. 05., cs – 07:50 )

Jo munkahoz ido kell, lassuhoz meg megtobb :D

( trey | 2007. 04. 06., p – 11:01 )

Valóban "szopesz a káresz" a dolog. Ma kb. 6 bejelentés jött hozzánk, hogy:

"Rthdcpl.exe - Szabálytalan rendszer DLL áthelyezés

A rendszer DLL (user32.dll) a memóriában áthelyezésre került. Az alkalmazás nem fog megfelelően futni. Áthelyezés történt, mert a DLL (C:\Windows\System32\Hhctrl.ocx) a Windows rendszer DLL-ek számára fenntartott címtartományt foglalta el. Új DLL-ért lépjen kapcsolatba a DLL-t biztosító forgalmazóval."

(Éjjel lejött a frissítés, reggel ezzel indultak egyes gépek (amiken ilyen Realtek hangbizbasz van))

Feltettem a javításkát az egyikre, de még nem boot-oltam újra. Remélem megjavítgatja.

--
trey @ gépház