Service isolation explanation

The past few days, we have had service isolation on our minds here in Redmond after the POC code posting last week from Cesar Cerrudo. Nazim Lala from the IIS team posted a great blog entry about the fix and why it is taking so long to release it. I expect it to be close to the amount of code churn as XP SP2. We’re backporting a huge amount of infrastructure work from the Vista servicing hardening effort back down-level. It’s really a monumental amount of work for a security update. Nazim’s blog entry goes into more detail.

But I wanted to make sure everyone knew what set of customers are at risk. I think Cesar outlined it pretty well but just to recap: an attacker would need to be executing code in the context of a Windows service to use this exploit. More precisely, an attacker needs the SeImpersonatePrivilege privilege in their token in order to start the privilege escalation.

IIS is a good attack vector in scenarios where a hosting provider hosts untrusted code. Cesar also points out the SQL Server scenario where a SQL DBA has admin rights to the database but not on the machine running the database. There might be other attack vectors as well. You can investigate any potential attack vectors in your scenario by checking the token in any process running code from untrusted sources. The easiest way to do so is via Process Explorer. Double-click on any running process and click the “Security” tab to see the options. Here are a couple examples.

Svchost running as NETWORK SERVICE:

cmd.exe running as an unprivileged user:

To recap, the vulnerable scenario is as follows:

1 – Process token has SeImpersonatePrivilege privilege
2 – Process is running at privilege level less than SYSTEM (otherwise, no escalation)
3 – Process runs untrusted code or allows untrusted users to execute code

If your network fits this criteria, we strongly encourage you to review Security Advisory 951306 and apply the workarounds listed.

- Jonathan Ness, SVRD Blogger

*Postings are provided “AS IS” with no warranties, and confers no rights.*