Windows Vulnerabilities - 92% mitigated by not being administrator

I'm going to step aside from my normal patching discussions and talk about what happens when you do get attacked with malware that exploits a vulnerability. When a nasty program exploits an unpatched vulnerability, there are always mitigating factors that can help limit the impact. One of the big ones is that the exploit usually runs in the security context of the account which it attacks/is run against. Security vendor BeyondTrust looked at the 154 Microsoft vulnerabilities published in 2008. They found that 92% of all vulnerabilities had their impact mitigated or were rendered completely harmless when the user was running with no elevated privilege (normal user rights). Obviously this is a report from a security vendor selling software that helps manage user rights... but the breakdown for 2008 is striking, indicating that running as non-administrator at least mitigates:

• 94% of Microsoft Office vulnerabilities reported in 2008
• 89% of Internet Explorer vulnerabilities reported in 2008
• 53% of Microsoft Windows vulnerabilities reported in 2008

That makes sense when you realize that the first two categories are just applications. They're very specialized, widespread and extensible applications, hence the risk. Ultimately, however, they're running at the user's privilege level. Even though the OS itself is somewhat less protected-- many of the juicier exploits will run at the System context or elevate privileges-- 53% mitigation is still pretty good.

Here's my beef with Microsoft in this regard. We all know that running in the least level of privilege is the safest and these numbers add good ammunition to that argument. While Microsoft has made great strides in allowing the user to elevate their privilege on some actions in the "XP era" and later, getting the ability to universally change security context on the fly eludes them. *nix with sudo and the standard GUI security elevation method of OS X both have serious problems, but they're a lot closer to right. Windows 7 will certainly continue the slow progress in this area, but at some point Microsoft ought to do better.

Remember MS08-067? It's baaaack (Conficker A)

And this time, it's bringing a worm. At this point, the estimate of infected systems is at around 8 million according to F-Prot. I've not seen an infection yet myself, knock on wood, but considering:

A.) That there was more than enough warning with Microsoft flailing their arms over a serious out-of-band patch on 10/23/2008, plus at least one, probably two Patch Tuesdays since the patch was released.

B.) This worm only spreads over corporate and local networks -- networks that are supposed to be managed by professionals.

The numbers are disheartening to say the least.

--

Edit: Microsoft has a helpful portal for this worm. Ars Technica also has a great article, quoting an infection rate of around 1.1 million PCs for the last 24 hours.

Another Out Of Band MS08-078

This is going to be short as it's already covered well elsewhere and this is late... Microsoft has another out-of-band patch as of 12/17, MS08-078 affecting all versions of IE on all supported OSes except Server 2008 for IA-32/x64. Zero-day exploits are already going on. Get this one patched ASAP.

I'd normally say "use Firefox" or some other browser whenever possible, but Firefox and Opera are also currently suffering vulnerabilities. Firefox 3.0.5 resolves the issues. While not quite as sever as the zero-day exploit on IE, these are noteworthy as cross-platform.

Windows: Vulnerability MS08-067

I don't normally beat the dead horse with Windows patch news, but this one is bad. Microsoft released an out-of-band patch this morning with MS08-067.

This vulnerability affects all current shipping Windows versions, with worm-style propagation being a very real likelihood. Versions of Windows 2000 and XP Pre SP2 are highly vulnerable, with some XP SP2+ and Windows Server 2003 systems being exploitable under certain common/popular firewall conditions.

Vista and Server 2008 appear to be exploitable, but only in terms of a DDoS type attack. Remote Code Execution has not yet been shown on a Vista system.

As of 12:30 PM Pacific Time, Microsoft reports attacks in the wild. This could be the next Blaster/Sasser type attack, so get patching!

Admin Basics: One, Some, Many

As I write this post, we're on the eve of a date Windows admins are painfully familiar with: Patch Tuesday. Microsoft releases scheduled updates on the 2nd Tuesday of each month and because of this predictable schedule, Admins can take all the actions necessary to ensure that these patches are delivered in a timely manner. I'll defer talking about patch automation until a later date, but for now I'll take this opportunity to talk about my first Admin Basics topic: One, Some, Many.

When taking any action on a computer, there's always some risk that the change you make will break something or have other unintended consequences. You can try to predict what will happen, and you can have rigorous testing, but the chances are that something may fail and that something may not be what you test for. When making larger changes, the chances of something going wrong are greater than for a trivial change.

This leads me to the concept of One, Some and Many. This ties nicely into patching, but applies to all system changes.

You know you're going to make a change. You know it might have negative consequences. You test it as best you can-- how can you limit your risk beyond that?

Simple: Push the change to a single system first and test. If it works, then the chances are reasonable that the change had no negative effects. From there, pick a representative sample of other systems and push that change to them... and wait. If none of the users report problems, you can then push out to a larger group. If you're running a very large group of systems, you may have several groups of "many" for various reasons. If you have a smaller number of systems, you can probably safely patch them all in one big group of "many." If you start to get failures, you can go back to the previous stage and test more rigorously with the new failure information.

Why do this?

1. Vendors can't test every possible scenario, and often patches, updates, and configuration changes are poorly tested.

2. While you have a responsibility to test changes, you will have a hard time testing every scenario. It's efficient to have some users test as well.

3. The risk exposure is lower: If users experience problems in the "some" phase, you've limited the number of people having problems and enhanced your ability to troubleshoot quickly. If nothing else, you can back out their updates and go back to the previous testing step.

If you execute the One, Some, Many strategy you can still make changes in a reasonable period of time but lessen the risk. It's a very bad feeling when you make a sweeping change and your users start screaming. This will help you not be that guy.