Today we are pleased to announce the availability of the Enhanced Mitigation Experience Toolkit (EMET) version 2.0. Users can click here to download the tool free of charge. For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications. This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited. By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products. In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor. Below is a screenshot of the tool, which features a brand new interface as part of this release.
Today we are pleased to announce the availability of the Enhanced Mitigation Experience Toolkit (EMET) version 2.0. Users can click here to download the tool free of charge.
For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications. This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited. By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products. In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.
Below is a screenshot of the tool, which features a brand new interface as part of this release.
The installation package for EMET v2.0 includes a detailed user guide. A copy can also be found at the bottom of this post. It gives an overview of the tool, instructions on how to use it, answers to frequently asked questions, and caveats about the mitigations that users should be aware of. Please be sure to read the guide before using the tool. Additionally, the BlueHat team has helped us put together a training video on EMET v2.0. The video gives an even more in-depth look at some of the security mitigations offered by the tool. You can watch the video online here. To get more information on how this FREE tool can help you take advantage of the protections it offers please refer to our previous blog post announcing the upcoming release. That post also gives a rundown of all the changes that are new with the 2.0 version. As always, we welcome your feedback and would like to hear more about your experiences with EMET. Please feel free to e-mail us at switech@microsoft.com - Andrew Roths and Fermin J. Serna
The installation package for EMET v2.0 includes a detailed user guide. A copy can also be found at the bottom of this post. It gives an overview of the tool, instructions on how to use it, answers to frequently asked questions, and caveats about the mitigations that users should be aware of. Please be sure to read the guide before using the tool.
Additionally, the BlueHat team has helped us put together a training video on EMET v2.0. The video gives an even more in-depth look at some of the security mitigations offered by the tool. You can watch the video online here.
To get more information on how this FREE tool can help you take advantage of the protections it offers please refer to our previous blog post announcing the upcoming release. That post also gives a rundown of all the changes that are new with the 2.0 version.
As always, we welcome your feedback and would like to hear more about your experiences with EMET. Please feel free to e-mail us at switech@microsoft.com
- Andrew Roths and Fermin J. Serna
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:
1) Windows firewall is disabled2) 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- for XP http://www.microsoft.com/windowsxp/using/security/learnmore/sp2firewall.mspx
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.
Security Update MS12-020 addresses two vulnerabilities in Microsoft’s implementation of the Remote Desktop Protocol (RDP). One of the two, CVE-2012-0002, is a Critical, remote code execution vulnerability affecting all versions of Windows. This blog post shares additional information with the following goals:
Note that CVE-2012-0002 was privately reported and we are not aware of any attacks in the wild. Additionally, the remote desktop protocol is disabled by default. However, due to the attractiveness of this vulnerability to attackers, we anticipate that an exploit for code execution will be developed in the next 30 days.
We understand and appreciate that our customers often need time to evaluate and install bulletins as appropriate for their environment. For systems running RDP without Network-Level Authentication (NLA) enabled, this post includes information on a mitigation that may be applied in advance of the bulletin.
Pre-auth, network accessible, service running as SYSTEM
This issue is potentially reachable over the network by an attacker before authentication is required. RDP is commonly allowed through firewalls due to its utility. The service runs in kernel-mode as SYSTEM by default on nearly all platforms (except for one exception described below). During our investigation, we determined that this vulnerability is directly exploitable for code execution. Developing a working exploit will not be trivial – we would be surprised to see one developed in the next few days. However, we expect to see working exploit code developed within the next 30 days.
The good news is that the Remote Desktop Protocol is disabled by default, so a majority of workstations are unaffected by this issue. However, we highly encourage you to apply the update right away on any systems where you have enabled Remote Desktop.
Workaround option: Enable Network Level Authentication (NLA) on Windows Vista and later platforms
There is something you can do to substantially reduce the risk on Windows Vista and later systems where RDP is enabled: You can enable Remote Desktop’s Network Level Authentication (NLA) to require authentication before a remote desktop session is established to the remote desktop server. On systems with NLA enabled, the vulnerable code is still present and could potentially be exploited for code execution. However, NLA would require an attacker to first authenticate to the server before attempting to exploit the vulnerability.
You can find instructions to enable NLA interactively or via group policy at http://technet.microsoft.com/en-us/library/cc732713.aspx. We’ve prepared a one-click “Fix it” solution that takes a registry-based approach to enable NLA. It is a simple MSI package that enumerates each of the “listener” registry subkeys under HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations and sets the “UserAuthentication” REG_DWORD to 1. The links below enable and disable NLA:
Enabling NLA will prevent older clients (including Windows XP and Windows Server 2003) from connecting, by default. NLA will not disrupt remote desktop connections initiated by Windows Vista and later versions of Windows because they support NLA by default. If you need to initiate a remote desktop protocol connection to an NLA-enabled server from a Windows XP client, you can install support for Credential Security Support Provider (CredSSP) on each connecting Windows XP client. Instructions for doing so can be found here: http://support.microsoft.com/kb/951608. You can also use this one-click Fix it solution on Windows XP SP3 clients to enable support for NLA:
Platforms and scenarios at reduced risk
Just to reiterate, remote desktop is not enabled by default and is not commonly enabled on client workstations. Additionally, there are two common scenarios where remote desktop services could be enabled but on which the vulnerability poses reduced risk.
First, servers providing Terminal Services Gateway service are not directly vulnerable to this issue. The reason is that external users connect to the TS Gateway by using RDP encapsulated in RPC over HTTPS via port 443. The TS gateway computer removes the SSL encryption from the RDP traffic and then forwards the traffic to port 3389 of the destination computer on the internal network. The Terminal Services session is then established with that destination computer, not with the TS Gateway system.
The second scenario at reduced risk is Windows Server 2008 R2 SP1 servers using the Remote Desktop feature called RemoteFX. This is a common scenario in virtualized environments. This scenario is at reduced risk because the vulnerable code is running in user-mode (not kernel-mode) with NetworkService rights (not SYSTEM rights). While NetworkService privileges are less severe than executing code as SYSTEM, it would still grant attackers an unfortunate foothold in the network – so it would be a mistake to allow this reduced risk discussion to slow your rate of bulletin application.
We are actively engaged with our MAPP partners to build network-based detection and protection signatures for this issue. The nature of this particular vulnerability should allow for strong IDS and IPS protection. So an additional scenario leading to reduced risk is to have one’s systems behind a protection product from one of our MAPP partners who has built strong detection for this issue.
Conclusion
We urge you to promptly apply this security update. We also encourage you to consider how you might harden your environment against unauthenticated, attacker-initiated RDP connections. Please let us know if you have any questions that can help you speed your deployment. You can reach out to us at switech –at- microsoft –dot- com.
- Suha Can and Jonathan Ness, MSRC Engineering
As some of our readers are well aware, Conficker and other malware is taking advantage of the AutoRun functionality as a spreading mechanism. Furthermore, over the last couple of months, there has been a significant increase of this threat, as more malware is abusing this functionality. Further information about this specific threat has been highlighted in the recent Security Intelligence Report (look for Win32/AutoRun) and the Microsoft Malware Protection Center (MMPC) blog.
Background
Before going into the specifics changes, it is important to understand the difference between AutoRun and AutoPlay:
Changes
In order to help prevent malware from spreading (such as Conficker) using the AutoRun mechanism, the Windows 7 engineering team made two important changes to the product:
It is worth noting that some smart USB flash drives can pose as a CD/DVD drive instead of standard ones (see http://en.wikipedia.org/wiki/U3 for an example). In this specific scenario, the operating system will treat the USB drive as if it is a CD/DVD because the type of the device is determined at the hardware level.
For further information please visit the Windows 7 blog.
This change is available in the RC build of Windows 7.We are planning on making this change available on Windows Vista and Windows XP, so that the rest of our customers can benefit from these changes as well.
Thanks,
Damian Hasse – MSRC Engineering Blogger
References:
Updated on 4/28: Change text to "non-optical removable media" instead of "non removable optical media"
*Postings are provided "AS IS" with no warranties, and confers no rights.*
We are pleased to announce the release of a new version of our Enhanced Mitigation Experience Toolkit (EMET) - EMET 3.0. EMET it is a free utility that helps prevent vulnerabilities in software from being successfully exploited for code execution. It does so by opt-ing in software to the latest security mitigation technologies. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an update has not yet been applied. Download it here: http://www.microsoft.com/en-us/download/details.aspx?id=29851
This new version of the tool being released today addresses top feedback themes we have heard from users: EMET needs more enterprise configuration, deployment and reporting options. We have seen growing interest in adoption from enterprise and large scale networks and this new version includes enhancements for that segment. Here are some of the highlights of and new features in EMET 3.0.
Configuration
EMET 3.0 comes with three default "Protection Profiles". Protection Profiles are XML files that contain pre-configured EMET settings for common Microsoft and third-party applications. Under EMET’s installation directory, these files are in the
Deployment\Protection Profiles
folder. You can enable them as-is, modify them, or create new protection profiles based on them.
The three profiles that ship with EMET 3.0 are:
Looking inside a profile, we see a list of programs with EMET mitigations. The example below shows all EMET mitigations enabled for Windows Media Player, with the exception of Mandatory ASLR:
<Product Name="Windows Media player"> <Version Path="*\Windows Media Player\wmplayer.exe"> <Mitigation Enabled="false" Name="MandatoryASLR"/> </Version> </Product>
Notice the “*” in the Path attribute above? In EMET 3.0, we also expanded the EMET grammar rules. Existing rules that you might have continue to work as-is and it is possible now to also use wildcards in EMET rules. This means that you no longer have to use the full path of an application in EMET rules. You can use the “*” character or simply use the image name, such as “iexplore.exe” in your rules. EMET will protect them regardless of where these applications may be installed. This has been one of the most requested features.
Deployment
EMET also comes with built-in support for enterprise deployment and configuration technologies. This enables administrators to use Group Policy or System Center Configuration Manager to deploy, configure and monitor EMET installations across the enterprise environment.
For Group Policy: EMET includes an ADMX file that contains the three protection profiles mentioned above as policies that can be enabled/disabled through group policy. There is also a policy that demonstrates how to add custom EMET settings.
For System Center Configuration Manager: The SCCM team blog post this morning provides a package and instructions for integration with various SCCM features. Read that blog post here: http://blogs.technet.com/b/configmgrteam/archive/2012/05/15/deploying-and-configuring-the-enhanced-mitigation-experience-toolkit.aspx
Reporting
With EMET 3.0, we have included an additional new reporting capability that we call "EMET Notifier". When you install EMET 3.0, this lightweight component is set to automatically start with Windows. It will show up in the notification area of your taskbar with an EMET 3.0 icon.
EMET Notifier has two duties:
EMET events are logged via the event source called EMET. These logs can be found in the Application log. There are three levels: Information, Warning and Error. Information messages are used for logging usual operation such as the EMET Notifier starting. Warning messages are used when EMET settings change. Error messages are used for logging cases where EMET stopped an application with one of its mitigations, which means an active attack has been blocked. An example entry can be seen below.
In addition to the error messages written to the Windows Event Log, when an EMET mitigation stops (crashes) an application by blocking an exploit, a message is displayed for the user. A toast style taskbar notification states which application is being stopped and which mitigation is causing EMET to stop it. You can see an example below.
Other EMET v3 developments
In addition to these features, EMET 3.0 comes with a number of other improvements and bug fixes. More details and a FAQ can be found in the User Guide that comes with the install. However, we would like to specifically highlight a couple of things here.
First, we have tested EMET 3.0 on the Windows 8 Consumer Preview and it works great - we encountered no problems at all so we encourage you to use EMET on all versions of Windows. Second, EMET 3.0 can be installed just fine on a system where EMET 2.1 (the previous release) was already installed. An upgrade or a new installation is no different. Your existing rules built for EMET 2.1 will continue to work just fine with EMET 3.0. Third, we would like to point out that EMET is an officially-supported Microsoft tool. That is a question we get a lot from enterprise customers. Microsoft's Customer Service & Support team offers forums-based support via http://social.technet.microsoft.com/Forums/en/emet/threads. We in MSRC Engineering are also very eager to promote EMET and help you use it so we are quick to respond to feedback, ideas, suggestions, or questions via switech -at- microsoft -dot- com. Please do not hesitate to reach out to us.
Acknowledgements
I would like to thank Chengyun Chu, Elias Bachaalany, Elia Florio, Jinwook Shin, Neil Sikka, and Nitin Kumar Goel for their various contributions to this release. Also a big thank you to Jason Githens and Hema Rajalakshmi from the System Center Configuration Manager team for their help and support.
- Suha Can, MSRC Engineering
As you probably know there is a new exploit in the wild for Adobe Reader and Acrobat. This particular exploit is using the Return Oriented Programming (ROP) exploit technique in order to bypass Data Execution Prevention (DEP).
Normally Address Space Layout Randomization (ASLR) would help prevent successful exploitation. However, this product ships with a DLL (icucnv36.dll) that doesn’t have ASLR turned on. Without ASLR, this DLL is always going to be loaded at a predictable address and can be leverage by an exploit. In the below screenshot we use Process Explorer to show what this looks like.
Find more information on the importance of enabling ASLR in your products at http://msdn.microsoft.com/en-us/library/bb430720.aspx.
The good news is that if you have the Enhanced Mitigation Experience Toolkit 2.0 (EMET) enabled for AcroRd32.exe, it blocks this exploit. This is happens thanks to two different mitigations:
Mandatory ASLR: On Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 this mitigation will force the relocation of non ASLR-aware DLLs. The exploit will then fail to use ROP successfully since it is expecting the DLL to be at a predictable location. Take a look at the below screenshot from Process Explorer to see what this looks like.
Export Address Table Access Filtering (EAF): The exploit is also blocked by the EAF mitigation. This is important for Windows XP and Windows Server 2003 because they do not support mandatory ASLR. With this mitigation in place EMET will detect the shellcode accessing the EAT of Kernel32.dll trying to resolve some APIs (e.g. LoadLibraryA). EMET will then raise a STATUS_STACK_BUFFER_OVERRUN unhandled exception and the program will be terminated before the shellcode does anything bad.
In order to enable EMET for Adobe Reader and Acrobat you have to install EMET and run the following simple command line as an Administrator. Please note the path to the Adobe Reader and Acrobat could be different in your system (especially if you are not using a 64 bit system).
C:\Program Files (x86)\EMET>emet_conf.exe --add "c:\program files (x86)\Adobe\Reader 9.0\Reader\acrord32.exe"
The changes you have made may require restarting one or more applications
We have been working closely with the Adobe Secure Software Engineering Team (ASSET) on recommending EMET as a mitigation option. Due to the time-sensitive nature of this issue, we have only been able to perform a cursory look at the functional compatibility of this mitigation. Keep in mind, Adobe Reader and Acrobat support broad feature sets, which require extensive testing to fully cover all functionality. Therefore, we recommend that you also test the mitigation in your environment to minimize any impact on your workflows. Please refer to Adobe's guidance regarding EMET under the Mitigations section of their Security Advisory.
Also, last week we made available version 2.0 of EMET on this blog post. We would like to thank all the people that gave it a try it and sent us feedback. Today we are releasing an updated version of EMET (2.0.0.1) with some bug fixes. The download for the old version has been replaced with the new version and can be obtained here.
The following are the changes you can find in the new version:
- Fermin J. Serna and Andrew Roths
Updated September 14, 2010 - In certain Windows XP configurations, users have encountered problems where several applications configured for use with EMET do not get protected by EMET. When this happens you will see that the process does not have a check mark under the "Running EMET" column of the main application. If you have encountered this issue, please download the latest version of the tool which addresses this problem.
Our recent advisory describes an ASP.NET vulnerability which was recently publicly disclosed. This blog post will give you more information about the vulnerability and the workaround. It will also provide a script which will help you detect ASP.NET applications on your server that are in a vulnerable configuration.
The Impact of the Vulnerability
ASP.Net uses encryption to hide sensitive data and protect it from tampering by the client. However, a vulnerability in the ASP.Net encryption implementation can allow an attacker to decrypt and tamper with this data.
But what can the attacker do with this capability? Part of the answer depends on the ASP.Net application being attacked. For example, if the ASP.Net application stores sensitive information, such as passwords or database connection strings, in the ViewState object this data could be compromised. The ViewState object is encrypted and sent to the client in a hidden form variable, so it is a possible target of this attack.
If the ASP.Net application is using ASP.Net 3.5 SP1 or above, the attacker could use this encryption vulnerability to request the contents of an arbitrary file within the ASP.Net application. The public disclosure demonstrated using this technique to retrieve the contents of web.config. Any file in the ASP.Net application which the worker process has access to will be returned to the attacker.
How the Vulnerability Works
To understand how this vulnerability works, you need to know about cryptographic oracles. An oracle in the context of cryptography is a system which provides hints as you ask it questions. In this case, there is a vulnerability in ASP.Net which acts as a padding oracle. This allows an attacker to send chosen cipher text to the server and learn if it was decrypted properly by examining which error code was returned by the server.
By making many requests the attacker can learn enough to successfully decrypt the rest of the cipher text. The attacker can then alter the plain text and re-encrypt it as well.
The Workaround - Silencing the Oracle
The workaround for this vulnerability is to use the customErrors feature of ASP.NET to configure applications to return the same error page regardless of the error encountered on the server.
By following the steps in the advisory to map all error messages to a single error page, you make it difficult for the attacker to distinguish between the different types of errors, effectively limiting access to the oracle.
How to Detect Vulnerable ASP.Net Applications
Some ASP.Net applications may already be configured to return the same error page for all server errors. To detect ASP.Net applications that are not configured this way and need to have the workaround applied to them, use the following script:
Note: After installing the MS10-070 security update, the workaround is no longer necessary and there is no need to run this script.
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' ' DetectCustomErrorsDisabled.vbs Script ' Version 3.1 ' ' This script will help detect vulnerable configuration for the Padding Oracle ' ASP.Net vulnerability documented in MS advisory 2416728. ' ' http://www.microsoft.com/technet/security/advisory/2416728.mspx ' ' Usage: ' cscript DetectCustomErrorsDisabled.vbs [RemoteServerName] ' ' NOTE: THIS SCRIPT USES THE FILESYSTEM AND SHELL OBJECT AND SHOULD BE ' RUN AS AN ADMINISTRATOR ' ' The script works by enumerating all web.config and assessing if the ' side-channel leak for the padding oracle vulnerability is mitigated by the ' use of homogenizing custom error responses from ASP.Net applications. ' ' Note: On IIS 7 servers, this script requires IIS6 compatibility mode to be ' installed. ' ' More information on: http://blogs.technet.com/b/srd/archive/2010/09/17/understanding-the-asp-net-vulnerability.aspx ' ' Version History: ' 1.0 - Initial version ' 2.0 - Added additional checks for app/site root config ' 3.0 - Added error validation for XML parsing and path checks ' 3.1 - Added check for missing root web.config ' ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' OPTION EXPLICIT ON ERROR RESUME NEXT DIM strServer DIM objWebService, objWebServer, objDir, objFileSys DIM physicalPath, dir, xmlDoc, nodeList, node, ret DIM configFile, configFilePath, configLine DIM childNodes, ErrPage500, ErrPage404, errFound DIM index, errCount strServer = "localhost" ' Parse command line input ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' IF WScript.Arguments.Length=1 THEN strServer = WScript.Arguments( 0 ) END IF IF WScript.Arguments.Length>1 THEN WScript.Echo "Illegal number of arguments" WScript.Echo "Usage: cscript.exe DetectCustomErrorsDisabled.vbs [RemoteServerName]" WScript.Quit( 1 ) END IF ' Initializations ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SET objFileSys = CreateObject("Scripting.FileSystemObject") SET objWebService = GetObject( "IIS://" & strServer & "/W3SVC" ) IF Err <> 0 THEN WScript.Echo "Could not find IIS ADSI object. Make sure you have IIS and IIS6 management compatibility installed." WScript.Quit (1) END IF SET xmlDoc = CreateObject("Microsoft.XMLDOM") IF IsNull(objFileSys) THEN WScript.Echo "Failed to create FileSystemObject. Please run script as Admin." WScript.Quit (1) END IF IF IsNull(objWebService) THEN WScript.Echo "Failed to connect to IIS ADSI provider. Make sure you have IIS6 "_ + "management compatibility role service installed." WScript.Quit (1) END IF WScript.Echo("Enumerating possible paths with ASP.Net configuration that have" _ +" custom errors turned off.") WScript.Echo ("") ' Search web server for unsafe configuration ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' FindASPNetConfig(objWebService) ' Search all paths on web server for possible web.config files. ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SUB FindASPNetConfig(WebService) FOR EACH objWebServer IN WebService IF objWebserver.Class = "IIsWebServer" THEN EnumDirectories(objWebServer) END IF NEXT END SUB ' Recursively go through vdirs and webdirs ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SUB EnumDirectories(objDir) DIM objSubDir ' The first call to this is from IIsWebServer, so we can skip that FOR EACH objSubDir IN objDir IF (objSubDir.Class = "IIsWebVirtualDir") THEN GetPhysicalPaths(objSubDir) EnumDirectories(objSubDir) END IF NEXT END SUB ' Get physical paths for web and virtual directories ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SUB GetPhysicalPaths(objDir) physicalPath = objDir.Path CALL EnumWebConfig(physicalPath,1) END SUB ' Recursively search for web.config files. ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SUB EnumWebConfig(Path,IsRoot) IF NOT objFileSys.FolderExists(Path) THEN IF IsRoot THEN ' WScript.Echo Path & ": Site's disk path is incorrect and root web.config does not exist" WScript.Echo Path & ": ** Vulnerable configuration found **" END IF EXIT SUB END IF configFilePath = Path & "\web.config" IF objFileSys.FileExists(configFilePath) THEN CALL ProcessWebConfig(configFilePath,IsRoot) ELSEIF IsRoot = 1 THEN ' WScript.Echo Path & ": Site or app root web.config does not exist" WScript.Echo Path & ": ** Vulnerable configuration found **" END IF FOR EACH dir IN objFileSys.GetFolder(Path).SubFolders CALL EnumWebConfig(dir.Path,0) NEXT END SUB ' Skip known identities that will have Write access by default ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' SUB ProcessWebConfig(Path,IsRoot) xmlDoc.async="false" xmlDoc.load(Path) errFound = 0 SET nodeList = xmlDoc.getElementsByTagName("customErrors") IF IsRoot = 1 AND nodeList.length = 0 THEN ' Root web.config does not set defaultRedirect, so this config should ' have a customErrors section present with customErrors turned on and a ' defaultRedirect present. Else this is a vulnerable configuration. ' WScript.Echo path & ": Root web.config must have customErrors with defaultRedirect defined" errFound = errFound + 1 ELSEIF IsRoot = 1 THEN ret = CheckRootCustomErrorsSection(nodeList, Path) errFound = errFound + ret END IF DIM count FOR count=0 TO nodeList.length-1 ret = CheckCustomErrorsDisabled(nodeList.Item(count), Path) errFound = errFound + ret ret = CheckCustomErrorsAreHomogenous(nodeList.Item(count), Path) errFound = errFound + ret NEXT IF errFound > 0 THEN WScript.Echo Path & ": ** Vulnerable configuration found **" ELSE WScript.Echo Path & ": ok" END IF END SUB FUNCTION CheckRootCustomErrorsSection(xmlnodelist, path) errCount = 0 FOR index=0 TO xmlnodeList.length-1 ret = CheckRootCustomErrorsDisabled(nodeList.Item(index), Path) errCount = errCount + ret NEXT CheckRootCustomErrorsSection = errCount END FUNCTION FUNCTION CheckRootCustomErrorsDisabled(xmlnode, path) IF StrComp (LCase(xmlnode.getAttribute("mode")), "off") = 0 THEN ' WScript.Echo path & ": Custom Error disabled: " & xmlnode.xml CheckRootCustomErrorsDisabled = 1 EXIT FUNCTION ELSEIF IsNull(xmlnode.getAttribute("defaultRedirect")) THEN ' WScript.Echo path & ": defaultRedirect not set: " & xmlnode.xml CheckRootCustomErrorsDisabled = 1 EXIT FUNCTION ELSE CheckRootCustomErrorsDisabled = 0 END IF END FUNCTION FUNCTION CheckCustomErrorsDisabled(xmlnode, path) IF StrComp (LCase(xmlnode.getAttribute("mode")), "off") = 0 THEN ' Unsafe config ' WScript.Echo path & ": Custom Error disabled: " & xmlnode.xml CheckCustomErrorsDisabled = 1 ELSE CheckCustomErrorsDisabled = 0 END IF END FUNCTION FUNCTION CheckCustomErrorsAreHomogenous(xmlnode, path) IF xmlnode.childNodes.length=0 AND len(xmlNode.getAttribute("defaultRedirect"))>0 THEN CheckCustomErrorsAreHomogenous = 0 EXIT FUNCTION END IF SET childNodes = xmlnode.childNodes ErrPage404 = "" ErrPage500 = "" DIM count FOR count=0 TO childNodes.length-1 CALL GetErrorPage(childNodes.Item(count)) NEXT IF StrComp(ErrPage404,"") = 0 AND StrComp(ErrPage500,"") = 0 AND IsNull(xmlNode.getAttribute("defaultRedirect")) THEN ' Missing defaultRedirect in this case will cause config to be vulnerable 'WScript.Echo path & ": missing defaulRedirect URL: " & xmlnode.xml CheckCustomErrorsAreHomogenous = 1 EXIT FUNCTION ELSEIF StrComp(ErrPage404,"") = 0 AND StrComp(ErrPage500,"") <> 0 AND StrComp(ErrPage500, xmlNode.getAttribute("defaultRedirect")) <> 0 THEN 'WScript.Echo path & ": 500 and default error pages differ: " & xmlnode.xml CheckCustomErrorsAreHomogenous = 1 EXIT FUNCTION ELSEIF StrComp(ErrPage500,"") = 0 AND StrComp(ErrPage404,"") <> 0 AND StrComp(ErrPage404, xmlNode.getAttribute("defaultRedirect")) <> 0 THEN 'WScript.Echo path & ": 404 and default error pages differ: " & xmlnode.xml CheckCustomErrorsAreHomogenous = 1 EXIT FUNCTION ELSEIF StrComp(ErrPage404, ErrPage500) <> 0 THEN 'WScript.Echo path & ": 404 and 500 error pages differ: " & xmlnode.xml CheckCustomErrorsAreHomogenous = 1 EXIT FUNCTION ELSE CheckCustomErrorsAreHomogenous = 0 END IF END FUNCTION SUB GetErrorPage(xmlnode) IF xmlnode.nodeType <> 1 THEN EXIT SUB ELSEIF IsNull(xmlnode.getAttribute("statusCode")) THEN 'Do nothing. ELSEIF StrComp(xmlnode.getAttribute("statusCode"), "500") = 0 THEN ErrPage500 = xmlnode.getAttribute("redirect") ELSEIF StrComp(xmlnode.getAttribute("statusCode"), "404") = 0 THEN ErrPage404 = xmlnode.getAttribute("redirect") END IF END SUB
Many thanks to Levi Broderick, Nazim Lala, and Stefan Schackow for their contributions to this post.
-Kevin Brown, MSRC Engineering
Updated September 18, 2010
Made several improvements to the included script to catch additional corner cases and provide additional error handling. Clarified that an attacker can only retrieve files from within the ASP.Net application.
Updated September 21, 2010
Updated the script to add a check for missing root web.config files, and attached a zip of the script to the post so it can be downloaded directly.
Updated September 29, 2010
Added a note clarifying that the workaround and the detection script are no longer necessary once the security update has been installed. The security update is now available - please see MS10-070 for more information.
Today Microsoft revised the Workarounds section of Security Advisory 961051. We wanted to share more detail about the vulnerability and explain the additional workarounds here to help you protect your computers.
Information about the vulnerability
The vulnerability is caused by memory corruption resulting from the way Internet Explorer handles DHTML Data Bindings. This affects all currently supported versions of Internet Explorer. Malicious HTML that targets this vulnerability causes IE to create an array of data binding objects, release one of them, and later reference it. This class of vulnerability is exploitable by preparing heap memory with attacker-controlled data (“heap spray”) before the invalid pointer dereference.
Which workarounds should you apply?
The advisory now lists nine different workaround options. We have been adding additional workarounds with each advisory revision to give you more surgical options to cut off the vulnerable code path. Only IE8 has an option to turn off data binding altogether. So unless you are using IE8, you’ll need to:
The table below lists what type of protection each advisory workaround provides.
Applying a workaround from the (A) column will protect against current attacks but to comprehensively protect against the vulnerability, we recommend that you also apply a workaround from the (B) column.
Why list five different ways to protect against OLEDB data provider attack vector?
Let’s briefly touch on workarounds 3-7, each being a different way to protect against the OLEDB data provider attack vector.
6 & 7 –Unregister or Disable via ACL the OLEDB32.DLL
We listed these workarounds in yesterday’s advisory and they still remain viable options. However, these are two somewhat drastic options. All applications that rely on any part of this DLL will fail to function.
5 - Disable Row Position functionality of OLEDB32.dll
In our investigation, we discovered that disabling a single OLEDB32 COM object is enough to block access to the affected code path. We continue to list workaround options #6 and #7 in the advisory but #5 is actually far preferable because it is as good as either #6 or #7 and less invasive.
4 - Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL
This workaround option is another way to block access to the OLEDB data provider. The great thing about this option is that it blocks access for Internet Explorer only. It will not disrupt stand-alone data access applications. However, it only exists when UAC and IE Protected Mode are both enabled (default configuration) on Windows Vista and Windows Server 2008. We will go into more detail for this option below because it is pretty cool. :)
3 - Disable XML Island functionality
Exploits targeting the OLEDB data provider require msxml3.dll as well as OLEDB32.dll. We initially considered suggesting customers unregister or ACL msxml3.dll to block attempts to exploit the vulnerability. Blocking msxml3.dll system-wide turned out to break lots of stuff. However, disabling only the XML Data Island CLSID is enough to prevent msxml3.dll from loading only for IE for known attacks. Also, from our testing, it appears that not very many websites use the XML Data Island functionality so this is our least intrusive workaround from column A and it works on all supported platforms.
Further information about the Integrity Level ACL workaround
To provide this type of selective protection, the new workaround relies on the fact that, by default, Internet Explorer runs with Protected Mode turned on. This means that the iexplore.exe process runs at a low integrity level. For more information on what this means and how this works, refer to http://msdn.microsoft.com/en-us/library/bb250462.aspx. As mentioned in the article, the integrity mechanism makes it possible to block processes from being able to write to securable objects (such as files) that have a higher integrity level. One thing that the article does not mention, however, is that it is also possible to block a process from being able to read or execute securable objects at a higher integrity level. This is done by applying a special integrity level entry to the Access Control List (ACL) for an object. Later on in this post, we will walk you through how to do this for OLEDB32.DLL such that Internet Explorer cannot read or execute it.
One thing that should be noted about this workaround is that Internet Explorer must be running with Protected Mode turned on. This requires that both Protected Mode and User Account Control (UAC) are enabled (the default setting). You can determine whether or not Protected Mode is enabled by examining the Internet Explorer status bar as is illustrated in the following screenshot:
Enabling the Workaround (only applies to Windows Vista and later operating systems)
To use this workaround you must first create a temporary directory and then copy an inf file from the attached zip file to it. Use the BlockAccess_x86.inf file if the underlying operating system is 32 bit and the BlockAccess_x64.inf file if the underlying operating system is 64 bit. If you are unsure which operating system you are using, you can figure it out by opening the Control Panel and selecting System. Look for the following output in the resulting window.
Once you have the appropriate file copied over, start an elevated Administrator command prompt, navigate the prompt to the temporary directory, and run the following command where <inf> is the name of the file you copied to the directory.
SecEdit /configure /db BlockAccess.sdb /cfg <inf>
After running the command, you should see the following output.
The task has completed successfully. See log %windir%\security\logs\scesrv.log for detail info.
SecEdit will also create a file called BlockAccess.sdb in the directory it was run from. You can safely delete it and the inf file.
Validating the Workaround
It is possible to use the icacls command to quickly determine whether or not the workaround has been applied. If you are using a 32 bit operating system, you just need to run the following command:
icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"
On the other hand if you are using a 64 bit operating system, you will need to run icacls twice; once for the 32 bit version of OLEDB32.DLL and once for the 64 bit version. The two commands are as follows:
icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll" icacls "%ProgramFiles(x86)%\Common Files\System\Ole DB\oledb32.dll"
Each time you run icacls, search through the output for the following line.
Mandatory Label\Medium Mandatory Level:(NW,NR,NX)
If the line is present and includes both the NR and NX values, the workaround has successfully been applied. However, if either the line is missing, or one of the NR or NX values is missing, the workaround has NOT been successfully applied.
Undoing the Workaround
To undo the workaround, you will once again need to create a temporary directory and copy an inf file from the zip into it. This time you will need to copy UnblockAccess_x86.inf if you are using a 32 bit operating system and UnblockAccess_x64.inf if you are using a 64 bit one. After copying the file, start an elevated Administrator command prompt, navigate to the temporary directory, and run the following command where <inf> is the name of the file you copied to the directory.
SecEdit /configure /db UnblockAccess.sdb /cfg <inf>
You should see the same output as before and similar to last time, you can safely delete the UnblockAccess.sdb and UnblockAccess.inf files.
Let us know if you have any questions.
Update Dec 13, 2008: Added "Disable XML Island Functionality" workaround.
- Andrew Roths, Jonathan Ness, Chengyun (SVRD Bloggers)
(Special thanks to Neil Carpenter for helping out on this blog post)
Beginning late last year, a number of websites were defaced to include malicious HTML <script> tags in text that was stored in a SQL database and used to generate dynamic web pages. These attacks began to accelerate in the first quarter of 2008 and are continuing to affect vulnerable web applications.
The web applications compromised share several commonalities:
This represents a new approach to SQL injection (http://msdn.microsoft.com/en-us/library/ms161953.aspx). In the past, SQL injection attacks were targeted to specific web applications where the vulnerabilities and the structure of the underlying database were either known or discovered by the attacker. This attack differs because it has been abstracted such that it is possible to attack virtually any vulnerability that is present in an ASP page creating dynamic SQL queries from URI query strings. Additional technical details and a walkthrough of the specifics are available at http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx.
This attack does not exploit vulnerabilities in Windows, IIS, SQL Server, or other infrastructure code; rather, it exploits vulnerabilities in custom web applications running on this infrastructure. Microsoft has investigated these attacks thoroughly and determined that they are not related to any patched or 0-day vulnerabilities in Microsoft products. More information can be found at http://blogs.technet.com/msrc/archive/2008/04/25/questions-about-web-server-attacks.aspx.
As indicated above, these attacks have been accelerating through the year. This would appear to be related to at least two factors. First, there is a malicious tool that is in the wild that automates this. SANS discusses that tool here -- http://isc.sans.org/diary.html?storyid=4294. The tool uses search engines to find vulnerable sites to SQL injection.
The second factor is that one or more malicious bots are now launching SQL injection attacks as a way of spreading the bot further. SecureWorks discusses an example at http://www.secureworks.com/research/threats/danmecasprox/.
Once a server has been defaced using this attack, it will begin including a malicious <script> tag pointing to a .js file. While the contents of these files differ, they all attempt to exploit various vulnerabilities including already-patched Microsoft vulnerabilities and vulnerable third-party ActiveX controls. Since these scripts are hosted independently, it is possible that the scripts can be changed rapidly to exploit new client vulnerabilities and can be easily tailored to target on a “per browser” basis.
There are a number of things that IT administrators and database administrators should do to limit risk and respond to possible incidents on the code and infrastructure they manage:
Since this exploit takes place via the URI query string, administrators can review IIS logs to find anomalous queries that may be attempts to exploit this. Information on how to do this manually is available at http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx. A sample of an automated tool is available at http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=WSUS&ReleaseId=13436.
If IIS logs show that the server has possibly been exploited, the next step would be to inspect tables in databases that are used by the associated web applications, looking for <script> tags appended to cells in text columns.
NOTE: IIS servers should never run in production with logging disabled. While the storage and administration requirements of IIS logging can be significant, the lack of IIS logs makes it very difficult to respond to security incidents.
In cases where 3rd party ASP web applications are being used, administrators should contact the application vendors to ensure that they are not susceptible to SQL injection attacks.
Administrators should make sure that the SQL users that the web application uses have the least privilege necessary. Web applications should never connect as users with administrative privilege such as “sysadmin” at the server level or “db_owner” at the database level. The white paper “best practices for setting up and maintaining security in SQL Server 2005” http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc provides recommendations for various aspects of SQL server security.
There are several good documents on how Web developers can prevent SQL injection attacks when writing code. Since these attacks leverage vulnerable web application code, the only way to completely prevent them is to resolve vulnerabilities in the code. Any place that the code dynamically generates a SQL query using data from an external source (and, particularly, from a URI query string) should be considered suspect. Once code vulnerabilities are identified, they need to be carefully resolved.
http://msdn.microsoft.com/en-us/library/bb671351.aspx
Also, the above document contains a pointer to the following article “How To: Protect From SQL Injection in ASP.NET” http://msdn.microsoft.com/en-us/library/ms998271.aspx (which still applies to ASP)
A very useful video can be found here (this is the video refer on the previous article, but that link is currently broken): http://channel9.msdn.com/wiki/default.aspx/SecurityWiki.SQLInjectionLab
http://msdn.microsoft.com/en-us/library/ms161953.aspx
http://msdn.microsoft.com/en-us/library/cc676512.aspx
How to call SQL Server stored procedures from ASP:
http://support.microsoft.com/kb/q164485
Michael Howard covers those topics in http://blogs.msdn.com/sdl/archive/2008/05/15/giving-sql-injection-the-respect-it-deserves.aspx
Also, Writing Secure Code 2nd has good guidance on how to prevent these type of attacks as well (see pages 399-411)
Part 1: http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx
Part 2: http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx
Nazim from the IIS team explains how to do the filtering in detail here: http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx
If you are still not sure where to start, all web code that accesses a database with a particular focus on ASP code and areas of code which use user-supplied data should be review first.
End users should review the information at http://www.microsoft.com/protect/default.mspx; in addition, here are some specific steps that you can take to protect yourself.
While responsible browsing limits your exposure to vulnerability, it is possible that even websites you trust may have been compromised. Watch for unusual behavior, be aware of the risk, and implement the other recommendations in this section.
Since the malicious scripts are exploiting known vulnerabilities, you should make sure that you are running the latest Microsoft and 3rd party security updates. Microsoft security updates are available via http://update.microsoft.com. Additional information is available at http://www.microsoft.com/protect/computer/updates/OS.aspx.
You should disable any unneeded ActiveX controls and add-ons in Internet Explorer. To do this on Windows XP Service Pack 2 or later, follow these steps from KB883256 (http://support.microsoft.com/kb/883256):
1. Start Internet Explorer. 2. On the Tools menu, click Manage Add-ons. 3. Click the name of the add-on. 4. Use one of the following methods: • Click Update ActiveX to replace the add-on with the current version. This option is not available for all add-ons. • To enable an add-on, click Enable, and then click OK. • To disable an add-on, click Disable, and then click OK.
You may have to restart Internet Explorer for the changes to take effect after you enable or disable an add-on.
For earlier operating systems, follow the instructions in KB154036 (http://support.microsoft.com/kb/154036).
If you are using an Internet browser other than Internet Explorer, you should ensure that you have installed the latest security updates and that you disable unneeded extensions and add-ons. Information for popular browsers can be found at:
Firefox - http://support.mozilla.com/en-US/kb/Firefox+Support+Home+Page Opera - http://www.opera.com/support/ Safari - http://www.apple.com/support/safari/
End users should ensure that they have anti-virus and anti-spyware software installed and that it is up to date. More information can be found at http://www.microsoft.com/protect/computer/antivirus/OS.aspx and http://www.microsoft.com/protect/computer/antispyware/OS.aspx. You can get a 90-day trial copy of Windows Live OneCare anti-virus/anti-spyware software at http://onecare.live.com/standard/en-us/install/install.html.
- Security Vulnerability Research & Defense Bloggers
Blog Update - June 2, 2008: Updated above url to "http://contoso.com..."
It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the first part of a three-part FAQ we have developed to answer some questions around the Kill-Bit and related functionality.
The Kill-Bit FAQ – Part 1 of 3
What is the Kill-Bit?
The Kill-Bit (a.k.a. “killbit”) is not actually a bit. The Kill-Bit is a registry entry for a particular CLSID that marks the COM object / ActiveX control referenced by that CLSID as non-loadable in the browser and other scriptable environments. Microsoft releases Kill-Bits in security updates to block vulnerable ActiveX controls and COM objects which are vulnerable to security flaws when hosted in the browser.
Issuing a Kill-Bit for the control marks that particular control as forbidden to instantiate in the browser. Issue a Kill-Bit by setting the Compatibility Flags value to 0x400 for a control in the registry as described in KB Article 240797.
Where are Kill-Bits in the registry?
Kill-bits are located in the registry: x86 IE / x86 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
x64 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
x86 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
(3/11/2009 Update: added detail on x86 / x64 scenarios)
Warning - Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Modify the registry at your own risk.
Note that not all CLSIDs listed in this location are killed, only controls containing 0x400 in the Compatibility Flags DWORD value. The acceptable values for Compatibility Flags are documented here. If you are setting a Kill-Bit, you may want to ensure that you don’t wipe out any existing Compatibility Flags set for the CLSID being killed. If you are removing a CLSID, to preserve any pre-existing Compatibility Flags, subtract 0x400 from the Compatibility Flags DWORD value and only remove the CLSID key if the Compatibility Flags value was set to 0x400 exactly.
What applications respect the Kill-Bit?
The Kill-Bit is respected in Internet Explorer (all zones) and also in Microsoft Office scenarios where objects are embedded within documents. The Kill-Bit should also be effective by default in any other application or platform that hosts the IE browser’s rendering engine (MSHTML). A notable exception are HTAs – with an HTA it is already possible to load unsafe controls and run arbitrary code. HTAs are an unsafe file type.
(3/11/2009 Update: HTAs do currently respect the Kill-Bit for objects instantiated via the OBJECT tag. The Kill-Bit is not respected when HTAs instantiate objects in script. Thanks to Nicolas Noakes for reporting this. The Kill-Bit behavior within HTAs may change in the future to become more consistent.)
A control could conceivably have a flaw so severe that a Kill-Bit does not effectively block all attack vectors. For example, imagine a control that is found to implement a web server which suffers from a buffer overrun in the code responsible for parsing web requests. In this case, a code fix must be issued – simply implementing a Kill-Bit will not provide a comprehensive solution because any application which uses the control is exposed to the vulnerability.
If an application or platform hosts controls and allows those controls to effectively be driven by untrusted data, that environment should respect Safe for Scripting, Safe for Initialization and Kill-Bit logic. Otherwise, the environment should provide some other equivalently or more restrictive policy, such as an allow-list of known-good scriptable objects.
Why does my vulnerable control / object need a Kill-Bit?
Kill-Bits must be issued to prevent old / vulnerable signed versions of controls from being effectively foisted on users. Even if a user has a fixed version of the control on their system, a renamed / signed DLL or OCX served from a malicious web page could revert their machine to an insecure state.
Additionally, the “Always trust content from…” checkbox on the Authenticode dialog box, if checked for a particular trusted publisher, could allow old / vulnerable signed versions of controls to install silently. Otherwise, the victim of such an attack would be presented with an Authenticode dialog from a presumably trustworthy publisher. Once the old / vulnerable control is installed, the attacker can immediately script to it.
Kill-Bits are effective regardless of their origin but obviously wider distribution of a Kill-Bit ensures more comprehensive protection. If you would like Microsoft to distribute a Kill-Bit in Windows on your behalf, contact the MSRC and include details on the CLSID(s) in question.
What is the relationship between an OBJECT tag’s CLSID and CODEBASE attributes?
It is possible to specify any CLSID paired with any CODEBASE in an OBJECT tag. If that CLSID isn’t already registered, IE will attempt to download the control specified in the CODEBASE attribute of the OBJECT tag. It isn’t feasible for IE to know what control a package installs before that package is actually installed.
Will controls with the Kill-Bit still load in other applications?
Yes. See “What applications respect the Kill-Bit?” above.
Is it still possible to download and install an ActiveX control with the Kill-Bit?
Yes. Setting the Kill-Bit on a control only affects that control’s ability to instantiate within Kill-Bit aware hosts such as IE.
Updates March 11, 2009 - updated blog post and flagged where updates were made.