This past weekend we have alerted you about a vulnerability present in Internet Explorer 6, 7, and 8 which has already been used in limited targeted attacks. Later versions of Internet Explorer (9 and 10) are not affected by this issue. As always, we recommend upgrading to the latest available. For those who are constrained to older versions, today we are providing a Microsoft "Fix it" solution designed to reduce the attack surface of this vulnerability.
This code-signed, one-click deployable Microsoft “Fix it” package uses the Windows application compatibility toolkit to make a small change at runtime to mshtml.dll every time Internet Explorer is loaded. For more details, you can refer to our previous blog post. You can apply this workaround by running the Microsoft Fix it 50971 from the link below. For enterprise deployment, please refer to Knowledge Base article 2794220, section “Deploying an application compatibility database across multiple computers”.
Applying this workaround will not interfere with the installation of the final security update that will address this issue. However, applying the workaround will have a small effect on the startup time of Internet Explorer. Therefore, as you are applying the final security update, you should uninstall the workaround as it will no longer be needed.
- Cristian Craioveanu, MSRC Engineering
DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) have proven themselves to be important and effective countermeasures against the types of exploits that we see in the wild today. Of course, any useful mitigation technology will attract scrutiny, and over the past year there has been an increasing amount of research and discussion on the subject of bypassing DEP and ASLR [1,2]. In this blog post we wanted to spend some time discussing the effectiveness of these mitigations by providing some context for the bypass techniques that have been outlined in attack research. The key points that should be taken away from this blog post are:
In a previous blog post series we went into detail on what DEP is and how it works[part 1, part 2]. In summary, the purpose of DEP is to prevent attackers from being able to execute data as if it were code. This stops an attacker from being able to directly execute code from the stack, heap, and other non-code memory regions. As such, exploitation techniques like heap spraying (of shellcode) or returning into the stack are not immediately possible.
The effectiveness of DEP hinges on the attacker not being able to 1) leverage code that is already executable or 2) make the attacker's data become executable (and thus appear to be code). On platforms without ASLR (that is, versions of Windows prior to Windows Vista), it is often straightforward for an attacker to find and leverage code that exists in modules (DLLs and EXEs) that have been loaded at predictable locations in the address space of a process. Return-oriented programming (ROP) is perhaps the most extensive example of how an attacker can use code from loaded modules in place of (or as a stepping stone to) their shellcode [3,1]. In addition to loaded modules, certain facilities (such as Just-In-Time compilers) can allow an attacker to generate executable code with partially controlled content which enables them to embed shellcode in otherwise legitimate instruction streams ("JIT spraying")[2].
The fact that modules load at predictable addresses without ASLR also makes it possible to turn the attacker's data into executable code. There are a variety of ways in which this can be accomplished, but the basic approach is to use code from loaded modules to invoke system functions like VirtualAlloc or VirtualProtect which can be used to make the attacker's data become executable.
Summary: DEP breaks exploitation techniques that attackers have traditionally relied upon, but DEP without ASLR is not robust enough to prevent arbitrary code execution in most cases.
Attackers often make assumptions about the address space layout of a process when developing an exploit. For example, attackers will generally assume that a module will be loaded at a predictable address or that readable/writable memory will exist at a specific address on all PCs. ASLR is designed to break these assumptions by making the address space layout of a process unknown to an attacker who does not have local access to the machine. This prevents an attacker from being able to directly and reliably leverage code in loaded modules.
The effectiveness of ASLR hinges on the entirety of the address space layout remaining unknown to the attacker. In some cases memory may be mapped at predictable addresses across PCs despite ASLR. This can happen when DLLs or EXEs load at predictable addresses because they have not opted into ASLR via the /DYNAMICBASE linker flag. Prior to Internet Explorer 8.0 it was also possible for attackers to force certain types of .NET modules to load at a predictable address in the context of the browser[6]. Attackers can also use various address space spraying techniques (such as heap spraying or JIT spraying) to place code or data at a predictable location in the address space.
In cases where the address space is initially unpredictable an attacker can attempt to discover the location of certain memory regions through the use of an address space information disclosure or through brute forcing[5]. An address space information disclosure occurs when an attacker is able to coerce an application into leaking one or more address (such as the address of a function inside a DLL). For example, this can occur if an attacker is able to overwrite the NUL terminator of a string and then force the application to read from the string and provide the output back to the attacker [4]. The act of reading from the string will result in adjacent memory being returned up until a NUL terminator is encountered. This is just one example; there are many other forms that address space information disclosures can take.
Brute forcing, on the other hand, can allow an attacker to try their exploit multiple times against all of the possible addresses where useful code or data may exist until they succeed. Brute forcing attacks, while possible in some cases, are traditionally not practical when attacking applications on Windows because an incorrect guess will cause the application to terminate. Applications that may be subjected to brute force attacks (such as Windows services and Internet Explorer) generally employ a restart policy that is designed to prevent the process from automatically restarting after a certain number of crashes have occurred. It is however important to note that there are some circumstances where brute force attacks can be carried out on Windows, such as when targeting an application where the vulnerable code path is contained within a catch-all exception block.
Certain types of vulnerabilities can also make it possible to bypass ASLR using what is referred to as a partial overwrite. This technique relies on an attacker being able to overwrite the low order bits of an address (which are not subject to randomization by ASLR) without perturbing the higher order bits (which are randomized by ASLR).
Summary: ASLR breaks an attacker's assumptions about where code and data are located in the address space of a process. ASLR can be bypassed if the attacker can predict, discover, or control the location of certain memory regions (particularly DLL mappings). The absence of DEP can allow an attacker to use heap spraying to place code at a predictable location in the address space.
In the previous sections we described the effectiveness of DEP and ASLR in isolation from one another. In reality, DEP and ASLR are designed to be used in combination on Windows Vista and beyond. Both of these mitigations are enabled in the context of important applications like Internet Explorer 8, Microsoft Office 2010, and in-box services and applications that ship with the OS. This means that attackers looking to exploit vulnerabilities in these environments will need to overcome both obstacles (in addition to numerous other mitigations).
The DEP+ASLR bypass techniques that are currently being explored in attack research have primarily focused on identifying and refining methods of bypassing ASLR. Once ASLR has been bypassed it is typically straightforward to bypass DEP using established techniques such as return-oriented programming. At this point in time there have been multiple exploits which have demonstrated that it is possible in practice to bypass the combination of DEP+ASLR in the context of certain application domains (such as browsers and third party applications). These exploits have bypassed ASLR through the use of predictable DLL mappings, address space information disclosures, or JIT spraying and have bypassed DEP through the use of return-oriented programming (or some simpler variant thereof) or JIT spraying. In many cases these exploits have relied on predictable mappings caused by DLLs that ship with third party components or by JIT compilation capabilities included in non-default browser plugins. This means that these exploits will fail if the required components are not installed.
Although exploits have been written which are capable of bypassing the combination of DEP+ASLR, the vast majority of exploits that have been written to date do not have such capabilities and instead strictly target applications and platforms that do not enable these mitigations. This affirms our position that DEP+ASLR are strong countermeasures for the types of attacks that we see in the wild today despite weaknesses in their current implementations.
Summary: DEP+ASLR are most effective when used in combination; however, their combined effectiveness is heavily dominated by the effectiveness of ASLR. Exploits have been developed that are able to bypass DEP+ASLR in the context of browsers and third-party applications. Nevertheless, the vast majority of exploits written to date do not attempt to bypass the combination of DEP+ASLR.
As we look toward the future it is clear that attackers will continue to become increasingly incentivized to attempt to develop exploits which are capable of bypassing the combination of DEP+ASLR. Our understanding of the ways that DEP and ASLR can be bypassed directly informs the future work we are doing to improve the robustness and resiliency of our mitigation technologies. Although this work is ongoing there are two noteworthy improvements that we would like to highlight.
The first improvement can be seen in the latest version of the Enhanced Mitigation Experience Toolkit (EMET) which now includes support for a feature known as mandatory ASLR. This feature enforces ASLR for all modules regardless of whether or not they are ASLR aware (which effectively eliminates predictable DLL mappings when enabled on Windows Vista and above). This resolves the ASLR bypass technique we described previously and it has been used in practice to successfully mitigate exploits in the wild. The second improvement consists of JIT spraying mitigations that have been directly incorporated into the JavaScript JIT compiler that was recently released in the Internet Explorer 9 beta. These mitigations act as countermeasures against the JIT spraying techniques that have been described in attack research.
These two improvements help to further illustrate our belief that DEP, ASLR, and exploit mitigations in general are extremely important due to the impact they have on the cost of developing reliable exploits and due to the knowledge demands they place on attackers. Mitigations such as these enable us to be proactive about providing additional protection to customers who may be running software with an unknown or unpatched vulnerability. Ultimately our goal with exploit mitigations is to reach a point where vulnerabilities become too expensive to reliably exploit - and this is a goal we are actively working toward.
We recommend that enterprises and users enable DEP for all critical applications and run a version of Windows that supports ASLR (such as Windows 7). The Enhanced Mitigation Experience Toolkit (EMET) can be used to easily enable DEP and other mitigations for a process. You can read more about EMET here:
http://support.microsoft.com/kb/2458544
The effectiveness of mitigations like DEP and ASLR across the Windows ecosystem is heavily contingent on ISV adoption. ISVs that are interested in more details on how to enable DEP, ASLR, and other mitigations in their products are encouraged to refer to the guidance below:
http://msdn.microsoft.com/en-us/library/bb430720.aspx
Matt Miller, MSEC Security Science
References
[1] Dino Dai Zovi. Practical Return-Oriented Programming. April, 2010.
[2] Dionysus Blazakis. Interpreter Exploitation: Pointer Inference and JIT Spraying. February, 2010.
[3] Hovav Shacham. Return-Oriented Programming: Exploits Without Code Injection. August, 2008.
[4] Peter Vreugdenhil. Pwn2Own 2010 Windows 7 Internet Explorer 8 Exploit. March, 2010.
[5] Hovav Shacham et al. On the Effectiveness of Address-Space Randomization. 2004.
[6] Alexander Sotirov and Mark Dowd. Bypassing Browser Memory Protections. August, 2008.
*Posting is provided "AS IS" with no warranties, and confers no rights.*
The MSRC Engineering team has been investigating reports of a vulnerability involving the use of VBScript and Windows Help files.
What is the impact and affected platforms?
Our investigation has determined that Windows 7, Windows Server 2008, and Windows Vista are not impacted. Only Windows 2000 and Windows XP are impacted by default. Windows 2003 Server is also impacted, but the issue is mitigated in the default configuration due to the presence of the Internet Explorer Enhanced Security Configuration. With this issue, it is possible for a malicious web page to display a dialog box which will trigger the execution of arbitrary code when the user presses the F1 key. The prompt can appear repeatedly when dismissed, nagging the user to press the F1 key. Platforms are affected regardless of the Internet Explorer version installed.
How would a malicious user leverage this vulnerability?
Windows Help files are an inherently unsafe file format. That means these files can run arbitrary code, thus the browser must prevent remote Windows Help files from executing automatically.
VBScript functionality available from within Internet Explorer exposes the MsgBox function, allowing script on a web page to display a message to the user. The parameters supplied to the MsgBox function may reference an associated Window Help file, though this functionality is limited when VBScript is used within the browser. Though user interaction is required the F1 keyboard shortcut does enable an attack scenario. In the exploit, a file path enables a .HLP file to be loaded from the local filesystem, SMB, or WebDav.
Workarounds
As an interim workaround, users are advised to avoid pressing F1 on dialogs presented from web pages or other Internet content. If a dialog box appears repeatedly in an attempt to convince the user to press F1, users may log off the system or use Task Manager to kill the Internet Explorer process.
It is also possible to use the following command line to lock down the legacy Windows Help system, preventing it from loading:
cacls "%windir%\winhlp32.exe" /E /P everyone:N
Command line to roll back this change:
cacls "%windir%\winhlp32.exe" /E /R everyone
As this vulnerability is driven by scripting, the following standard workarounds apply as well:
Set Internet and Local intranet security zone settings to "High" to prompt before running ActiveX Controls and Active Scripting in these zones
You can help protect against exploitation of this vulnerability by changing your settings for the Internet security zone to prompt before running ActiveX controls and Active Scripting. You can do this by setting your browser security to High.
To raise the browsing security level in Internet Explorer, follow these steps:
1.
On the Internet Explorer Tools menu, click Internet Options.
2.
In the Internet Options dialog box, click the Security tab, and then click the Internet icon.
3.
Under Security level for this zone, move the slider to High. This sets the security level for all Web sites you visit to High.
Note If no slider is visible, click Default Level, and then move the slider to High.
Note Setting the level to High may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly even with the security setting set to High.
Impact of workaround. There are side effects to prompting before running ActiveX Controls and Active Scripting. Many Web sites that are on the Internet or on an intranet use ActiveX or Active Scripting to provide additional functionality. For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements. Prompting before running ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround. For each prompt, if you feel you trust the site that you are visiting, click Yes to run ActiveX Controls or Active Scripting. If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".
Add sites that you trust to the Internet Explorer Trusted sites zone
After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone. This will allow you to continue to use trusted Web sites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone.
To do this, follow these steps:
In Internet Explorer, click Tools, click Internet Options, and then click the Security tab.
In the Select a Web content zone to specify its current security settings box, click Trusted Sites, and then click Sites.
If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box.
4.
In the Add this Web site to the zone box, type the URL of a site that you trust, and then click Add.
5.
Repeat these steps for each site that you want to add to the zone.
6.
Click OK two times to accept the changes and return to Internet Explorer.
Note Add any sites that you trust not to take malicious action on your system. Two in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com. These are the sites that will host the update, and it requires an ActiveX Control to install the update.
•
Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone
You can help protect against exploitation of this vulnerability by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone. To do this, follow these steps:
In Internet Explorer, click Internet Options on the Tools menu.
Click the Security tab.
Click Internet, and then click Custom Level.
Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK.
Click Local intranet, and then click Custom Level.
7.
Click OK two times to return to Internet Explorer.
Note Disabling Active Scripting in the Internet and Local intranet security zones may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting, and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly.
Impact of workaround. There are side effects to prompting before running Active Scripting. Many Web sites that are on the Internet or on an intranet use Active Scripting to provide additional functionality. For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround. For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting. If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".
The Group Policy setting to “Turn off displaying the Internet Explorer Help Menu” under the Category Path “Computer Configuration\Administrative Template\Windows Components\Internet Explorer\” is not a sufficient mitigation for this issue.
Acknowledgements
Thanks to Robert Hensing for his work on the issue.
-David Ross, MSRC Engineering
Recently, we found a remote code execution vulnerability in Microsoft’s DirectShow platform (quartz.dll) when processing the QuickTime format. We have released advisory 971778 providing guidance to help protect customers. We’d like to go into more detail in this blog to help you understand:
Which configurations are at risk?
The vulnerability is in DirectShow’s code to process QuickTime format. The QuickTime Movie Parser Filter in DirectShow has been removed from Windows Vista and later operating systems (see http://msdn.microsoft.com/en-us/library/dd377491(VS.85).aspx). Windows Vista, Window Server 2008, and later versions of Windows are not affected by this vulnerability. Older Windows platforms are vulnerable, as shown in the advisory.
If I have installed Apple’s QuickTime, am I safe?
Our investigation has found that the installation of Apple’s QuickTime does NOT mitigate this DirectShow’s vulnerability.
To be clear, whether you’ve installed Apple’s QuickTime or not, the vulnerability is in the Microsoft’s quartz.dll and it’s possible to craft an attack to call that DLL on the system regardless of whether Apple’s QuickTime is present.
Why is this a high risk vulnerability?
The vulnerability is in the DirectShow platform (quartz.dll). While the vulnerability is NOT in IE or other browsers, a browse-and-get-owned attack vector does exist here via the media playback plug-ins of browsers. The attacker could construct a malicious webpage which uses the media playback plug-ins to playback a malicious QuickTime file to reach the vulnerability in Quartz.dll. Please note this type of attack could happen for any browsers, not IE specific.
There is also a file-based attack vector by opening a malicious QuickTime file via Windows Media Player to trigger the vulnerability.
How can I protect myself?
There are several workarounds that you may consider here.
#1: Disable Quick Time Parsing in Quartz.dll by deleting the following registry key:
HKEY_CLASSES_ROOT\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}
For X64 delete the following registry key as well:
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{D51BD5A0-7548-11CF-A520-0080C77EF58A}
This is the best workaround because it’s the most surgical. It only disables QuickTime Parsing in DirectShow. DirectShow's other functionality is not affected. This workaround covers all known attack vectors. Therefore, if you are not concerned about QuickTime content playback via DirectShow, this is the workaround we recommend you apply.
#2: Kill-bit WMP ActiveX Control
If you are using IE, this helps mitigate current attacks we have seen in the wild. You can set the following registry key to apply the killbit:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{6BF52A52-394A-11D3-B153-00C04F79FAA6}] "Compatibility Flags"=dword:00000400
The advantage of this workaround is that it still allows you to use Windows Media Player (or other applications) to playback QuickTime content via DirectShow. The disadvantage is that it only protects against the current attacks we see that use IE. Other attack vectors are not covered. For example, it won’t protect other browsers.
#3: Unregister/ACL quartz.dll
This workaround is effective but can have significant impacts in your environment. Please refer to our previous SRD blog: “MS08-033: So what breaks when you ACL quartz.dll?” to get more details on this.
We don’t recommend this workaround because #1 provides the same level of protection with less impact. However, it is an option listed in the advisory because it is effective protection and to give customers as full a range of options as possible to better protect their environment.
Chengyun, MSRC Engineering
*Postings are provided "AS IS" with no warranties, and confers no rights.*
Today we released Security Advisory 2488013 to notify customers of a new publicly-disclosed vulnerability in Internet Explorer (IE). This vulnerability affects all versions of IE. Exploiting this vulnerability could lead to unauthorized remote code execution inside the iexplore.exe process.
Proof-of-concept exploit bypasses ASLR and DEP
The Metasploit project recently published an exploit for this vulnerability using a known technique to evade ASLR (Address Space Layout Randomization) and bypass DEP (Data Execution Prevention).
In a few words, Internet Explorer loads mscorie.dll, a library that was not compiled with /DYNAMICBASE (thus not supporting ASLR and being located always at the same base) when processing some html tags. Attackers use these predictable mappings to evade ASLR and bypass DEP by using ROP (return oriented programming) gadgets from these DLLs in order to allocate executable memory, copying their shellcode and jumping into it. Note that without that predictable mapping, the only public ways to evade ASLR and DEP is through:
We have recently blogged on the effectiveness of ASLR and DEP here.
Recommendation: Use Enhanced Mitigation Experience Toolkit (EMET) to dynamically rebase all loaded DLLs
In order to minimize the risk of exploitation, users could install EMET and proceed to protect the iexplore.exe process as shown in the BlueHat video.
Exploits that attempt to bypass ASLR and DEP would use several ROP gadgets for several purposes. To understand why EMET is an effective workaround for these exploits, let’s focus on the stack pivot gadgets which set the stack pointer to the attacker controlled data (heap spray in our case):
0:000> u 63f0575b L4 mscorie!_chkstk+0x1b: 63f0575b 94 xchg eax,esp 63f0575c 8b00 mov eax,dword ptr [eax] 63f0575e 890424 mov dword ptr [esp],eax 63f05761 c3 ret 0:000>
When EMET is in place, this type of exploit will most likely fail. This is because of at least three mitigations:
Although the later two mitigations in the list above are not bullet proof and can be evaded, Mandatory ASLR is a solid one for closing the mscorie.dll exploitation vector. When the exploit attempts to jump into the ROP gadget that it believes to be at a predictable memory address, it will hit an access violation and crash the process:
0:000> u 63f0575b L4 63f0575b ?? ??? ^ Memory access error in 'u 63f0575b l4' 0:000>
And the exploit will fail.
Thanks to Richard van Eeden, Bruce Dang, and Jonathan Ness from the MSRC Engineering team for the help investigating this issue.
--
Fermin J. Serna, Security Software Engineer
Last week, we released Security Advisory 2607712, notifying customers that fraudulent digital certificates had been issued by certificate authority DigiNotar. We’d like to follow up on that notification in this blog post by explaining more about the potential risks and actions you can take to protect yourself from any potential attacks that would leverage those fraudulent certificates.
Scope of the risk
Digital certificates issued by a trusted Certificate Authority (CA) establish the identity of a computer. Protocols that assure your privacy, such as SSL (HTTPS) and TLS, leverage a server’s digital certificate to ensure that no third party can eavesdrop on or tamper with conversations between a client and the server. Clients and servers establish their identity via a digital certificate. Clients make a decision to trust the identity of the server because they trust that a CA verifies the legitimacy of the person or company requesting the certificate. If a trusted CA were to be compromised or tricked into issuing fraudulent certificates, a malicious attacker could potentially request and be granted a digital certificate that would allow the attacker to participate in HTTPS conversations, snooping on or tampering with the contents.
For an attack to be successful, an attacker must have been issued a digital certificate for the server or domain to which the client is initiating a connection. Also, the attacker must be able to tamper with the conversation in progress. Practically speaking, this tampering can happen in one of three ways:
Without this type of “man-in-the-middle” access, an attacker would be unlikely to be successful in carrying out an attack.
In this particular case, we were originally aware of fraudulent certificates issued by DigiNotar for *.google.com and have since become aware of fraudulent certificates issued for *.microsoft.com, *.windowsupdate.com, www.update.microsoft.com, and a number of other domains for which conversation privacy is extremely important. Windows Update is a special case addressed later in the blog; however, suffice it to say that if the attacker had one of those certificates and had man-in-the-middle access to your network traffic, they could potentially snoop on (or change the contents of) conversations between you and any of those domains.
Vulnerable configurations
All versions of Windows are affected by this attack. However, when a user initiates an HTTPS SSL connection via Internet Explorer on Windows Vista, Windows 7, or Windows Server 2008 and encounters a new root certificate, the Windows certificate chain verification software checks a list of valid root certificates, which is hosted on Windows Update. As of August 29th, this Certificate Trust List (CTL) on Windows Update has been revised to remove DigiNotar from the list of trusted Certificate Authorities so that any certificates issued by DigiNotar are no longer trusted for HTTPS conversations.
Windows XP and Windows Server 2003 do not have the same Windows Update check mechanism. Instead, these versions of Windows rely on a static list of trusted root certificate authorities. This list is updated through the non-security update “Update for Root Certificates (KB 931125)”. DigiNotar was not initially included as a trusted root certificate in Windows XP, so if you have never installed this update, you are not vulnerable to any certificates issued by them.
However, any Windows XP or Windows Server 2003 system that installed this update as of November 2008 or later would have DigiNotar added as a trusted root certificate. Administrators of these systems can follow the steps in the “What you can do to protect yourself” section below to take proactive actions to remove DigiNotar as a trusted root Certificate Authority until Microsoft releases an update that fully addresses this problem.
Windows Phone devices are unaffected. No Windows Mobile devices have a DigiNotar certificate in the Trusted Root Certificate Store.
What Microsoft is doing to protect you on Windows Vista and later platforms
Microsoft has updated the Certificate Trust List (CTL) hosted on Windows Update to remove DigiNotar as a trusted root Certificate Authority. Attacks targeting Internet Explorer users on Windows Vista and later platforms any time after August 29th will likely fail. However, we should note that systems having previously encountered DigiNotar certificates may have cached DigiNotar as a trusted root Certificate Authority. This cached list is updated client-side every seven days. Therefore, the last date on which any attack targeting Internet Explorer users on Windows Vista and later platforms might possibly be successful is September 5th.
What Microsoft is doing to protect you on Windows XP and Windows Server 2003
We are currently preparing an update for Windows XP and Windows Server 2003 platforms which will add DigiNotar to our Untrusted Certificate Store. This update will be available soon.
What you can do to protect yourself
First, as indicated in the security advisory, we recommend keeping Microsoft software updated. If you’re able to do so, opt into Automatic Updates to automatically get the Windows XP and Windows Server 2003 updates when they become available.
Second, you can choose to delete the DigiNotar root from the root store manually. You might consider doing this if you believe the risk to your network or system is urgent and you would like to take action before the Windows XP and Windows Server 2003 update becomes available. After doing this, you’ll also need to clear the local cache. The steps for both removing the DigiNotar root from the trusted root CA store and clearing the cache are listed below.
Step 1: Remove the DigiNotar Root from the trusted root CA store
To perform the above steps from the command-line, you can use the certutil.exe tools as follows:
If you distribute roots in your enterprise using group policy, follow the instructions to remove a root across an enterprise network via group policy - http://technet.microsoft.com/en-us/library/cc786148(WS.10).aspx. In step 3 of those group policy instructions, choose the root CA in question here - DigiNotar Root CAs with thumbprints "c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c" and "43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3".
Step 2: Clear the cache to remove any older cached CTL
The simplest way to do so is to use “certutil –urlcache * delete”. This will clean up the cache for the current user. You can find further documentation on this step, including a Microsoft Fix It package to clean up the cache, at http://support.microsoft.com/kb/2328240
As indicated above, most customers on Windows Vista and later platforms are already protected due to the updated Certificate Trust List on Windows Update, which is checked when Windows encounters a new root Certificate Authority. To ensure that DigiNotar has not been cached locally as a trusted root CA, you can clear the local cached CTL as explained above. A fresh CTL will automatically be downloaded the next time Windows encounters a new root CA.
There is one final edge case to consider that will not be automatically protected:
Then you likely will want to add the DigiNotar roots to the Untrusted Certificate Store via group policy.
Additional protections built-in to Windows Update
Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers. The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate.
Thanks to Yogesh Mehta, Shain Wray, Charles Anthe, and Mark Wodrich for the help with this blog post.
Updated Sept 5: Added certutil.exe command line example. Thanks Uwe Wizovsky for the tip.
- Jonathan Ness, MSRC Engineering
Today we released Security Advisory 983438 informing customers of a cross-site scripting (XSS) vulnerability in SharePoint Server 2007 and SharePoint Services 3.0. Here we would like to give further technical information about this vulnerability.
What is the attack vector?
The advisory states that the vulnerability could allow Elevation of Privilege (EoP) within the SharePoint site itself. We would like to stress that this EoP is not EoP from normal user to admin user in the workstation or the server environment. Instead, the attacker may execute malicious script under a SharePoint user’s context within his/her Sharepoint session. The most likely attack scenario, then, is that an attacker sends a malicious link to a user who is logged into their Sharepoint server. If the user clicks the link, the javascript created by the attacker and embedded in the link would execute in the context of the user who clicked the link.
Mitigation
Sharepoint uses Http-Only cookies for authentication. HttpOnly cookies are not accessible through script, significantly mitigating the risk of XSS attacks. For more information, please refer to Mitigating Cross-site Scripting With HTTP-only Cookies.
IE8’s XSS filter is enabled by default in the Internet Zone. The IE8 XSS filter catches this class of XSS attacks so users of IE8 are at the reduced risk from this vulnerability. IE8’s XSS filter is not enabled in the local intranet zone. It can be turned on in the local intranet zone via the following UI.
Or administrators can choose to enable or disable the XSS Filter for any zone via group policy. Please refer to Group Policy and Internet Explorer 8 for more details.
Workaround
We recommend a server-side workaround to ACL down the file help.aspx. If you enable this workaround, you will be unable to view Help content within your Sharepoint site. For users who implement the server-side mitigation, help content in English is available here as an alternative to SharePoint-provided help:
http://office.microsoft.com/en-us/sharepointserver/FX101211721033.aspx
Jonathan Ness, David Ross, and Chengyun Chu, MSRC Engineering
At the CanSecWest conference earlier this month we made our first public release of the !exploitable Crash Analyzer. While an upcoming white paper and the CanSecWest slide deck go into detail on the technology involved, we thought it might be useful to explore the history of the tool.
The technology and research that eventually became the !exploitable Crash Analyzer came out of the investment that MSEC (and Microsoft as a whole) has made in fuzzing technology. Preceding the launch of Windows Vista, there was a 14 month fuzzing effort totaling over 350 Million iterations. Upon examining crashes from the fuzzing effort, a number of observations were made about similarities in crashes. Several folks from what is now MSEC (Adel Abouchaev, Damian Hasse, Scott Lambert and Greg Wroblewski) published an article regarding some of these findings in the November 2007 edition of MSDN.
One of the nice benefits of fuzzing is that it eliminates any need to determine “is the problematic code reachable by an attacker”. Because the malformed data is provided in the same way that an attacker would provide it, we know that if we are able to generate an issue during fuzzing, a real attacker would in all likelihood be able to reach the same code.
Another observation was that a single issue in code could be reached via multiple vectors, creating crashes that appeared to be different, but with the same root cause. By grouping crashes together which occur in the same area of code, the number of crashes that need to be looked at can be dramatically decreased.
In the diagram below, we’ve seen the results from 2 weeks of fuzzing with 4 different fuzzers against 1 parser, which found 57 crashes, and VERY LITTLE overlap between fuzzers:
When the same 57 crashes are run through !exploitable Crash Analyzer, and grouped for similarity, we see that there are 15 unique issues, reducing the number of crashes to look at nearly 4-fold, and Fuzzers A and B found all but 2 of the issues, showing what fuzzers really give the best coverage for this application.
However, even when grouping similar crashes, there is a need to perform a rough-cut triage of the severity of the crashes found. The !exploitable Crash Analyzer was built to address these needs. Because of this, the tool assumes that the information in the faulting instruction is controlled by an attacker – the normal case when assessing results of fuzzing runs.
Once we move beyond fuzzing, the assumptions built into the tool make the results less reliable. Unlike our fuzzer generated crashes, we don’t actually know whether the crash was caused by information that could be controlled by an attacker. Even in this case, the stack trace hashes let us group similar issues. But we have to add an implicit caveat to the exploitability ratings provided by !exploitable: “If an attacker controlled the source data to the faulting instruction…”.
What does this mean for the developer? Effectively, it means that we don’t know whether or not we simply have a problematic coding issue or bug versus a true security vulnerability. A coding issue or bug becomes a security vulnerability only when an attacker is able to reach it, generally by providing invalid data. It may be that the problematic code cannot be reached by an attacker, in which case we merely have a bug. It may be that there are code paths (which we may or may not have found) that expose the problematic code to attacker controlled data. Or it may be that a yet to be implemented feature will expose the issue. But for the software developer, especially when these coding issues are found early in development, the knowledge that there is a potentially problematic issue in the code should be enough to get the fix created and implemented or made available for users to install as appropriate.
Even in the cases where the crash was caused by data supplied by an attacker, we don’t know how much control the attacker has. For example, if we look at a faulting memory copy, it’s possible that the attacker could control the destination address, the source address, the move length, or some combination of all three. Inside of the !exploitable Crash Analyzer, we assume that the attacker has control of all three. While this is probably not the case, we are willing to accept the over-assessment of risk in this case because the coding issue is considered severe enough that the ensuing false positive rate is something we consider acceptable.
When analyzing a crash, !exploitable is looking at the details, and categorizing the severity based on reasonably coarsely grained heuristics. You can read the output of !exploitable as “This is the sort of crash that experience tells us is likely to be exploitable”, and for the software developer, that should be all of the information that is necessary. It’s well beyond the scope of the tool to figure out how an exploit could be delivered; that sort of analysis tends to require highly skilled humans.
Moreover, even in the case where a vulnerability is exploitable, exploit mitigations built into the compiler and the platform may be sufficient to prevent actual exploitation. This doesn’t mean that the root problem shouldn’t be fixed, any more than having airbags and wearing your seatbelt means it is acceptable to not repair your brakes. But it does mean that sometimes the end user is protected, even if everything else went wrong.
Fundamentally, this is a defensive tool, aimed at the software developer, especially those without deep expertise in security threats. By grouping common issues, identifying cases where multiple code paths flow to the same underlying issue, and providing a rough cut of the security implications of individual crashes, we think it provides a valuable service to software developers triaging bugs during development. We’ve certainly found that to be the case inside of Microsoft.
Dave Weinstein and Jason Shirk Microsoft Security Engineering Center
Yesterday we heard reports of a commercially available exploit that bypasses DEP. This exploit was made available to a limited number of major security vendors (Antivirus, IDS, and IPS vendors) and government CERT agencies. We wanted to use this opportunity to give an overview of current customer risk related to this DEP bypass.
Real-world attacks so far still only effective against Internet Explorer 6
We have seen an increase in attacks attempting to exploit the vulnerability detailed in Security Advisory 979352. However, all attacks we have seen so far still target Internet Explorer 6 - this is also confirmed by the attack samples our Microsoft Active Protections Program (MAPP) partners have sent in.
While we have not seen real-world attacks for any other platform, we have seen researchers poking at other platforms and have seen the following:
State-of-the-art of attacker research on various platforms
Here’s the current state-of-the-art on each platform:
Other mitigations (besides DEP)
We have discussed DEP at length in this blog. As you can see in the table above, two other mitigations help prevent or limit the impact of attacks on later platforms.
Out-of-band update coming tomorrow
We’ll be releasing a comprehensive, well-tested security update tomorrow morning PST to address this vulnerability. In the meantime, we hope this information helps you assess risk and protect your environment.
Thanks Matt Miller and John Lambert for help with the ASLR arithmetic and other feedback.
Update Jan 20, 2010: Updated "less than 1%" to "1%". Thanks reader Larry for catching arithmetic error.
Update Jan 22, 2010: Updated to reflect new understanding of the commercially-available, limited distribution exploit on IE8 / XP SP3. Also removed formula behind the theoretical 1% ASLR success chance. The formula was off by a fraction of a percentage point and the math to describe it would be difficult to explain. The chance is approximately 1.1%.
It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the second part of our three-part Kill-Bit FAQ.
The Kill-Bit FAQ – Part 2 of 3
How do ActiveX Controls, OLE Controls, and COM Objects relate?
An ActiveX control is an OLE control that is intended to be used inside a web browser. Likely an ActiveX control is marked Safe for Scripting and Safe for Initialization as well as being packaged to be installed via Authenticode. More information on the difference between OLE and ActiveX controls is available here.
All ActiveX / OLE controls are COM objects, but not vice versa. ActiveX / OLE controls are built on COM and implement a required minimum set of interfaces in order to operate properly within any OLE container. More information on the requirements that a COM object must meet in order to be considered a valid OLE control can be found here.
ActiveX Controls, OLE Controls, and COM Objects all can be instantiated in IE with an OBJECT tag or through script (“new ActiveXObject”, etc.) All are subject to Safe for Scripting, Safe for Initialization and the Kill-Bit.
Will IE host any ActiveX Control, OLE Control, or COM Object?
Sort of. Prior to MS05-052, IE treated all COM objects equally. Any registered COM object could be instantiated within the browser just as long as the Kill-Bit wasn’t in place for its CLSID. Safe for Scripting and Safe for Initialization would be verified only after instantiation as particular operations were attempted on the object. Think about it – there’s no way to call into a control’s implementation of IObjectSafety without actually instantiating the control!
In MS05-052, IE made a change that affects the way controls are instantiated in the Internet zone. The IObjectSafety check is now frontloaded so that IE can determine control safety status quickly and abort instantiation as soon as a control is identified as unsafe. Extra unnecessary probing of COM objects upon instantiation was a contributing factor to the exploitability of many COM object instantiation bugs. Control authors can set the compatibility flag value of 0x00800000 on their controls to opt-out of this new behavior if necessary.
How does the Kill-Bit interact with “Safe for Scripting” and “Safe for Initialization” (SFS / SFI)?
The Kill-Bit trumps SFS / SFI. If a control has the Kill-Bit, it just won’t load within Kill-Bit aware applications, period.
If I Kill-Bit my vulnerable object / control, should I still release a fixed version?
If you are releasing a Kill-Bit for a vulnerable object, it makes sense to issue a code fix as well. A code fix will mitigate the threat posed by environments that provide an attack scenario through which the vulnerability can be exploited yet do not support the Kill-Bit. If you do release a fixed version as well as a Kill-Bit, make sure to give the control a new CLSID and issue a “Phoenix-Bit” (see below) as necessary if the update control must operate within Kill-Bit aware environments.
What is the “Phoenix-Bit” a.k.a. AlternateCLSID?
Since a Kill-Bit completely prevents a control from loading in the browser, there needs to be a way to safely revise a control without breaking web content that references the killed CLSID. The Phoenix-Bit does this – it allows control developers to kill the vulnerable CLSID and transparently redirect requests for the old CLSID to a new CLSID. The name “Phoenix-Bit” honors the mythical Phoenix bird known for its regenerative ability.
When verifying that a CLSID has or has not been killed, MSHTML will check to see whether an alternate CLSID has been provided for use in place of a killed CLSID. This will allow pages or Kill-Bit aware applications that have not been revised to refer to the new CLSID and still function.
To implement the Phoenix-Bit, add an “AlternateCLSID” string value to the killed CLSID under the ActiveX Compatibility key. The Phoenix-Bit requires that the Kill-Bit is also set. Example:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
{CLSID of killed ActiveX control}, Compatibility Flags, 0x0400
{CLSID of killed ActiveX control}, AlternateCLSID, “{CLSID of alternate ActiveX control}”
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.
The alternate CLSID requires the curly braces. It is possible to chain redirects up to ten levels deep.
The Phoenix-Bit was introduced in IE6 SP1 and was backported to downlevel versions (5.01 and 5.5) in 2003. It is supported on all fully patched versions of IE >= 5.01.
If I implement the Phoenix-Bit should the control still support the old CLSID?
If the control is intended to be hosted outside of IE, then yes. In that case the control should support both the old CLSID and the new CLSID. Otherwise, hosts that do not understand or honor the Phoenix-Bit will be broken if they reference the control by the old CLSID.
Are there any alternatives to the Phoenix-Bit?
Ditching your control’s existing CLSID may be difficult if the CLSID is hard-coded in many web pages. The recommended solution to this problem is the Phoenix-Bit (see above). Besides the Phoenix-Bit, there are a few potential alternate solutions you may want to investigate:
Is there an easy way for users to block ActiveX controls in Internet Explorer without setting a Kill-Bit?
Yes, the Add-on Manager in XP SP2 and above allows users to easily disable specific ActiveX controls in Internet Explorer. It’s worth mentioning though that this is not technically equivalent to setting a Kill-Bit. So for example, Windows applications that respect the Kill-Bit to block ActiveX controls may or may not respect the Add-on Manager settings.
- Security Vulnerability Research & Defense Bloggers