- A hozzászóláshoz be kell jelentkezni
- 5939 megtekintés
Hozzászólások
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?
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Az is durva, hogy egy animált kurzor mennyire össze van drótozva más dolgokkal. Nem értek annyira hozzá, de szerintem az ilyesminek igencsak el kellene különülnie a program többi részétől...
- A hozzászóláshoz be kell jelentkezni
Nem értek annyira hozzá, de szerintem az ilyesminek igencsak el kellene különülnie a program többi részétől
El is különül szépen, .ani kiterjesztésű állományokba. :)
--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven
- A hozzászóláshoz be kell jelentkezni
é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.
- A hozzászóláshoz be kell jelentkezni
Olvassatok föntebb.
Amúgy meg ha closed source, akkor már gányolt? :-)
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)
- A hozzászóláshoz be kell jelentkezni
neem, nincsenek előítéleteim, csupán nem értettem a dolgot, és merem fetételezni, hogy egy vista méretű projectnél nem gányolHATNAK a fejlesztők, mert akkor az eredmény instabil, kiszámíthatatlan, secholos lesz. ,)
- A hozzászóláshoz be kell jelentkezni
Én poénnak szántam, ha nem jött le, akkor bocs... :)
--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven
- A hozzászóláshoz be kell jelentkezni
biztosan ezt a verziot latta belole ;(
de ha valakit erdekel egy (tetszes szerint megkerdojelezheto) cikk a temarol, az olvassa el ezt: a quick look at the Win2k source
--
The Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
- A hozzászóláshoz be kell jelentkezni
haat. a vista biztos nem 'ganyolt', hiszen mint tudjuk, a 'kod nem megfelelo minosege' miatt 2004-ben kidobtak belole az osszes 'ganyolt' kodot, es inkabb ujrairtak az egeszet.
haat. ahol elso nekifutasra ket evnyi fejlesztest ki kell dobni...
- A hozzászóláshoz be kell jelentkezni
hát, nálad a "hozzánemértő" még jóindulatú jelző lenne. :)
- A hozzászóláshoz be kell jelentkezni
Mester. Elmondanád mennyire és hova van beásva az .ani kurzor támogatás? Ill szerinted is ott a helye?
Valamint normális dolog -e, hogy ha javítanak vmit az egér kurzoron, akkor nem megy egy mixer alkalmazás?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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 :)
- A hozzászóláshoz be kell jelentkezni
>> GDI milyen priv. szinten megy ?
gratulálok
- A hozzászóláshoz be kell jelentkezni
thx.
Fogalmazd át, ha nem tetszik. :P
- A hozzászóláshoz be kell jelentkezni
"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." - Ami még mindig nem magyarázat arra, hogy miért tör el egy audio control panelt. :)
- A hozzászóláshoz be kell jelentkezni
mert rajzolni kell azt is?
- A hozzászóláshoz be kell jelentkezni
Mert nem egy nyamvadt kis ablakocska, hanem gondolom valami csilli-villi designos lófütty. sndvol32 rulez.
- A hozzászóláshoz be kell jelentkezni
Nincs lib. A GDI a kernel része (az NT4 óta, ld. http://en.wikipedia.org/wiki/Windows_NT_4 ).
Hogy ez mennyire uncool dolog, arról már néhányszor beszélgettünk.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, próbáltál-e már Gnome komponenst felrakni az egész Gnome nélkül... nem fog sikerülni.
;-(
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
> "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 hozzászóláshoz be kell jelentkezni
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... ;)
- A hozzászóláshoz be kell jelentkezni
>> Igen, ez az a játék
erről lassan kell egy faq, vagy legalább egy táblázat linuxos testvéreinknek, hogy a warezxp/warezaoe milyen kombinációkban működik :)
- A hozzászóláshoz be kell jelentkezni
É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...
- A hozzászóláshoz be kell jelentkezni
Most tessék megrökönyödni: Én még a béta verziós Vistán is AOE-ztam. Igaz, hogy csak az 1-essel...
- A hozzászóláshoz be kell jelentkezni
> 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. :)
- A hozzászóláshoz be kell jelentkezni
lám lám ;)
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Közben megbeszéltük IRC-n, hogy 0.9x-ben még nem is volt ELF támogatás, csak később 1.2 környékén került be... :)
- A hozzászóláshoz be kell jelentkezni
a.out még mindig van.
- A hozzászóláshoz be kell jelentkezni
Na, fordíts egy helloworld.c-t a.out binárisra gyorsan a Gentoodon, hagy lássam milyen ügyes vagy. :)
Hint: nem attól lesz a.out, hogy ilyen filenévvel jön létre a bináris, a formátuma legyen a.out... ;)
- A hozzászóláshoz be kell jelentkezni
majd vizsgaidőszak után
- A hozzászóláshoz be kell jelentkezni
;))
- A hozzászóláshoz be kell jelentkezni
"Hint: nem attól lesz a.out, hogy ilyen filenévvel jön létre a bináris, a formátuma legyen a.out... ;) "
5000 évre banolnának, ha erre az első gondolataimat leírnám.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Jo munkahoz ido kell, lassuhoz meg megtobb :D
- A hozzászóláshoz be kell jelentkezni
A pszichiátriai kezeléshez még több... :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
A foenoek szaamlazooprogija is lehet, hogy ennek esett aaldozatul tegnaprol maara...
- A hozzászóláshoz be kell jelentkezni
ne, ezt ne
- A hozzászóláshoz be kell jelentkezni
tuvudsz ivigy beveszévélnivi? :P
- A hozzászóláshoz be kell jelentkezni
szerintem a fudra gondolt, nem a diszgráfiára
- A hozzászóláshoz be kell jelentkezni
Miért?! Nekem pont azóta nem ég a kocsin a jobb első fényszóró... :\
Nem lehetne az MS-t valahogy kérdőre vonni ezért?
- A hozzászóláshoz be kell jelentkezni
:)
Nekem azóta javult meg a hangszóróm. Most akkor éltetni kell az MS-t?
- A hozzászóláshoz be kell jelentkezni
nem, a táviratra gondoltam, de ha már csinálja, legalább csinálná rendesen :)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni