When security breaks things

  • Article

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.

The bulletin
Vulnerabilities in MSDTC and COM+ could allow remote code execution
https://www.microsoft.com/technet/security/bulletin/ms05-051.mspx
https://support.microsoft.com/kb/902400

The problems
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
https://support.microsoft.com/kb/909444

What you shouldn't be doing
Security configuration guidance support: "File system and registry access control list modifications"
https://support.microsoft.com/kb/885409/#XSLTH4173121122120121120120

Other stuff you shouldn't be doing
Client, service, and program incompatibilities that might occur when you modify security settings and user rights assignments
https://support.microsoft.com/kb/823659

Re-enabling TIP
How to configure MSDTC transaction Internet protocol functionality after you install security update 902400
https://support.microsoft.com/kb/908620

Comments

  • Anonymous
    January 01, 2003
    Yesterday I mentioned that there's no substitute for doing your own testing of updates. I mentioned virtualization

  • Anonymous
    November 08, 2005
    The comment has been removed

  • Anonymous
    November 09, 2005
    The comment has been removed

  • Anonymous
    November 09, 2005
    SCE won't work in this way without initially having a template that reflects the default ACLs, which you'll first need to remember to create after you initially build a system. And be sure to use the right command switches. SCE /GENERATEROLLBACK -- the switch that seems to be the one to use -- compares the computer's current state with a template you specify and generates a "rollback" template which you can then use to undo the new template. But /GENERATEROLLBACK doesn't support file and registry permissions. Better would be to use SECEDIT /EXPORT /MERGEDPOLICY /CFG <filename>.INF which captures the system's complete current state into a brand new template, including ACLs.

  • Anonymous
    November 09, 2005
    The comment has been removed

  • Anonymous
    November 09, 2005
    Ah. Seems I used the wrong link before; my bad. Here's the proper 'return to security defaults' link:

    http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/dd766d48-ed09-45a3-aa5e-cf0a64a7fb88.mspx

  • Anonymous
    November 09, 2005
    Ah yes, there is the hammer otherwise known as "setup security.inf." The important bit to remember is to specify the /REGKEYS and /FILESTORE switches so that only the permissions are reset, and not reapply all the default settings in the entire template.

  • Anonymous
    November 10, 2005
    Hello,

    It would be nice to know precisely what Microsoft test on in terms of systems. This includes applications installed on those systems as well - oftentimes, the impact of installing a patch to the OS has unforseen consequences on apps which run on that system.

    So, what apps do you test OS patches with, please? E.g. Office XP, Office 2003, what 3rd party apps etc.

    This info would be really useful for our own testing plans.

  • Anonymous
    November 10, 2005
    If additional changes takes away urgent need of patching of every "Black Tuesday" why i should not do it? Those changes are done because of need of keeping data safe.

  • Anonymous
    November 10, 2005
    Patch program executes

    Examine prevailing permissions in/under %WINDIR% folder and compare with required set

    If permissions in/under %WINDIR% folder are suitable apply patch and then exit

    else display message to screen referring to permissions issue and stop process

  • Anonymous
    November 10, 2005
    Patch program executes

    Examine prevailing permissions in/under %WINDIR% folder and compare with required set

    If permissions in/under %WINDIR% folder are suitable apply patch and then exit

    else display message to screen referring to permissions issue and stop process

  • Anonymous
    November 11, 2005
    I came here from Jesper's blog. While it may not be good to mess with the ACLs of operating system files, and it is impossible to test combinations of ACLs thoroughly, it is still not an excuse for addressing the issues when they do arise. Humans are not the only things that change ACLs. Software can do it as well.

  • Anonymous
    November 11, 2005
    That's a good point, Brant. Simply put, no third-party software should ever change ACLs in %WINDIR%. I'm not sure whether this now part of the logo requirements, so I will check. I do know that logoed software is no longer allowed to store user info in the HKLM registry hive or write to %WINDIR%, would be good to add the no-ACL-change requirement if it isn't already there.

  • Anonymous
    January 03, 2006
    There's one thing you probably didn't test: how the patch (MS05-051) behaves when applying it to a XP installation CD (slipstreaming it). I'm used to building an automatic unattended installation cd with XP SP2 and all possible updates.

    It's a great way to install new workstations, I even have Office 2003 and Adobe CS2 installing on one single go.

    MS05-051 breaks the installation CD completely, which probably has something to do with the ACL , which might not be "compatible" when applying this hotfix with a "slipstreaming" method.

    I'm assuming that slipstreaming hotfixes into installation media should is supported, since MS provides instructions on how to do it and every hotfix has switches which make is possible. Am I wrong?