Patch voor 17 jaar oude bug blijkt oorzaak van bsod's in XP

Microsoft heeft op 9 februari via Windows Update een patch verspreid die bij sommige Windows XP-gebruikers tot een blue screen of death leidt. De update was bedoeld om een zeventien jaar oud beveiligingslek te verhelpen.

Na installatie en herstarten van de pc, werden diverse gebruikers met een 'PAGE_FAULT_IN_NONPAGED_AREA'-melding geconfronteerd, waarna de machine opnieuw opstart. De oorzaak van de crashende XP-systemen blijkt de op 9 februari vrijgegeven update KB977165 te zijn, een patch die een 17 jaar oude beveiligingsbug moet dichten.

Een Microsoft-medewerker heeft op het support-forum van de softwaregigant een bruikbare workaround gegeven: door de betreffende update met behulp van de recovery console te deïnstalleren, kan het systeem weer zonder problemen opstarten. Gevolg van het verwijderen van de patch is uiteraard wel dat het systeem weer kwetsbaar wordt voor de antieke bug. Het is volgens de medewerker echter mogelijk de computer alsnog te beschermen via een tool die het lek dicht zonder daarbij bsod's te veroorzaken.

Reacties (174)

[Auredium]

Ik vraag me dan toch af waarom de BSOD wordt veroorzaakt. Zou het kunnen zijn dat MS in al hun progsels een kritiek deel via dat lek laat werken in XP? Dat zou kunnen verklaren waarom het probleem optreed na patchen van dat lek.

[wildhagen]

Zou het kunnen zijn dat MS in al hun progsels een kritiek deel via dat lek laat werken in XP?

Extreem onwaarschijnlijk, het gaat namelijk om de NT Virtual DOS Machine (NTVDM) die kwetsbaar is, die word enkel gebruikt om nog DOS-applicaties uit te voeren. Windows XP is helemaal niet meer gebaseerd op DOS, en zal dus dat ding zelf ook niet gebruiken.

[captain007]

NT Virtual DOS Machine wordt ook gebruikt om 16-bit applicaties te starten. Dat wil nog wel eens voorkomen bij sommige oude installers.
Ik vermoed dat NT Virtual DOS Machine standaard wordt geladen bij het opstarten van Windows. En aangezien dat die Virtual DOS Machine in Kernel mode draait levert dat een BSOD op wanneer er een fout ontstaat (door een bepaalde soort configuratie, o.i.d).

[Bor]

Een deel van het OS laten werken via een bug? Dat lijkt mij totaal onzin. Het kan niet anders dan het lek zit in een deel wat onderdeel is van het OS maar dat er bij het maken van een nieuwe / aangepaste versie van de bestanden gewoon een andere bug is opgetreden.

[Anoniem: 175233]

Het is maar een klein deel van de gebruikers waarbij het optreedt. Het ligt dus meer voor de hand, dat die gebruikers iets vreemds geinstalleerd hebben dat daarin werkt...

[Keypunchie]

Bij Microsoft ga je dan meteen kwade dingen denken als "Zouden ze het expres doen om mensen te laten upgraden naar Windows 7?"

Raar verhaal dit, want lijkt me dat het maar in beperkte gevallen voorkomt. Maar bij wie dan? En bij wie niet? En wat is het verschil tussen de twee?

[PolarBear]

Bij Microsoft ga je dan meteen kwade dingen denken als "Zouden ze het expres doen om mensen te laten upgraden naar Windows 7?"

Microsoft heeft al jaren het Trustworthy Computing initiatief. En je ziet ook dat producten (zie bijvoorbeeld UAC in Vista en 7) steeds veiliger worden. Eastereggs zoals in Excel kom je niet meer tegen. Dus ik denk eerlijk gezegd niet dat ze het expres doen. Als ze echt iedereen massaal over willen hebben dan hadden ze de lifecycles van de OS'en wel verkort (8 jaar algemene support op Windows XP zonder SP is toch best ruim).

Raar verhaal dit, want lijkt me dat het maar in beperkte gevallen voorkomt. Maar bij wie dan? En bij wie niet? En wat is het verschil tussen de twee?

Er zal een verbindende factor zijn en er zal een bepaalde oorzaak zijn. Een combinatie van factoren die niet vaak voor komt. Dat is het moeilijke aan het achterhalen van dit soort bugs.

[Reactie gewijzigd door PolarBear op 24 juli 2024 02:55]

[Anoniem: 175233]

Dat is nou precies het probleem dat Microsoft ook heeft... Uitvoerig op allerlei hardware getest, en wanneer je het released, dan zijn er tóch nog gebruikers met problemen.

Waarbij dan de vraag is wat er bij hen dan aan de hand is, dat zij die problemen krijgen. En dat probleem hoeft niet eens bij Microsoft te liggen! Bijvoorbeeld drivers die dingen doen die eigenlijk niet mogen/kunnen, maar dat vóór de patch toevallig wel werkt, en dan na de patch problemen oplevert.

Er zijn in het verleden talloze voorbeelden geweest waarbij een correcte patch problemen in iets anders naar voren brengt. Natuurlijk geeft iedereen onmiddellijk de schuld aan de patch, maar dat hoeft dus helemaal niet zo te zijn.

[Hoite]

Bij dit soort dingen vraag ik me altijd weer af hoeveel ze testen voor het lanceren van zo'n patch, imo sta je als bedrijf toch goed voor lul als je met een patch 1 bug oplost en er weer 1 veroorzaakt.

[Rob Coops]

Ik denk dat er alleen bij een bepaalde aanroep van uit de 16bit dos box zo iets gebeurt. Iets wat heel erg moeilijk te testen zal zijn omdat je moeilijk alle mogelijke dingen kunt testen die een 16bit dos programma eventueel zou kunnen doen.
Dat dit niet gevonden is een een vrijwel niet gebruikte functie van het OS wat eigenlijk niets anders is dan een emulator voor een ander OS is natuurlijk niet heel erg vreemd.

Dat het hele OS over zijn nek gaat als een emulator stoute dingen doet is een heel ander verhaal. Maar iets dat inherent is aan het OS en iets dat totaal los staat van het oplossen van deze bug of niet.
Daarom lijkt het me eigenlijk alleen maar goed van Microsoft dat ze zelfs 17 jaar na dato nog problemen in hun OS kunnen oplossen, dat de oplossing kan leiden tot een crash is erg jammer maar niet iets wat je maar even op de Q&A afdeling kunt afschuiven.

[Wobblier]

Ik denk dat er alleen bij een bepaalde aanroep van uit de 16bit dos box zo iets gebeurt.

Nou, dat is wel een hele interessante aanname, Windows XP heeft geen 16 bits dos omgeving. Wel kent Windowx XP de NTVDM, een virtuele dos omgeving. Deze draait geheel binnen de 32 bits operating system. Ik zou het heel slordig vinden als de toch al niet zo heel compatible dos omgeving deze kan laten crashen.

Daarom lijkt het me eigenlijk alleen maar goed van Microsoft dat ze zelfs 17 jaar na dato nog problemen in hun OS kunnen oplossen, dat de oplossing kan leiden tot een crash is erg jammer maar niet iets wat je maar even op de Q&A afdeling kunt afschuiven.

In mijn optiek hadden ze het 16 jaar geleden al opgelost moeten hebben. Als je het zo bekijkt is inderdaad de MS Q&A zeker de schuldige.

Ik vind de berichtgeving wel een beetje stemming maken. Het bericht doet vermoeden alsof ze de bug 17 jaar geleden ontdekt hebben. Dat is waarschijnlijk niet het geval.

[SunnieNL]

16 jaar geleden al oplossen wordt wat moeilijk als 17 jaar na de 1ste release pas de bug wordt gevonden he..

[latka]

Ze hadden het in 2001 (meen ik) uiterlijk moeten vinden toen al het Microsoft personeel op security training werd gestuurd nadat gebleken wat dat Windows PCs op aan internet net zo'n goed idee was een klein kind een machinegeweer geven. Ze hebben toen beterschap en een volledige QA van Windows beloofd. Deze (en trouwens veel meer) is niet gevonden wat, mijns inziens, een aantal dingen bewijst:
1) Het was een marketing offensive, geen security offensive
2) Je kunt niet alle bugs vinden, ook niet met voldoende QA
3) Windows is een 'problem waiting to happen'

[MSalters]

Het probleem treed (ook) op bij het opstarten van XP. Dat gebeurt voordat de 16 bits programma's kunt starten. Dus nee, je vermoeden klopt zeker niet.

[wildhagen]

Tsja, het gebeurt zoals je kan lezen slechts bij enkele gebruikers, lang niet bij allemaal. Ik heb de patch op mijn workstation (met XP) ook geinstalleerd, en geen enkel probleem gehad.

Het is dus mogelijk een combinatie van heel veel verschillende factoren: bepaalde geinstalleerde software, drivers, specifieke hardware-modellen etc etc.

Testen is leuk, maar je kan nooit alle potentiele scenario's testen, dat zijn er miljoenen namelijk, dat is gewoon niet haalbaar.

Er zal t.z.t. neem ik aan wel een nieuwe versie van de update uitkomen.

[firefly112]

als je na gaat hoeveel verschillende hardware er is en software en daar alle combinaties mee moet gaan testen.
dat is het nadeel voor microsoft hun dat ze het nooit helemaal goed kunnen testen.

bij mac osx heb je het voordeel weg van de verschillende hardware want daar zijn er niet zo veel van.

[mjtdevries]

Dat wordt beter en meer getest dan jij in je stoutste dromen kan bedenken.

Maar als er een kans is van 1 op de miljoen dat het in een bepaalde configuratie fout gaat, dan vind je dat niet zo makkelijk in tests.

Maar er zijn dan wel voldoende mensen waarbij die kleine kans een probleem oplevert om een artikel op T.net te veroozaken.

[Madcat]

Lekker op tijd Maar beter laat dan nooit, XP wordt nog best wel veel gebruikt.
Maar betekend dat deze bug niet in windows vista en 7 is gefixed?

[Bor]

Lekker op tijd

De bug is niet al 17 jaar bekend maar is eind afgelopen jaar ontdekt. Heb je het artikel (en de bron) wel gelezen?

[Psilax]

zover bekend bij het grote publiek.

Uit eigen ervaring weet ik dat sommige software bedrijven goed genoeg weten waar een bug zit maar dit pas willen oplossen als er klanten problemen mee hebben om kosten uit te sparen.
Nu ga ik niet beweren dat dit bij microsoft het geval is voor deze bug, maar het is al eerder bekend dat ze sommige bugs pas willen erkennen en oplossen wanneer het een probleem is voor sommige klanten.

[CyBeRSPiN]

En wat voor de ene klant een bug is, is voor een andere een "undocumented feature"

[wildhagen]

Jawel, daar is hij ook gefixed, maar daar treed het probleem dus kennelijk niet op, het moet dus echt XP-specifiek zijn wat die BSOD veroorzaakt.

Overigens waren de 64-bits versies van Vista en 7 sowieso niet kwetsbaar omdat ze deze component (NTVDM) niet meer aan boord hebben, het gold dus alleen voor de 32-bits varianten.

[DanielG]

De bug is ook aanwezig in vista en win7 maar gelukkig is de patch ook uitgerold op deze systemen.

De BSOD's gebeuren zo te zien alleen bij XP.

[bzerk]

Wat ik interessant vind is dat kennelijk dezelfde bug in xp, vista en win7 zit. Dat maakt de marketing van MS (hele OS van de grond opnieuw ontworpen) net even iets minder geloofwaardig.

[Anoniem: 312055]

Ik vraag me bij dit soort dingen altijd af of de patch dan niet goed getest is of uberhaupt getest is.

[PolarBear]

Zie comment van Wildhagen hier boven. Foutloze software opleveren is nauwelijks haalbaar en commercieel gezien niet mogelijk. En dan nog zijn het sommige gebruikers, niet alle.

[Anoniem: 62763]

Ik werk zelf bij een softwarebedrijf, en we testen onze software altijd op wat het moet doen. Maar je zal altijd zien, dan belt er een klant die het voor elkaar krijgt de software te gebruiken op een manier waarvoor het niet bedoeld is, en ja... Dan kan er wel eens wat naar boven komen drijven.

[alt-92]

Is wel getest, hoor.
Alleen gaan ze niet voor jou testen wat er gebeurt als je $obscure-registrykey Everyone Full Control geeft terwijl er alleen SYSTEM op hoort te staan of een andere afwijking ten opzichte van de in-box aanwezige security templates.

Een onbekende of unsupported wijziging aan het systeem aanbrengen kan je soms in den kont bijten

[murderface]

myah, dit wordt dus wel ZEER uitvoerig getest maar laat ons eerlijk zijn... je kan dit niet testen en doen werken op ALLE PC's... kijk naar andere besturings systemen en je weet genoeg, MS test net heel goed hun updates (ik heb er nog nooit een ECHT fout zien gaan) net zoals op mijn mac, daar is ook nog nooit een update fout gegaan...

[Kriebelkous]

En dat terwijl mac eigenlijk verschrikkelijk in het voordeel is.
De hardwarecomonenten die in een mac zitten zijn verschillen alleen per model.
Daarmee wil ik zeggen dat Mac exact kan testen hoe een update reageert op alle systemen die ze ooit hebben uitgebracht. Er is geen wildgroei aan hardware bij mac systemen indien deze nog orgineel zijn.
Bij X86 systemen zijn miljoenen verschillende configuraties mogelijk, ik vind de frequentie waarmee dit soort dingen gebeurd bijzonder meevallen.

Je kan van MS ook niet verwachten dat ze kunnen of een update een conflict oplevert met je hasibashi racestuur of je high-end (bijna niet verkochte) raid controller.

[Finder]

Er worden een aantal zaken over het hoofd gezien:

- Dat Microsoft de keuze maakt om op zoveel systemen te draaien is een keuze van Microsoft. Als Microsoft niet in staat is om z'n OS stabiel genoeg te maken zouden ze misschien ook beter wat minder hardware ondersteunen. Trouwens dit is het grootste non-argument van alle pro-MS tweakers hier. UNIX, Linux, of OS/2 draaien op veel meer verschillende soorten hardware of architecturen dan Windows, en dat crashed niet. Zou het misschien komen omdat alle OS-en met uitzondering van Windows een goede driver- en systeem structuur hebben? Waarbij als een driver of zelfs de desktopomgeving crashed, het OS gewoon doordraait?

- Het kan ook een reden zijn dat MS zoveel 'oude code' in z'n OS steekt dat dat de boel onstabiel maakt. Ben nou eens eerlijk; wat doet 17 jaar oude DOS-code in een OS? Ookal is XP van 2001? Maak dan een deftige emulatielaag in je OS, zoals Rosetta of Classic bij OSX.

Zelfs Windows 7 blijft oude wijn in nieuwe zakken. Microsoft leert het nooit.

[mjtdevries]

UNIX, Linux, of OS/2 draaien op veel meer verschillende soorten hardware of architecturen dan Windows, en dat crashed niet.

Volslagen flauwekul. Ook Linux crashed keihard.

en OS/2 mag dan in naam zelden tot nooit crashen, maar het kon wel vrij makkelijk totaal unresponsive worden. Het SIQ probleem was net zo erg als een crash.

En dat een ander drivermodel een OS compleet onkwetsbaar kan maken voor crashes is ook totale onzin.
Per definitie moeten drivers hardware rechtstreeks kunnen aanspraken. En dat betekent per definitie dat je OS daardoor keihard kan crashen.

[hackerhater]

Echter zijn de enigste linux-crashes die ik hier in jaren gezien heb altijd te wijten geweest aan of een defecte systeems-schijf of aan een defect moederbord

Wat ik er ook op instaleerde of hoe zwaar ik het ook belaste

[Anoniem: 5760]

Kan ik de reeds geinstalleerde update niet gewoon deinstalleren als ik geen bsod krijg?

[pcgek]

Waarom zou je die willen deinstalleren als je er geen problemen mee hebt? volgens mij doet het probleem zich direkt voor na installatie.Als je nu geen BSOD krijgt,heb je er later ook geen last van. Ik heb er verder ook geen hinder van ondervonden trouwens.

[Pixeltje]

Het is natuurlijk onmogelijk om alle scenario's te testen, en naar mijn idee heeft Microsoft op deze manier vrij rap gereageerd met een workaround en een tool die het lek alsnog dicht.

[Anoniem: 80487]

Ja maar dat is in een netwerk natuurlijk gewoon kut.
Ik heb hem maar snel gedeclineerd gewoon om te voorkomen dat ik straks die workaround mag gaan doen bij 100 pc's. Is gewoon niet werkbaar.

[Kriebelkous]

Het lijkt me ook logisch dat wanneer ergens 100 systemen in een netwerk staan, er ook een systeembeheerder is die de automatische updates heeft uitgezet en eerst een update test voordat hij deze implementeerd. Als bedrijf (ik ga er even vanuit dat we het niet over een thuisgebruiker hebben die te veel geld heeft) kan je je ook niet permiteren om het anders te doen. Elke verandering aan een systeem kan nou eenmaal niet het effect geven wat je verwachte.

[Anoniem: 80487]

Euh, nofi maar met het update tempo van MS is het onmogelijk om alle minuscule updates in je netwerk te testen, dan ben je niet veel anders meer aan het doen als er in je eentje zit en ook nog met verschillende systemen hebt te maken. MS weet wat ze aanpassen MS moet de gevolgen die een patch heeft inzichtelijk kunnen maken.

De enige werkbare failsafe die ik heb ik gewoon updates later uitrollen en eerst even de kat uit de boom kijken, zoals nu ook weer.

[Reactie gewijzigd door Anoniem: 80487 op 24 juli 2024 02:55]

[Anoniem: 20531]

Microsoft test alle paches en software op 100den verschillende configuraties hiervoor hebben ze grote test ruimtes vol computers. Als je een beetje zoekt op channel9 kun je daar verschillende filmpjes en interviews over vinden.

Dat er dan nog af en toe wat fout gaat is niet gek. Windows draaid op zoveel verschillende configuraties en in combinatie met zoveel verschillende drivers en software. Het is niet gek dat het dan alsnog af en toe fout gaat.

[Faust]

dit probleem heeft helemaal niks te maken met of een computer een wacom tablet heeft, icm een epson printer driver etc.
Leuke spin, maar dit is toch echt een 'echte fout'

[wildhagen]

Dat weet je niet, het probleem kan best pas optreden als er een bepaalde combinatie van factoren aanwezig is, zoals bepaalde hardware, bepaalde specifieke drivers (of versies van drivers), in combinatie met 3rd party tools die wellicht bepaalde DLL's heeft vervangen etc etc.

Als het echt een fout in de patch zelf was geweest was die namelijk bij het testen wel naar voren gekomen. Dat testen gebeurt namelijk zéér intensief op honderden verschillende configuraties.

Maar dan nog is niet alles te voorkomen, aangezien Windows op miljoenen verschillende combinaties van hardware, software en drivers draait, wereldwijd gezien. Het is gewoon godsonmogelijk om dat allemaal te testen, dan ben je over 100 jaar nog bezig. Per patch dus.

[Anoniem: 20531]

Nee, tuurlijk zal het waarschijnlijk in dit geval niet aan je printer of wacom tablet liggen. Maar er zijn genoeg stukjes 3th-party software te verzinnen die wel intensief met je kernel samenwerken zoals beveilingssoftware/drivers. Het is goed mogelijk dat je door het patchen van een fout er een andere voor terug krijgt.

Punt is gewoon dat ze niet alle combinaties kunnen testen. En dat hierboven een aantal keer onterecht word geroepen dat het maar apen zijn bij MS.

[Rudedadude]

Er is dus nog niet achterhaald waardoor in sommige gevallen een bsod optreedt? (en weer heb ik een nieuwe afkorting geleerd )