When security breaks things
Now that the furor has waned, I want to comment on MS05-051. For those of you who don't memorize bulletin numbers (I am part of that set; Susan Bradley, for example, isn't, hehe), this is the security update that fixed a number of vulnerabilities found in MSDTC and COM+; it replaced five other updates dating back to 2003. On Windows 2000 it also disables MSDTC TIP beause this functionality generally isn't needed.
Shortly after we released the bulletin, some customers began experiencing problems. The media got wind of this, and in typical fashion blasted Microsoft for "yet another broken patch." KB909444 describes typical symptoms (see the end of this post for resources). Sure enough, we've intentionally made life more difficult for you yet again. We just love doing that, I tell ya!
Um, no. That's a silly accusation, reflective of immature thought. Look: would any organization purposefully do things to drive its customers away? Ok, I guess I wasn't thinking about airlines here, but that's another matter. Microsoft strives to make it easier for you to bring technology to improve your business, not to get in the way. Security bulletins are part of helping you keep your business running.
Security guidance is another part. And for some time now, we've been recommending a particular thing about guidance: don't change the defalt ACLs on the operating system's files and registry entries. The default permissions on Windows XP and Windows Server 2003 are a whole lot tighter than they were on Windows 2000. While it was necessary to make several modifications on that older operating system, current operating systems don't require any modifications, despite what several well-meaning third-party security guides might claim. KB885409 discusses many issues surrounding questionable guidance; make sure you consult this before you implement the recommendations of any guidance.
What happened specifically with MS05-051? Some security guides recommend changing the default ACLs throughout the %WINDIR% folder. These modifications affect the security changes implemented in the MS05-051 update. If you left the ACLs alone, then the MS05-051 update operates properly on your computer. But if you made changes, and put more restrictive permissions on %WINDIR%\registration, then the update appears to break the system because it actually can't function properly now. KB909444 describes the symptoms, the problem, and the resolution: restore the default permissions on that folder.
Better, restore (if you can) the default permissions on the entire %WINDIR% tree and seriously rethink the guidance. Consider this bit from KB885409, written over a year ago in August 2004:
Microsoft Windows XP and Microsoft Windows Server 2003 have considerably tightened system permissions.... Because of these changes to the core operating system of Windows XP and of Windows Server 2003, extensive changes to file permissions on the root of the operating system are no longer required.
Additional ACL changes may invalidate all or most of the application compatibility testing that is performed by Microsoft. Frequently, changes such as these have not undergone the in-depth testing that Microsoft has performed on other settings. Support cases and field experience has shown that ACL edits change the fundamental behavior of the operating system, frequently in unintended ways. These changes affect application compatibility and stability and reduce functionality, both in terms of performance and capability.
Because of these changes, we do not recommend that you modify file system ACLs on files that are included with the operating system on production systems. We recommend that you evaluate any additional ACL changes against a known threat to understand any potential advantages the changes may lend to a specific configuration. For these reasons, our guides make only very minimal ACL changes and only to Windows 2000. For Windows 2000, several minor changes are required. These changes are described in the Windows 2000 Security Hardening Guide.
Extensive permission changes that are propagated throughout the registry and file system cannot be undone. New folders, such as user profile folders that were not present at the original installation of the operating system, may be affected. Therefore, if you remove a Group Policy setting that performs ACL changes, or you apply the system defaults, you cannot roll back the original ACLs....
To help you remove the worst results of such file and registry permissions, Microsoft will provide commercially reasonable efforts in line with your support contract. However, currently, you cannot roll back these changes. We can guarantee only that you can return to the recommended out-of-the-box settings by reformatting your hard disk drive and by reinstalling the operating system.
For example, modifications to registry ACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the ACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can only guarantee that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.
Reformatting and rebuilding your production server is the ultimate destabilizing activity! (Also commonly known as an RGE: a resume-generating event.) There's no substitute for testing updates yourself, on your own systems (virtualization is your friend here). We test all updates thoroughly, including on systems configured according to our own published security guidance. But there's no way we can test all permutations of all third-party guides. Resist the urge to tweak every security setting just because it's there. Sometimes the defaults are good enough, and in the case of the file system and the registry, good enough really is exactly what you need.
Vulnerabilities in MSDTC and COM+ could allow remote code execution
Systems that have changed the default access control list permissions on the %WINDIR%\registration directory my experience various problems after you install the Microsoft security bulletin MS05-051 for COM+ and MSDTC
What you shouldn't be doing
Security configuration guidance support: "File system and registry access control list modifications"
Other stuff you shouldn't be doing
Client, service, and program incompatibilities that might occur when you modify security settings and user rights assignments
How to configure MSDTC transaction Internet protocol functionality after you install security update 902400