This morning we released MS09-012, an update to address the publicly-disclosed issue commonly referred to as Token Kidnapping (http://www.argeniss.com/research/TokenKidnapping.pdf). This vulnerability allows escalation from the Network Service account to the Local System account. Normally malicious users are not running as Network Service, except for a very few programs like IIS, where arbitrary code can be executed within a service running as Network Service. This allows malicious users to attack and gain control of Windows.
Am I vulnerable?
This issue affects scenarios where untrusted code is being executed within a process owned by the Network Service account, or within processes having the SeImpersonatePrivilege. The publically discussed attack is via malicious Full Trust ASPX code hosted within an IIS worker process. Normally untrusted users aren’t allowed to add web content to an IIS website, but some web hosts explicitly offer hosting for 3rd party web content. You can read more about the risk in a previous SRD blog entry here: http://blogs.technet.com/srd/archive/2008/10/13/service-isolation-explanation.aspx
Addressing this issue required one of the most epic engineering efforts we have ever expended for a Microsoft security update. This security update changed parts of the Windows kernel; the COM, DCOM, and LSASS subsystems; the WMI and MSDTC built-in services; and the service control manager (SCM). We had to back-port much of the service token work implemented in Vista and Server 2008 down to XP and Server 2003. Some of our most senior developers and architects devoted time away from Windows 7 development to address this issue down-level. (Security updates are typically fully handled by the Sustained Engineering team.) The changes made were in sensitive parts of the OS which required some delicate re-architecture work to avoid application compatibility issues, which took a long time to plan and develop. Then we wanted to be absolutely sure we wouldn’t break anything after changing these core pieces of the Windows architecture so this update went through rigorous testing to iron out the issues testing uncovered. Only now is it finally ready to be released.
We’d like to answer a few questions you might have about this security update.
Why are there multiple different CVE’s being addressed in this update?
To address this issue system-wide, we actually needed to fix four separate vulnerabilities. You can see more detail about each of the separate CVE’s below.
CVE-2008-1436 for MSDTC:
One of the issues publically identified was a flaw in MSDTC. It was asking for too much permission when creating an RPC connection. A higher privilege token would then be created in the process calling RPC allowing that process to elevate and execute as the Network Service account. This update addresses the issue by having MSDTC ask for less permissions when creating the RPC connection so the user’s process doesn’t receive this higher privilege token.
CVE-2009-0079 for RPCSS:
The second piece which needed updating involved the security permissions given to various services running as the Network Service account. This update backports a subset of Vista’s Service SID functionality, discussed here by Mark Russinovich (http://technet.microsoft.com/en-us/library/cc748650.aspx); thus this update is not applicable in Vista and Windows Server 2008. This helps prevent services running as Network Service from attacking the RPCSS service. Additionally it lays the framework for future services to be opted into the Service SID functionality should the need arise on these older versions of Windows. All services were not configured to run with a Service SID down-level due to application compatibility concerns and technical limitations.
CVE-2009-0080 for the Thread Pool:
The third issue brought up was an attack which would cause a new thread to be created in a given process. This thread wouldn’t require the proper permissions to open it, which created this possibility for attack. The fix was to harden the permissions required to access the thread.
CVE-2009-0078 for WMI:
And finally, WMI previously ran Network Service and Local Service providers without any protection from other processes running under the same account. The WMI changes use technology based from Vista’s Service SID functionality to protect WMI providers with a WMI SID. Third parties will need to evaluate their WMI providers and opt into this functionality if applicable.
In the upcoming release of Windows 7 and Windows Server 2008 R2 systems, a new feature named Managed Service Accounts (http://technet.microsoft.com/en-us/library/dd367859.aspx) has been introduced which creates a more streamlined and flexible solution to the issues surrounding service isolation. It provides for services, which have opted to use the feature, the ability to run as a separate account which remotely authenticates with a managed domain SPN. It also provides seamless and automatic password management, similar to the computer account, which frees up time that administrators would previously have used to update user account passwords for these services. You can read more about creating Managed Service Accounts here http://technet.microsoft.com/en-us/library/dd548356.aspx.
– Nick Finco, MSRC Engineering
*Postings are provided “AS IS” with no warranties, and confers no rights.*