No! No! You release patches to fix the operating system, not to crash the operating system!
Posted by DeLong at February 05, 2003 05:15 PM | TrackbackMicrosoft pulls patch that crashes NT: Microsoft has pulled a security patch for Windows NT 4.0 because installing it can cause the operating system to crash, the software maker said Monday.
The patch, released on Dec. 11 last year, is to fix a privilege elevation vulnerability deemed "important" by Microsoft. A malicious user could gain administrative privileges on a system by exploiting a flaw in the WM_TIMER Windows function, Microsoft said in security bulletin MS02-071.
However, some system administrators were confronted with random crashes and reboots on their NT 4.0 systems after installing the patch. The problem was solved by removing the patch, according to postings about the issue in online discussion groups.
Also, one user complained of trouble using Windows NT 4.0 Terminal Server. When a user was signed off using Terminal Server Administrator, their processes showed as still running. This was also resolved by removing the security patch...
Variations on this theme are one reason why so many computer systems go unpatched: even if a vendor patch doesn't break the vendor's own code, there's no guarantee that it won't crash or corrupt a customer's program written to work with the vendor's code.
Companies trying to run a business often have system administrators wrestling with application support and development to be allowed to apply patches. It's hard to make a well-grounded business decision about patching when you have no estimate of either the likelihood of an attack using a bug or the likelihood of loss of business due to a patch breaking something apparently unrelated.
At the employee level it's almost a no-brainer: if I say yes to this patch and it breaks something, my job is on the line, but nobody can blame me if an outsider attacks us, especially since we have to keep costs low and not waste money on a test environment for patches.
this sort of thing happened routinely, well before Microsoft even existed.
IBM's mainframe operating systems of the 70's and 80's (MVS, VSE and VM) routinely shipped patches (called APAR's) some of which resulted in crashes when installed.
having contributed to some of these directly, i can say with considerable authority that it is almost impossible to 'patch' a complex operating system time and time again without screwing up *some* of the time.
Posted by: Suresh Krishnamoorthy on February 6, 2003 10:40 AMOpen source software projects usually catch on to problems like this right away, since serious developers, administrators, and users often check the underlying code to make their systems work better with it.
With Microsoft software I have often needed to set up days and days of testing with thousands of tests to tease out underlying design and philosophy of supposedly "documented" systems. Mostly that was thanks to the seriously bad design of systems other than NT, but the trouble persists in certain modules. With that kind of opacity and secrecy and the interdependences underlying it it's no surprize that Microsoft can't build a decent patch.
And no surprize that open source systems release good patches quickly and reliably that work.
Of course, closed source Opera has a design methodology that allows them to build really good patches also. And Microsoft routinely violates sound principles like keeping the changes minimal with each patch, so closed source is far from their only problem.
And remember that the recent MS SQL worm, the latest Microsoft disaster to hit the internet, was patched six months ago. But also remember that subsequent patches removed the original patch and resotred the bug. Anyone running an up-to-date server was totally vulnerable. That's a reflection of simple bad engineering practice and lack of care but all too typical of MS.