After watching this thread fill my inbox the last few days, I couldn't let it 
die before jumping in with my own opinion. It is an interesting series of 
events here: Microsoft issues a patch, it breaks some systems, broken patches 
get lots of media attention, Microsoft people defend themselves saying that the 
default permissions are good enough you shouldn't be messing with them, which 
brought on a discussion of default permissions and security guides, among other 
things.

The question is if this is an issue of a buggy patch or an issue of reckless 
admins over-hardening their systems and then just blaming Microsoft? I think it 
is a bit of both.

Microsoft certainly cannot anticipate and test every possible configuration 
change that customers might make. The patches undergo a significant amount of 
testing and their careful patch testing and release plan is better than it has 
ever been. But was this a foreseeable scenario that should have been tested? 
Should they have anticipated ACL problems? I read in MSKB 909444 that 
"...Before Microsoft Security Bulletin MS05-051, explicit permissions to the 
COM+ catalog were not required." Reading that, I would suspect that if you make 
a change that requires explicit permissions that you should anticipate that 
anything besides the default permissions might cause problems. I think they 
could have anticipated issues here to have warranted a more detailed test plan 
and should not have relied so much on beta testing to have found any issues.

And they should have anticipated that people will change default permissions. 
You can't just say that the default permissions are good enough or that you 
should have just followed our guides. Many people, including myself, spend a 
lot of time establishing extreme hardening strategies that go far beyond the 
widely-available security guides. In my opinion, it was at least a partial 
failure in testing because it was probably something that they should have 
foreseen, but likely a mistake they won't make again.

Having said that, I certainly don't think that people are wrong for hardening 
beyond the guides but if you do that you can't be blaming Microsoft if your 
server breaks. Windows security is complex and you need to understand what you 
are doing, especially when you venture out doing things like changing 
permissions in %WINDIR%. If you are going much beyond a standard configuration, 
you should expect to have to test things more than other people, especially for 
patches in a server environment. If you use COM+ or MSDTC and you see a patch 
that affects this, and you know that you have changed file permissions that you 
probably didn't understand, you too are partially at fault. Perhaps if you got 
burned this time you won't ever make that mistake again. Perhaps.

Sure, it would be great if Microsoft could anticipate and test every 
foreseeable configuration but it is reasonable to expect a few mistakes. Just 
learn from them. Experimenting with security is good and Microsoft should 
encourage that and not use default configurations or security guides as an 
excuse. That could be very dangerous if that attitude starts catching on over 
there. Microsoft's default permissions on Windows 2003 are a great improvement 
and their security guides are very good. But advanced Windows security 
configurations are complex and time consuming. It would be nice for Microsoft 
to do more, but I personally think that is an area where the security community 
could also contribute more. There is a vast universe to explore just in 
%WINDIR% alone.

Windows 2003 is pretty secure out of the box, but just for today's threats. We 
need to start work on defending against tomorrow's threats. The issues with 
MS05-051 are something that none of us likes to see. We just have to make sure 
it doesn't turn into a complacency of relying on default permissions just to be 
safe. I can guess that we will see documents published a decade from now 
recommending not to change permissions under %WINDIR% just because of this 
issue.


Mark Burnett












---------------------------------------------------------------------------
---------------------------------------------------------------------------

Reply via email to