Today Microsoft released a security update that fixes a remote code execution vulnerability in the Windows Server Service. This is a serious vulnerability and we have seen targeted attacks using this vulnerability to compromise fully-patched Windows XP and Windows Server 2003 computers so we have released the fix “out of band” (not on the regular Patch Tuesday). Due to the serious nature of the vulnerability and the threat landscape requiring an out-of-band release, you probably have questions about your own organization’s risk level, what actions you can take to protect yourself, and why newer platforms are at reduced risk. We hope to answer those questions in this blog post.
Which platforms are at higher risk?
An unauthenticated attacker can trigger this vulnerability remotely for code execution on Windows Server 2000, Windows XP and Windows 2003. By default, Windows Vista and Windows Server 2008 require authentication. However, the attacker must be able to reach the RPC interface to exploit the vulnerability. In the default out-of-the-box scenario, the interface is not reachable due to the Windows firewall enabled by default on Windows XP SP2, Windows Vista, and Windows Server 2008. Unfortunately, either one of the following two conditions exposes the RPC endpoint:
- Windows firewall is disabled
- Windows firewall is enabled but file/printer sharing is also enabled.
When File/Printer Sharing is enabled on Windows Vista and Windows Server 2008, the Windows firewall only expose the RPC interface to the network type shared. For example, if a printer is shared on a network type ‘Private’, the Windows firewall will block incoming RPC connections if the computer switches over to a network type ‘Public’. If you then choose to share the printer on the network type ‘Public’, Vista and Windows Server 2008 will prompt to ask if you really want to enable “File and Printer Sharing” for ALL public networks.
For more information about file/printer sharing, visit the following URLs:
- for Vista http://technet.microsoft.com/en-us/library/bb727037.aspx
The following picture illustrates the risk for each platform in more detail.
More about mitigations (DEP, ASLR, /GS)
On Vista and Windows Server 2008, the combination of Address Space Layout Randomization (ASLR, http://blogs.msdn.com/michael_howard/archive/2006/05/26/address-space-layout-randomization-in-windows-vista.aspx) and Data Execution Protection (DEP, http://support.microsoft.com/kb/875352/EN-US/ ) will make the exploitation of this vulnerability more difficult. ASLR will randomize the base address of modules, heaps, stacks, PEB, TEBs, etc. making difficult the return into known locations. Known DEP bypass techniques will not be applicable on these platforms because of the presence of ASLR.
Regarding /GS protection, the stack frame of the function that contained the overflowed buffer was protected with a stack frame boundary cookie. However, due to the nature of this particular vulnerability, the exploit code is able to take advantage of another stack frame that was not meant to be protected by the /GS security cookie. The /GS security cookie is only emitted for functions meeting certain criteria.
UAC mitigates even when the prompting is disabled
As mentioned above, Windows Vista and Windows Server 2008 by default require authentication. But the security callback on the RPC interface has not been changed on the more recent platforms. Instead, the UAC and integrity level hardening work introduced with Vista is forcing the authentication requirement. The anonymous user connects with integrity level “Untrusted” while the named pipe requires at least a “Low” integrity level. Since “Untrusted” is lower than “Low” integrity level, the access check fails. Note that disabling the UAC prompt does not disable the integrity level access check. In other words, regardless of whether the UAC prompt is enabled or disabled, the integrity level check will be performed. The integrity level check will fail on Vista and Windows Server 2008 if the user connects anonymously. See http://msdn.microsoft.com/en-us/library/bb625963.aspx for more information.
There is a non-default scenario where a non-domain-joined Windows Vista and Windows Server 2008 can be exploited anonymously. If the feature “Password Protected Sharing” is disabled, anonymous connections come in at “Medium” integrity level. Because “Medium” integrity level is a higher integrity level than “Low”, the integrity level check will succeed. This would allow Windows Vista and Windows Server 2008 to be exploited anonymously. This feature could be disabled through Vista’s Network Sharing Center in the “Sharing and Discovery” section.
Most perimeter firewalls will block exploit attempts from outside your organization
If you are behind a perimeter firewall that filters inbound connections to TCP ports 139 and 445, you will not be reachable from the Internet. This is a common home user scenario. In this scenario, only the machines in your local LAN will have the ability to exploit this vulnerability.
How you can protect yourself
You should apply the security update as soon as you can. This is the best way you can protect yourself. While you are testing the update and preparing your deployment process, you may choose to use one or more of the workarounds listed in the security bulletin. (http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx) We have researched several options that range from turning off the affected component to limiting the exposure to authenticated users.
There is one other workaround option that we didn’t include in the bulletin because it is not a supported scenario. The Server service exposes the vulnerable code over an RPC named pipe. The access control list for the named pipe is specified in the netapi32.dll code. It can be changed for any current Windows session. When Windows is rebooted, the ACL will get reset to the default value. However, if you were to change the ACL on every boot after the service is started, the window of attack for anonymous users would be very small. We have developed a simple tool that can remove the ANONYMOUS access control entry is the named pipe’s access control list. (Please remember that this is not a supported scenario.) Here’s what it looks like when run:
C:\>chacl.exe \\.\pipe\srvsvc
opening up \\.\pipe\srvsvc
Got back 3 ACE entries
Found an entry for ANONYMOUS LOGON. Deleting it...
deleted that ACE
Setting new DACL changes...
Done
C:\>chacl.exe \\.\pipe\browser
opening up \\.\pipe\browser
Got back 3 ACE entries
Found an entry for ANONYMOUS LOGON. Deleting it...
deleted that ACE
Setting new DACL changes...
Done
We have attached the chacl.c source code at the bottom of this blog post.
Greetz
A great deal of investigation in a short amount of time went into this case. We’d like to publicly thank all the engineers who helped provide definitive answers (some requiring hours of debugging) to these hard technical questions.
- Bruce Dang, Fermin J. Serna, Damian Hasse, Andrew Roths and Jonathan Ness from the SVRD team
- Matt Miller and other members from the Microsoft Security Engineering Science Team
- David Kruse from the core filesystem team
- Tassaduq Basu and Raghu Gatta from the Windows Networking team
- Jon Schwartz from the Windows kernel team
- Carlos Trueba Salinas from the Windows Sustained Engineering team
Posting is provided “AS IS” with no warranties, and confers no rights.