Privilege escalation vulnerability affects Windows Vista SP1, XP

It is the type of vulnerability that Microsoft wanted to head off as long as possible, especially since Windows Vista's new kernel was designed to thwart this possibility.

Now, as the company acknowledged in a security bulletin yesterday, a malicious program running as a local or network service can leverage another local or network service running in the same system, to elevate its own privilege and potentially cause damage.

As of early Friday evening, there was no known exploit for this vulnerability, and thus security firm Secunia has given it a "less critical" rating. The nature of Microsoft's report today indicates that it may have been alerted to the problem by a security engineer who discovered a proof of concept, though no credit has yet been given.

It would be a very sophisticated exploit, and if it were tested in the field, the likelihood of it causing damage would appear to be low...unless a separate malicious payload were somehow crafted to ensure the running status of one network service, in order to leverage it to elevate its own privilege, and then use that privilege to execute a second payload. Unfortunately, Microsoft's bulletin admits, SQL Server and Internet Information Services -- two widely used network services -- are among the network services that could conceivably be leveraged in such an attempt.

Even more unfortunate is the news that Windows Server 2008, in the 32-bit and 64-bit as well as Itanium-based editions, are susceptible, as well as Windows Server 2003 SP2 -- server systems where those two network services would most likely be implemented. Windows Vista with Service Pack 1 and Windows XP Professional with Service Pack 2 are also on the list.

Three suggested workarounds for the problem, in a sense, offer more insight into the nature of the problem itself: They all involve IIS 6.0 or 7.0, and instruct administrators to create a worker process identity for application pools to utilize a specially crafted, privileged account -- apparently one that cannot be leveraged. They then suggest that admins disengage the Distributed Transaction Coordinator, which would presumably disable network transactions from services not added to the pool. Microsoft warns that doing this will likely increase system overhead and slow down execution.