Wednesday, 25 August 2004

I knew something was bugging me...

The Register: Windows XP SP2 features security crater - report

Basically, a malicious program can add a new WMI provider to the root\SecurityCenter namespace - an instance of AntiVirusProduct or FirewallProduct. Windows XP SP2's Security Center may then report that an anti-virus product or firewall product is installed and working correctly, even when one is not.

The mitigation, though, is that WMI is indeed read-write - for Administrators. PC Magazine's original article (attributed to eWeak by The Register's pet hack) makes this clear.

I was thinking along the lines of changing the ACL on this namespace so that only LocalSystem is able to create new providers, but failed since the ACLs are inherited - but you can't clear the inheritance in the MMC WMI Control snap-in (it's in the Computer Management console). However, this would only add a small hindrance since by default on XP SP2, at.exe still exists and still allows you to do

at 23:39 /interactive cmd

to get a command interpreter running as LocalSystem:

Process primary token
This is a unrestricted token
Token type: primary
Token ID: 0x25066b9
Authentication ID: 0x3e7
Token's owner: BUILTIN\Administrators (alias)
Token's source: *SYSTEM* (0x0)
Token's user: NT AUTHORITY\SYSTEM (user)
Token's primary group: NT AUTHORITY\SYSTEM (user)

(dumptoken from

This only works if you're an administrator, of course.

And if you think about it, most WMI providers get registered with WMI by an installer, running as an administrator. I'm not too sure about the default ACL for the root namespace which allows Everyone to modify provider information, though.

Anyway, what's the point of misreporting the firewall or antivirus status? A program running using a token containing the Administrators group SID (or, loosely, running as an administrator) can punch a hole in the firewall using the firewall administration API - how many users will regularly check the list of exceptions? It can normally install a device driver. It could install a file-system filter driver below the anti-virus filter driver in the disk driver stack and remove any trace of its own code (you'd probably need to add another one above to add the code back in so it could run).

The true mitigation, as for most things, is to run as a regular user. Don't run as a member of the Administrators group.


Anonymous said...

Critics are reaching for SP2 holes. Like that somehow makes them brilliant, and makes MS look dumb. Ah well.

In other news, giving someone your password will let them access your computer. Even with SP2 installed.

Biggus said...

The trouble is that BY DEFAULT, if your average consumer buys an XP machine the account they create will be an administrator. Nothing during the "Welcome" setup procedure makes any mention of there even being different types of user, let alone that it's making you create a user that you shouldn't actually run as.

Combine this with the fact that XP Home is limited to the far-too-granular Admin/Limited user types (without recourse to command line utilities, which are no use to your average user), and that some apps will break if not run as an admin user (unless you want to take the time and use regmon/filemon and fiddle around for hours), you'll find that without a great deal of education, 99% of XP users will be running as admin WITHOUT KNOWING.

As SP2 is touted as super secure, and much has been made of the Security Center, unless people are told they need to create additional user accounts and to treat the Security Center results with a pinch of salt, it may actually make things worse. I can almost hear the cries of "but Security Center said I was safe!"