Yesterday, the MSRC released Microsoft Security Advisory 979352 alerting customers to limited, sophisticated attacks targeting Internet Explorer 6 customers. Today, samples of that exploit were made publicly available.
Before we get into the details I want to make one thing perfectly clear. The attacks we have seen to date, including the exploit released publicly, only affect customers using Internet Explorer 6. As discussed in the security advisory, while newer versions of Internet Explorer are affected by this vulnerability, mitigations exist that make exploitation much more difficult. We would like to share a little more information about both the vulnerability and the exploits we have seen to help you understand the risk to your organization.
Risk, by platform
Newer versions of Internet Explorer and later Windows releases are at reduced risk to the exploit we have seen due to platform mitigations explained in the blog post below. (Note: Server platforms are omitted from this table because browsing is less likely from Servers.)
As you can see, the client configuration currently at risk is Windows XP running IE6. We recommend users of IE6 on Windows XP upgrade to a new version of Internet Explorer and/or enable DEP. Users of other platforms are at reduced risk. We also recommend users of Windows XP upgrade to newer versions of Windows.
More information about the vulnerability
The vulnerability is an Internet Explorer memory corruption issue triggered by an attacker using JavaScript to copy, release, and then later reference a specific Document Object Model (DOM) element. If an attacker is able to prepare memory with attack code, the reference to a random location of freed memory could result in execution of the attacker’s code.
Ways to block Code Execution
The vulnerability is present in Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8. All versions may crash after opening the attack code. However, there are a number of ways to limit the attack to an IE crash and prevent attacker code execution.
Note on enabling DEP for Windows Vista
The security advisory lists steps to enable DEP for Internet Explorer 7. To enable DEP on Windows Vista, be sure to run Internet Explorer as an Administrator (Right-click, and then select “Run as Administrator”). After enabling DEP, close the Internet Explorer session and re-launch Internet Explorer to browse with DEP enabled. The option will be grayed-out if you are not running Internet Explorer as an Administrator.
If you enable DEP on Windows Vista using the Microsoft Fix It, you will not see the Internet Explorer user interface change. However, after restarting Internet Explorer, you can use a tool like Process Explorer to verify that DEP is enabled. The Internet Explorer user interface displays value of a registry key while the Microsoft Fix It enables DEP by using an appcompat shim.
Acknowledgements
Big thanks to Chengyun Chu for his exploit analysis and risk assessment help. And thanks to Rob Hensing for the DEP research and FixIt4Me MSI help. Thanks to Fermin J. Serna for the vulnerability analysis. Lots of people at Microsoft are working on this, thanks everybody.
- Jonathan Ness, MSRC Engineering
*Posting is provided "AS IS" with no warranties, and confers no rights.*
The Khronos Group’s WebGL technology is a cross-platform, low-level 3D graphics API for the web. Recently, Context Information Security published two reports critical of the WebGL technology, WebGL – A New Dimension for Browser Exploitation and WebGL – More WebGL Security Flaws.
One of the functions of MSRC Engineering is to analyze various technologies in order to understand how they can potentially affect Microsoft products and customers. As part of this charter, we recently took a look at WebGL. Our analysis has led us to conclude that Microsoft products supporting WebGL would have difficulty passing Microsoft’s Security Development Lifecycle requirements. Some key concerns include:
The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern. We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.
As WebGL vulnerabilities are uncovered, they will not always manifest in the WebGL API itself. The problems may exist in the various OEM and system components delivered by IHV’s. While it has been suggested that WebGL implementations may block the use of affected hardware configurations, this strategy does not seem to have been successfully put into use to address existing vulnerabilities.
It is our belief that as configurations are blocked, increasing levels of customer disruption may occur. Without an efficient security servicing model for video card drivers (eg: Windows Update), users may either choose to override the protection in order to use WebGL on their hardware, or remain insecure if a vulnerable configuration is not properly disabled. Users are not accustomed to ensuring they are up-to-date on the latest graphics card drivers, as would be required for them to have a secure web experience. In some cases where OEM graphics products are included with PCs, retail drivers are blocked from installing. OEMs often only update their drivers once per year, a reality that is just not compatible with the needs of a security update process.
Modern operating systems and graphics infrastructure were never designed to fully defend against attacker-supplied shaders and geometry. Although mitigations such as ARB_robustness and the forthcoming ARB_robustness_2 may help, they have not proven themselves capable of comprehensively addressing the DoS threat. While traditionally client-side DoS is not a high severity threat, if this problem is not addressed holistically it will be possible for any web site to freeze or reboot systems at will. This is an issue for some important usage scenarios such as in critical infrastructure.
We believe that WebGL will likely become an ongoing source of hard-to-fix vulnerabilities. In its current form, WebGL is not a technology Microsoft can endorse from a security perspective.
We recognize the need to provide solutions in this space however it is our goal that all such solutions are secure by design, secure by default, and secure in deployment.
- MSRC Engineering
Today we released Security Advisory 2269637 notifying customers of a remote attack vector to a class of vulnerabilities affecting applications that load DLL’s in an insecure manner. The root cause of this issue has been understood by developers for some time. However, last week researchers published a remote attack vector for these issues, whereas in the past, these issues were generally considered to be local and relatively low impact. In this blog post, we’d like to share:
The vulnerability
When an application loads a DLL without specifying a fully qualified path name, Windows will attempt to locate the DLL by searching a defined set of directories. We have discussed the DLL search path on this blog and it has also been explained well on David LeBlanc’s blog. For the sake of this issue, its sufficient to say that if an attacker can cause an application to LoadLibrary() while the application’s current directory is set to an attacker-controlled directory, the application will run the attacker's code. Development best practices state that applications should call SetDllDirectory with a blank path before calling LoadLibrary(“foo.dll”) to ensure that foo.dll is not loaded from the current directory. We are investigating whether any of our own applications are affected by this class of vulnerability so that we can take appropriate action to protect customers.
Making a risk assessment for your environment
The most likely exploit scenario involves an attacker convincing the victim to open a file hosted on an attacker-controlled SMB or WebDAV share. The file itself would not necessarily be malicious or malformed. The key is that the file is loaded from a location where an attacker can also place a malicious DLL with the same name as a DLL the vulnerable application loads.
If a perimeter firewall prevents a system from making outbound SMB or WebDAV connections to attacker-controlled locations, this issue poses little risk. An attack cannot be automatically launched through email or web browsing attack vectors; a user must choose to open a file. However we recognize that users will often open trusted filetypes. We continue to recommend that all outbound SMB is filtered at the perimeter firewall. In addition, the security advisory recommends disabling the WebDAV client service on workstations to prevent outbound WebDAV connections.
A tool you can use to protect your systems
Another option for protecting your systems is to deploy a tool that can help prevent exploitation of this issue. Knowledge Base article 2264107 offers for download a tool that allows customers to selectively change the library loading behavior, either system-wide or for specific applications.
Customers can set the following two registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\CWDIllegalInDllSearchHKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ Image File Execution Options\binaryname.exe\CWDIllegalInDllSearch
Setting the first key will define the system-wide behavior, whereas the second key will set the behavior for one particular application. Note that this is an Image File Execution Option (IFEO), and thus will be valid for all binaries with that same name on the system.
The values for these keys have slightly different effects, depending on from where the application is started.
Scenario 1: The application is started from a local folder, such as C:\Program Files
Scenario 2: The application is started from a remote folder, such as \\remote\share
Scenario 3: The application is started from a WebDAV folder, such as http://remote/share
How can developers address these issues?
Microsoft recommends that developers clearly define from where they intend to load specific libraries. This was documented in the specific LoadLibrary application programming interface documentation on MSDN. However, we recognize that this guidance may not always have been very clear. We recently published an MSDN article, “Dynamic-Link Library Security,” that provides specific guidance to developers on how to load these libraries securely.
While there are several affected situations, described in detail in the above MSDN article, our general recommendations are:
We’ve also recently drafted additional guidance to help developers understand this issue. You can find that developer guidance attached to the blog post.
What Microsoft is doing
Loading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some applications require the ability to load libraries from the current working directory. Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not make this mistake in the future.
Microsoft is also conducting a thorough investigation into how this new vector may affect Microsoft products. As always, if we find this issue affects any of our products, we will address them appropriately.
We hope this blog helps address any questions you may have. Thanks to Mark Debenham, Anoop KV, Hari Pulapaka, Dou Kaya, Gov Maharaj, David LeBlanc, and Michael Howard for their work on this issue.
Cheers,
Jonathan Ness, MSRC EngineeringMaarten Van Horenbeeck, MSRC Program Manager
Today, we released Security Advisory 2718704, notifying customers that unauthorized digital certificates have been found that chain up to a Microsoft sub-certification authority issued under the Microsoft Root Authority. With this blog post, we’d like to dig into more technical aspects of this situation, potential risks to your enterprise, and actions you can take to protect yourself against any potential attacks that would leverage unauthorized certificates signed by Microsoft.
We'd also like to share how this issue relates to a complex piece of targeted malware known as "Flame". As many reports assert, Flame has been used in highly sophisticated and targeted attacks and, as a result, the vast majority of customers are not at risk. Additionally, most antivirus products will detect and remove this malware. That said, our investigation has discovered some techniques used by this malware that could also be leveraged by less sophisticated attackers to launch more widespread attacks. Therefore, to help protect both targeted customers and those that may be at risk in the future, we are sharing our discoveries and taking steps to mitigate the risk to customers.
How did this happen?
When we initially identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft, we immediately began investigating Microsoft’s signing infrastructure to understand how this might be possible. What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure.
What Microsoft is doing to protect customers
As soon as we discovered the root cause of this issue, we immediately began building a update to revoke the trust placed in the “Microsoft Enforced Licensing Intermediate PCA” and “Microsoft Enforced Licensing Registration Authority CA” signing certificates. That update is available today through Windows Update and Automatic Updates. This update places three certificates into the Windows Untrusted Certificate Store.
We have also discontinued issuing certificates usable for code signing via the Terminal Services activation and licensing process.
Thumbprints of affected certificates
While we encourage all customers to apply the officially tested update to add the proper certificates to the Untrusted Certificate Store, as an alternative you can instead place the certificates there in another way. For example, it might be more convenient to use the certutil command or the Certificates MMC snap-in. Or you might instead choose to manage trusted and untrusted certificates in your enterprise via group policy. Here are the thumbprints of the certificates to be placed in the Untrusted Certificates Store.
Connection to Flame malware
Components of the Flame malware were signed with a certificate that chained up to the Microsoft Enforced Licensing Intermediate PCA certificate authority, and ultimately, to the Microsoft Root Authority. This code-signing certificate came by way of the Terminal Server Licensing Service that we operate to issue certificates to customers for ancillary PKI-based functions in their enterprise. Such a certificate could (without this update being applied) also allow attackers to sign code that validates as having been produced by Microsoft.
Conclusion
We recommend that all customers apply this update.
We are aware of public attacks on the Internet exploiting a vulnerability in the Office Web Components Spreadsheet ActiveX control (OWC 10 and OWC11). Microsoft has released an advisory with further information available here.
What’s the attacking vector?
This vulnerability could be used for remote code execution in a "browse and get owned" scenario. User interaction is required since a user needs to go to a malicious website that hosts the exploit.
What configurations are at risk?
Neither OWC10 nor OWC11 are installed by default on any Windows version. However, it can be installed along several products:
Yes=Installed by default (Vulnerable) Opt = Optional install (May be vulnerable)
Please note, there are several scenarios and configurations that mitigate this vulnerability:
How do I check whether I am at risk?
You can check whether a workstation is vulnerable to this attack by using the Classid.cs tool we published in a previous blog post.
By default, if the control is installed, it can be instantiated and scripted as seen by the tool output below:
C:\>ClassId.exe {0002E541-0000-0000-C000-000000000046} (*)Clsid: {0002E541-0000-0000-C000-000000000046}Progid: OWC10.Spreadsheet.10Binary Path: C:\PROGRA~1\COMMON~1\MICROS~1\WEBCOM~1\10\OWC10.DLLImplements IObjectSafety: TrueSafe For Initialization (IObjectSafety): True --- IE will allow loadingSafe For Scripting (IObjectSafety): True --- IE will allow scriptingSafe For Initialization (Registry): FalseSafe For Scripting (Registry): FalseKillBitted: False --- It is not killbitted
(*) This example uses the OWC10 classid. Same applies to the OWC11 classid: {0002E559-0000-0000-C000-000000000046}
How could I protect myself?
In order to protect your system you can issue the killbit for the two classids by adding the following value in the registry following these steps:
1) Use Registry Editor to view the data value of the Compatibility Flags DWORD in the following two registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{0002E541-0000-0000-C000-000000000046}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{0002E559-0000-0000-C000-000000000046}
2) Change or add the value of the Compatibility Flags DWORD value to 0x00000400.
After applying the killbit you can check it again with the ClassId.cs tool:
C:\>ClassId.exe {0002E541-0000-0000-C000-000000000046} (*)Clsid: {0002E541-0000-0000-C000-000000000046}Progid: OWC10.Spreadsheet.10Binary Path: C:\PROGRA~1\COMMON~1\MICROS~1\WEBCOM~1\10\OWC10.DLLImplements IObjectSafety: TrueSafe For Initialization (IObjectSafety): TrueSafe For Scripting (IObjectSafety): TrueSafe For Initialization (Registry): FalseSafe For Scripting (Registry): FalseKillBitted: True --- Since the kilbit has been applied, IE will refuse to load the control
At this point you are no longer vulnerable to this threat through the IE vector.
As mentioned in the advisory, we are also providing a way to apply this workaround automatically. You can click the button below to set the kill-bit on this control.
Please visit Microsoft Knowledge Base Article 973472 for more information about this FixIt option.
- Fermin J. Serna, MSRC Engineering
We have mentioned DEP in several recent blog posts (1, 2, 3, and 4). This blog post will answer:
This is the first of a two-part blog series on DEP as a mitigation technology.
What is DEP?
DEP or “Data Execution Prevention” is a hardware + software solution for preventing the execution of code from pages of memory that are not explicitly marked as executable. Windows XP SP2, Windows Server 2003 SP1, and later operating systems check if the CPU supports enforcement of the ‘no execute’ or ‘execute disable bit’ for a page of memory.
Before Windows XP SP2, an exploit (“code”) could execute from memory allocated without the execute memory protection constant set. For example, if a page of memory were allocated using the VirtualAlloc() function specifying PAGE_READWRITE, it was still possible to execute code from that page of memory. Starting with Windows XP SP2 and Windows Server 2003 SP1, if the CPU supports the execute disable (XD – Intel CPUs) or no execute (NX – AMD CPUs) bits, any attempts to execute code from a page of memory with a (for example) PAGE_READWRITE memory protection will generate a STATUS_ACCESS_VIOLATION (0xC0000005) access violation exception. For more information on how hardware enforced DEP works please refer to the following article: http://technet.microsoft.com/en-us/library/bb457155.aspx.
DEP is “always on” for 64bit processes on 64bit versions of Windows and it cannot be disabled. The Windows DEP policy can be managed on both a system wide and per-process basis and both approaches will be discussed below. This blog post will apply specifically to 32bit processes running on either a 32bit or 64bit version of Windows.
How robust is DEP?
DEP presents a hurdle to attackers as they attempt to successfully exploit security vulnerabilities. In some cases, it is possible for an attacker to evade DEP by using an exploitation technique such as return-to-libc. DEP by itself is generally not a robust mitigation. DEP is a critical part of the broader set of exploit mitigation technologies that have been developed by Microsoft such as ASLR, SeHOP, SafeSEH, and /GS. These mitigation technologies complement one another; for example DEP’s weaknesses tend to be offset by ASLR and vice versa. DEP and ASLR used together are very difficult to bypass. The known bypasses that exist have been tied to specific application contexts (such as the IE7 and earlier bypass from Mark Dowd and Alex Sotirov).
How do I enable DEP?
If you have hardware that supports DEP and you are running Windows XP SP2 or newer operating system – you are already using DEP to some extent! Hardware enforced DEP can be configured system wide (applying to all processes) or using per-process policies. There are four different ways of enforcing a system wide DEP policy on platforms that support it.
Windows XP SP2 and Windows Server 2003 SP1
This article does a great job explaining how to use the boot.ini or the GUI to configure the memory protection settings on Windows XP SP2 and Windows Server 2003 SP1. Note that configuring the “system wide” DEP policy requires administrative privileges.
Windows Vista and Windows Server 2008
To configure the system-wide DEP policy on Windows Vista and Server 2008, modify the Boot Configuration Database using the bcdedit.exe console application from an elevated command prompt. You can find more information about how to do that here: http://msdn.microsoft.com/en-us/library/aa468629.aspx
Potential application compatibility issues with DEP “Always On”
Setting DEP to always be enabled for all processes may increase the risk of causing application problems due to certain behavior from versions of ATL prior to version 7.1. Older versions of ATL generated machine code at runtime and then attempted to execute this code from pages of memory that were not marked as executable, thus causing a DEP violation if DEP is enabled. If the system-wide setting is “opt-in”, a process known as “ATL thunk emulation” is used to avoid ATL related DEP crashes. “ATL thunk emulation” is not used if DEP is “Always On”. NOTE: When the "Always On" setting is used there are known compatibility issues with Microsoft Office applications when opening documents that contain VBA (Visual Basic for Applications) macros that can lead to DEP related crashes.
How can I tell if a specific process has opted-in or will opt-in to DEP?
The easiest way to tell if a process is currently using DEP is to use Process Explorer and to configure it to show the processes DEP status (View->Select Columns->Process DEP status) as shown below:
To determine why a process uses (or does not use) DEP requires a bit more investigative work. Here are the ways the system could have decided on a process’s DEP state. Each will be explored in more detail later in the blog post.
How Per-Process DEP policy works on Windows XP SP2 & Windows Server 2003 SP1
Windows XP SP2 and Windows Server 2003 SP1 included a heavy emphasis on security. As such, many of the default Windows programs were opted-in to DEP via the Application Compatibility database. To explore which programs opt-in to DEP on Windows XP SP2 or Windows Server 2003 SP1 you can download and install the latest Application Compatibility Toolkit and browse the main system database under the 'Windows Components' subset of applications.
All Windows XP SP2 applications opt-in to DEP if in category “Windows Components” with “AddProcessParametersFlags" compatibility fix applied:
The Windows Server 2003 SP1 default system wide policy is “OptOut”. That means all processes that do not explicitly opt-out will have DEP enabled. If the system-wide policy is changed, an application could still have DEP enabled by using the EnableDEP compatibility fix as shown below:
These compatibility fixes set the PEB's ProcessParameters value to 0x00020000, causing Windows XP SP2 and Windows Server 2003 SP1 to opt a process in to DEP. We found 305 processes opted-in to DEP on Windows XP SP2 and Windows Server 2003 SP1 via the main application compatibility database (%windir%\AppPatch\sysmain.sdb) using this particular compatibility fix. We have attached the list of processes at the bottom of the blog.
New Per-Process DEP options on Windows Vista, Windows Server 2008 and newer operating systems
Microsoft has introduced options on newer operating systems to opt a process in to DEP.
/NXCOMPAT linker switch
On Vista and newer operating systems, processes linked with the /NXCOMPAT option are opted-in to DEP by default. Developers of 3rd party applications that want to take advantage of this mitigation technology can re-link their applications using the Visual C++ 2003 or newer version of the linker by passing in the “/NXCOMPAT” flag. This will cause the linker to emit a binary that declares that it supports DEP via an optional image header field supported on Vista and later operating systems. You can determine whether a process has been linked with the /NXCOMPAT linker switch using dumpbin.exe (which ships with Visual Studio):
C:\Windows\System32>dumpbin /headers dllhost.exeMicrosoft (R) COFF/PE Dumper Version 9.00.21022.08Copyright (C) Microsoft Corporation. All rights reserved.Dump of file dllhost.exePE signature foundFile Type: EXECUTABLE IMAGEFILE HEADER VALUES 8664 machine (x64) 5 number of sections 4549BBFF time date stamp Thu Nov 02 05:35:59 2006 0 file pointer to symbol table 0 number of symbols F0 size of optional header 22 characteristics Executable Application can handle large (>2GB) addressesOPTIONAL HEADER VALUES 20B magic # (PE32+) 8.00 linker version 1400 size of code 1000 size of initialized data 0 size of uninitialized data 1818 entry point (0000000100001818) 1000 base of code 100000000 image base (0000000100000000 to 0000000100006FFF) 1000 section alignment 200 file alignment 6.00 operating system version 6.00 image version 6.00 subsystem version 0 Win32 version 7000 size of image 400 size of headers E1C5 checksum 2 subsystem (Windows GUI) 8140 DLL characteristics Dynamic base NX compatible Terminal Server Aware
Windows Vista and Windows Server 2008 can also force a process to use DEP using the ExecuteOptions registry setting. ExecuteOptions can force a process to use DEP without changing the system-wide policy. Processes opted-in to DEP using the ExecuteOptions registry setting will be DEP-enabled for the life of the process (DEP cannot be turned off via any API calls). Compared to the system-wide Opt-In / Opt-Out approach, this could be seen as a disadvantage as discussed above regarding “ATL thunk emulation” when it comes to application compatibility. “ATL thunk emulation” is not used when a process is forced to use DEP via either the ExecuteOptions registry setting or /NXCOMPAT linker switch. Finally, the Windows Compatibility Database contains a list of DLLs that are known to be incompatible with DEP and when this registry setting is used, since DEP cannot be disabled for the process by the compatibility infrastructure in Windows, DEP related crashes may result if applications attempt to load DLLs that are not compatible with DEP.
Microsoft encourages 3rd party ISVs to support DEP (and other exploit mitigation technologies). The latest versions of Acrobat, Flash, QuickTime, and Sun’s Java runtime (JRE 6 Update 12) all support DEP. For more information on how to avoid ATL related DEP crashes when DEP is enabled for a process, refer to http://support.microsoft.com/kb/948468.
SetProcessDEPPolicy API
Finally, a new way of opting-in to DEP is available on our latest versions of Windows. Windows Vista SP1, Windows Server 2008 and Windows XP SP3 includ the SetProcessDEPPolicy API to allow an application to opt-in to DEP programmatically without /NXCOMPAT or being marked up in the appcompat database or registry. Exposing an API not only makes it easier for developers to opt-in to DEP but when using this API, ATL thunk emulation is performed and processes using older versions of ATL should not crash due to DEP violations. For example, Internet Explorer 8 takes advantage of this new functionality.
In part two of this series, we’ll demonstrate how to change an application’s DEP policy to mitigate a real-world attack.
- Robert Hensing, MSRC Engineering
*Postings are provided "AS IS" with no warranties, and confers no rights.*
Today we released Security Advisory 2501696 to alert customers to a publicly disclosed vulnerability in the MHTML protocol handler. This vulnerability could allow attackers to construct malicious links pointing to HTML documents that, when clicked, would render the targeted document and reflected script in the security context of the user and target location. The end result of this type of vulnerability is script encoded within the link executed in the context of the target document or target web site.
How could I know if my machine is affected?
By default, the MHTML protocol handler is vulnerable on Windows XP and all later supported Windows versions. Internet Explorer is an attack vector, but because this is a Windows vulnerability, the version of IE is not relevant.
How could I protect client systems?
The security advisory lists steps to lock down the MHTML protocol handler for either all Internet Zone scenarios or to disable it altogether. We have previously blogged about the Network Protocol Lockdown workaround here. You can also click the button below to enable the Network Protocol Lockdown for mhtml: for all security zones:
More information about this FixIt at KB 2501696.
What would be the side-effect of MHTML lockdown workaround?
In our testing, the only side effect we have encountered is script execution and ActiveX being disabled within MHT documents. We expect that in most environments this will have limited impact. While MHTML is an important component of Windows, it is rarely used via mhtml: hyperlinks. Most often, MHTML is used behind the scenes, and those scenarios would not be impacted by the network protocol lockdown. In fact, if there is no script content in the MHT file, the MHT file would be displayed normally without any issue. Finally, for legitimate MHT files with script content that you would like to be rendered in IE, users can click the information bar and select “Allow All Protocols”, as shown below.
Doing so would temporarily allow the script content in the MHT file, and thus keep MHT files rendered correctly. Please note here that selecting “Allow All Protocols” will not undo the MHTML workaround permanently.
How can I know whether my service is at risk?
Any service that allows user input to be reflected back to the user could be affected by this issue. However the impact of scripting injected into a service is dependent on how the service itself is implemented. In this way, the impact is the same a server-side cross-site scripting issue but the vulnerability lies in the client.
What actions could service provider owners take?
First, please recommend that your customers apply the client-side workaround in the Security Advisory. This will prevent customers from being affected no matter how an attacker chooses to craft the link.
There are potential server-side workarounds that a service owner could employ. We’re working with service providers like Google and others as we explore these options. Some of these ideas are listed below. Each of these approaches is worth exploring and we continue to do so. However, they may be difficult for websites to implement comprehensively. For example, while newline filtering might be introduced in certain scenarios, low-level HTTP error response pages could reflect data in a way that is difficult to identify and mitigate. Each of the ideas are intended to break the parsing of MIME content and include:
Additionally, client/server interactions and decoding behavior may mean that in certain configurations these approaches are not fully effective.
We will continue to investigate server-side workarounds, and will continue to update with guidance as more are discovered. However, for the reasons above we recommend using the client-side workaround listed in the advisory, which can block exploits regardless of the service.
How can I test that a client system is protected?
Here are the steps to set up a test to ensure that a machine on which the workaround is enabled is protected from this vulnerability.
Step 1: Create the test.mht with the following content:
From: "Test"Subject: Date: Mon, 1 Jan 1111 11:11:11 -0800MIME-Version: 1.0Content-Type: text/html; charset="utf-8"Content-Transfer-Encoding: quoted-printableX-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 =EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML><HEAD><META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type><SCRIPT>function foo(){alert("hello");}</SCRIPT> <META name=3DGENERATOR content=3D"MSHTML 8.00.7600.16700"></HEAD><BODY onload=3Dfoo()>test MHTML protocol </BODY></HTML>
From: "Test"
Subject:
Date: Mon, 1 Jan 1111 11:11:11 -0800
MIME-Version: 1.0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543
=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dutf-8" http-equiv=3DContent-Type>
<SCRIPT>
function foo()
{
alert("hello");
}
</SCRIPT>
<META name=3DGENERATOR content=3D"MSHTML 8.00.7600.16700"></HEAD>
<BODY onload=3Dfoo()>test MHTML protocol </BODY></HTML>
Step 2: Upload the test.mht to a web server.
Before applying the workaround, when you navigate to Error! Hyperlink reference not valid., the following screen pops up:
As shown, the script within MHTML content is running.
After applying the workaround and restarting IE, when you navigate to Error! Hyperlink reference not valid., the following screen pops up:
The information bar indicates that the MHTML protocol is locked down so the script is not allowed to run.
- Dave Ross and Chengyun Chu, MSRC Engineering
Since our last MSRC blog post, we’ve received questions on the nature of the cryptographic attack we saw in the complex, targeted malware known as Flame. This blog summarizes what our research revealed and why we made the decision to release Security Advisory 2718704 on Sunday night PDT. In short, by default the attacker’s certificate would not work on Windows Vista or more recent versions of Windows. They had to perform a collision attack to forge a certificate that would be valid for code signing on Windows Vista or more recent versions of Windows. On systems that pre-date Windows Vista, an attack is possible without an MD5 hash collision. This certificate and all certificates from the involved certificate authorities were invalidated in Security Advisory 2718704. We continue to encourage all customers who are not installing updates automatically to do so immediately.
Mysterious Missing Extensions
When we first examined the Flame malware, we saw a file that had a valid digital signature that chained up to a Microsoft Root authority. As we reviewed this certificate, we noticed several irregularities. First, it had no X.509 extension fields, which was not consistent with the certificates we issued from the Terminal Server licensing infrastructure. We expected to find a Certificate Revocation List (CRL) Distribution Point (CDP) extension, an Authority Information Access (AIA) extension, and a “Microsoft Hydra” critical extension. All of these were absent.
When we examined the certificate with the Windows utility certutil.exe we saw a different story emerge.
> certutil.exe -dump MS.cer X509 Certificate: Version: 3 Serial Number: 1b7e Signature Algorithm: Algorithm ObjectId: 1.3.14.3.2.3 md5RSA Algorithm Parameters: 05 00 Issuer: CN=Microsoft LSRA PA DC=partners DC=extranet DC=microsoft DC=com NotBefore: 2/19/2010 2:48 PM NotAfter: 2/19/2012 2:48 PM Subject: CN=MS Public Key Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN) Algorithm Parameters: 05 00 Public Key Length: 2048 bits Public Key: UnusedBits = 0 0000 30 82 01 0a 02 82 01 01 00 a6 89 43 6f c6 ca 9d 0010 42 ad bd 28 d5 46 49 e0 55 f2 cc 38 e0 3d c0 7c 0020 ba 1d ca bb 92 c4 be 4c 5f 1a f9 d6 42 4b 34 0b 0030 2f 8a ac cb 97 31 ef 76 2f c3 85 af 95 93 47 46 0040 f6 ff 7c ca df c8 f9 d0 6a ec df 0e 91 55 23 ab 0050 64 06 90 d3 37 83 a8 0e 3e 5e 7f 77 35 66 74 20 0060 87 42 1f 25 17 8a d5 28 05 38 05 c8 48 6d 63 76 0070 3e fd 5a 11 67 07 09 6d 98 a3 08 4a f1 11 7f 80 0080 a7 4e 37 d4 f0 0e 34 7a d5 ba 83 ad 60 1e 57 44 0090 65 50 72 cd af 1e d0 1e 30 c2 eb 6a 51 e2 aa 54 00a0 85 57 fa 9c b1 59 e8 24 5e d4 38 d3 56 81 68 d5 00b0 05 8b 48 25 92 a2 11 1b e8 51 54 d9 d9 04 60 ee 00c0 1c fb 6a ec f0 6e 38 bb ad da 35 87 63 74 86 ef 00d0 1f cd 80 92 a2 98 3a 97 9a bd 35 d1 7d 2e 3a 47 00e0 04 48 17 74 db a3 67 d9 82 78 e0 77 2c cc ac 39 00f0 61 a6 d8 9d aa fc de 6f 60 4c 7c 73 07 31 93 2f 0100 67 28 4a 7e d1 ae 4c 42 dd 02 03 01 00 01 Issuer Unique Id:
0000 6a 4c e0 1f f5 91 69 b2 74 36 f0 7f 7b 4b 7b c6 jL....i.t6..{K{. 0010 be eb 3f 9f 98 3d a3 84 87 54 7e 72 87 71 25 4b ..?..=...T~r.q%K 0020 68 35 ae 65 bd 6c 8f dc 8d ac c4 e8 98 92 de dc h5.e.l.......... 0030 53 62 f5 72 6a 25 27 a3 12 46 eb 7f 6d 58 cd 30 Sb.rj%'..F..mX.0 0040 83 d7 7a 85 b8 48 e6 0e 01 11 68 65 7d 53 38 0b ..z..H....he}S8. 0050 40 f4 3b 68 43 59 c1 3c 05 c3 40 26 9d 51 97 e2 @.;hCY....@..Q.. 0060 eb 2e b8 c2 19 6e 4e 94 46 3b d8 d4 fd 0d 00 d1 .....nN.F;...... 0070 68 fa df f3 fa 18 8a 7c 65 9b da 23 11 9f 16 a6 h......|e..#.... 0080 8b 23 24 88 87 22 69 19 c2 11 ea 9d 36 81 ad fb .#$.."i.....6... 0090 e8 8b d2 d0 eb 06 f2 1a 86 8d c6 84 f3 88 c5 e0 ................ 00a0 d9 64 c6 48 95 d4 be d3 54 48 91 e6 6c e9 1e 33 .d.H....TH..l..3 00b0 97 15 42 ee b4 6d 1f 15 0b 27 dd 08 bb 81 de b6 ..B..m...'...... 00c0 96 16 39 d9 26 44 6a 5f d1 6b 3f 12 71 dc f0 99 ..9.&Dj_.k?.q... 00d0 62 d2 43 14 58 f8 6e f8 22 35 d2 90 f7 fd 93 6a b.C.X.n."5.....j 00e0 c4 49 b8 cb 0c e9 65 a8 f7 22 b5 f2 05 19 20 ef .I....e..".... . 00f0 25 63 c7 b3 97 4a 82 3e b2 e3 ee b4 5e cb 1d b3 %c...J.>....^... 0100 59 8f 8d f4 79 01 b1 b6 68 89 14 b4 8f 9d 60 d7 Y...y...h.....`. 0110 71 a5 3d 95 02 03 01 00 01 a3 82 02 5a 30 82 02 q.=.........Z0.. 0120 56 30 1d 06 03 55 1d 0e 04 16 04 14 9a 9a 5d 77 V0...U........]w 0130 bd 84 66 a4 f1 de 18 10 1b 6e 67 a5 97 c1 14 87 ..f......ng..... 0140 30 1f 06 03 55 1d 23 04 18 30 16 80 14 75 e8 03 0...U.#..0...u.. 0150 58 5d fb 65 e4 d9 a6 ac 17 b6 03 7e 47 ad 2e 81 X].e.......~G... 0160 af 30 81 c2 06 03 55 1d 1f 04 81 ba 30 81 b7 30 .0....U.....0..0 0170 81 b4 a0 81 b1 a0 81 ae 86 56 68 74 74 70 3a 2f .........Vhttp:/ 0180 2f 74 6b 78 70 61 73 72 76 33 36 2e 70 61 72 74 /tkxpasrv36.part 0190 6e 65 72 73 2e 65 78 74 72 61 6e 65 74 2e 6d 69 ners.extranet.mi 01a0 63 72 6f 73 6f 66 74 2e 63 6f 6d 2f 43 65 72 74 crosoft.com/Cert 01b0 45 6e 72 6f 6c 6c 2f 4d 69 63 72 6f 73 6f 66 74 Enroll/Microsoft 01c0 25 32 30 4c 53 52 41 25 32 30 50 41 2e 63 72 6c %20LSRA%20PA.crl 01d0 86 54 66 69 6c 65 3a 2f 2f 5c 5c 74 6b 78 70 61 .Tfile://\\tkxpa 01e0 73 72 76 33 36 2e 70 61 72 74 6e 65 72 73 2e 65 srv36.partners.e 01f0 78 74 72 61 6e 65 74 2e 6d 69 63 72 6f 73 6f 66 xtranet.microsof 0200 74 2e 63 6f 6d 5c 43 65 72 74 45 6e 72 6f 6c 6c t.com\CertEnroll 0210 5c 4d 69 63 72 6f 73 6f 66 74 20 4c 53 52 41 20 \Microsoft LSRA 0220 50 41 2e 63 72 6c 30 82 01 31 06 08 2b 06 01 05 PA.crl0..1..+... 0230 05 07 01 01 04 82 01 23 30 82 01 1f 30 81 8e 06 .......#0...0... 0240 08 2b 06 01 05 05 07 30 02 86 81 81 68 74 74 70 .+.....0....http 0250 3a 2f 2f 74 6b 78 70 61 73 72 76 33 36 2e 70 61 ://tkxpasrv36.pa 0260 72 74 6e 65 72 73 2e 65 78 74 72 61 6e 65 74 2e rtners.extranet. 0270 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 2f 43 65 microsoft.com/Ce 0280 72 74 45 6e 72 6f 6c 6c 2f 74 6b 78 70 61 73 72 rtEnroll/tkxpasr 0290 76 33 36 2e 70 61 72 74 6e 65 72 73 2e 65 78 74 v36.partners.ext 02a0 72 61 6e 65 74 2e 6d 69 63 72 6f 73 6f 66 74 2e ranet.microsoft. 02b0 63 6f 6d 5f 4d 69 63 72 6f 73 6f 66 74 25 32 30 com_Microsoft%20 02c0 4c 53 52 41 25 32 30 50 41 2e 63 72 74 30 81 8b LSRA%20PA.crt0.. 02d0 06 08 2b 06 01 05 05 07 30 02 86 7f 66 69 6c 65 ..+.....0...file 02e0 3a 2f 2f 5c 5c 74 6b 78 70 61 73 72 76 33 36 2e ://\\tkxpasrv36. 02f0 70 61 72 74 6e 65 72 73 2e 65 78 74 72 61 6e 65 partners.extrane 0300 74 2e 6d 69 63 72 6f 73 6f 66 74 2e 63 6f 6d 5c t.microsoft.com\ 0310 43 65 72 74 45 6e 72 6f 6c 6c 5c 74 6b 78 70 61 CertEnroll\tkxpa 0320 73 72 76 33 36 2e 70 61 72 74 6e 65 72 73 2e 65 srv36.partners.e 0330 78 74 72 61 6e 65 74 2e 6d 69 63 72 6f 73 6f 66 xtranet.microsof 0340 74 2e 63 6f 6d 5f 4d 69 63 72 6f 73 6f 66 74 20 t.com_Microsoft 0350 4c 53 52 41 20 50 41 2e 63 72 74 30 1a 06 08 2b LSRA PA.crt0...+ 0360 06 01 04 01 82 37 12 01 01 ff 04 0b 16 09 54 4c .....7........TL 0370 53 7e 42 41 53 49 43 S~BASIC Certificate Extensions: 0 Signature Algorithm: Algorithm ObjectId: 1.2.840.113549.1.1.4 md5RSA Algorithm Parameters: 05 00 Signature: UnusedBits=0 0000 96 b9 a2 43 a1 dd 17 48 b9 d6 ec a7 b7 71 a0 01 0010 63 0f f4 bc e7 c3 03 d3 c2 48 72 7f 85 90 b3 70 0020 17 d1 50 20 f7 8c ce aa d1 fe 68 fa 64 b3 8d 00 0030 b5 38 4a c9 0d 96 1f 6b 42 1f a9 44 05 c5 12 b1 0040 24 26 fd 19 bb 74 6f bf 16 ef 35 5c 4c d1 dd 30 0050 ac 64 3c e7 4f 10 14 49 d7 0e 20 c8 ac 36 af 01 0060 ca 80 ff 04 fb 9d 79 56 4b 8a 7b 11 4e d8 e2 97 0070 7e 1d 87 cd e5 e1 b1 3e e6 5f d0 9c 62 6d f6 8c 0080 dc ca e3 4a f2 e5 5c 29 bb 49 66 68 17 02 75 70 0090 71 7c f1 78 64 d6 ed db 85 f3 67 ee fb e8 57 50 00a0 35 94 7b 71 4d f7 b5 12 e5 bb e8 2b 40 de ec 5f 00b0 29 af bb 7e c9 0b 97 b2 d2 46 dc 77 ef f4 f5 3f 00c0 07 48 ab 25 c3 8a f3 5d e1 23 8b c9 49 7d c0 8b 00d0 c7 52 ca 5c 7f 29 4b 9b fd 5d fe 71 a1 34 50 00 00e0 10 a5 86 04 94 e8 07 b7 4b 58 05 4c 67 ca 76 ca 00f0 5a cc cf 27 d5 a4 04 a8 31 71 83 72 73 ab 4a 00 Non-root Certificate Key Id Hash(rfc-sha1): d6 11 4d 36 37 9e 6e e3 9e 9f 2f 61 88 98 f2 8d 56 38 69 c9 Key Id Hash(sha1): 38 ea d5 44 de a9 3f 76 78 43 6e 95 f0 2d 58 82 42 f6 55 dd Cert Hash(md5): ea 99 4e 63 fe 99 06 60 02 c9 9b 09 e3 50 06 2e Cert Hash(sha1): 1d 19 0f ac f0 6e 13 3e 87 54 e5 64 c7 6c 17 da 8f 56 6f bb CertUtil: -dump command completed successfully.
This certificate had an unusual field—Issuer Unique Identifier. This field is obsolete and not used by Microsoft software or infrastructure. When we examined this field in detail, we realized that it did not contain random data, but rather it had structure. It contained a correctly encoded X.509V3 extension field starting at byte offset 0x119 into the Issuer Unique Identifier field. Here are some of the “missing” extensions we extracted from it:
http://tkxpasrv36.partners.extranet.microsoft.com/CertEnroll/
tkxpasrv36.partners.extranet.microsoft.com_Microsoft%20LSRA%20PA.crt
The “Critical” Link
The Microsoft Hydra extension is marked as "critical" and this is crucial to why the attacker needed to perform a collision attack. In X.509 parlance, if an extension is essential to the proper validation of a certificate chain, it must be marked critical. The behavior of a crypto library upon encountering an extension marked critical that it does not understand is to fail validation. The Crypto API in Window Vista and later versions of Windows behave this way and the certificates fail validation on those platforms. Hence, if the attacker wanted a certificate that worked on all versions of Windows they needed to remove this field.
Circumstances that Collided
To remove the critical extension, the attacker took advantage of a number of circumstances to perform a collision attack:
An essential part of performing a collision attack is that the attacker needs to be able to predict completely the certificate content that will be signed by the CA. Because of the predictable serial numbers, the attacker can perform a set of certificate enrollments that reveal the likely serial number when they perform their collision attack. This is also called a "chosen prefix collision attack" [2]. The attacker can then apply the collision algorithm documented by Sotirov et. al. [3] to create a forged certificate that removes the critical Microsoft Hydra extension and still matches the MD5 hash of the legitimate certificate signed by the CA.
Quick Response to Extinguish Flame and Copycats
Without this collision attack, it would have been possible to sign code that would validate on systems pre-dating Windows Vista, but that signed code would fail validation on Windows Vista and above. After this attack, the attacker had a certificate that could be used to sign code that chained up to the Microsoft Root Authority and worked on all versions of Windows. Given the risk for copycat attacks on systems pre-dating Windows Vista, without the complexity of a collision attack, we took action to release an out-of-band update.
Hardening of the Terminal Server Licensing Certificate Infrastructure
We also made a number of changes to the Terminal Server licensing infrastructure to minimize risk in the future:
Microsoft takes the security of its customers seriously; therefore we took the swiftest action that would protect the largest number of customers first. We will continue to take the necessary actions to help protect our customers.
Thanks to John Lambert, Magnus Nystrom, David Molnar, and special thanks to Tolga Acar for their contributions to this investigation.
References
[1] Microsoft, “Object IDs associated with Microsoft cryptography”, http://support.microsoft.com/kb/287547/pt-b, March 1, 2007.
[2] M. Stevens and A. Lenstra and B. de Weger. "Chosen-prefix Collisions for MD5 and Colliding X.509 Certificates for Different Identities", http://www.win.tue.nl/hashclash/EC07v2.0.pdf, http://www.win.tue.nl/hashclash/ChosenPrefixCollisions/, June 16, 2009.
[3] A.Sotirov, M.Stevens, J.Applebaum, A.Lenstra, D.Molnar, D.A. Osvik, B. de Weger, “MD5 considered harmful today”, http://www.win.tue.nl/hashclash/rogue-ca/, Dec.30, 2008.
Recently we announced the Internet Explorer 8 XSS Filter and talked a bit about its design philosophy. This post will describe the filter’s architecture and implementation in more detail.
Design Goals
The Internet Explorer 8 XSS Filter is intended to mitigate reflected / “Type-1” XSS vulnerabilities in a way that does not “break the web.” Our baseline approach needs to satisfy the following three conditions:
In implementing the filter, we made decisions to best meet the above goals.
Practical Considerations
The XSS Filter must be in a position to observe and intercept requests and responses from the browser to the web server. In Internet Explorer, this is possible via a MIME Filter. The prototype implementation of the XSS Filter was in fact implemented as a MIME Filter, but for performance it was moved into MSHTML (the browser rendering engine) when we built Internet Explorer 8.
Architecture / Implementation
Figure A: XSS Filter Hosted in Internet Explorer 8
Figure B: XSS Filter Logic Flow
Figures A and B depict a high level view of the XSS Filter. Let’s dig into the details.
For performance, the XSS Filter only takes effect for navigations within the browser which can result in the execution of script. There’s no need for the XSS Filter to operate on resources such as images (as long as they are truly images when rendered by Internet Explorer).
The filter also checks the source and destination URLs of navigations within the browser. If the navigation is cross-site, or the source cannot be determined (ex: the user clicked on a Favorite) then the navigation is filtered.
The XSS Filter can be enabled/disabled per-zone. For the Beta 2 release the XSS Filter will be enabled for the Internet and Restricted Sites zones, but not the Local Intranet zone. Administrators can choose to enable or disable the XSS Filter for any zone via group policy.
The core XSS Filter engine operates in two stages:
1. HTTP GET / POST data is scanned to match a set of heuristics that identify XSS attack vectors. Matches are used to build signatures to identify markup/script as replayed in the HTTP response. 2. Generated signatures are used to scan the HTTP response. Markup/script which has been identified by a signature is neutered to block execution.
1. HTTP GET / POST data is scanned to match a set of heuristics that identify XSS attack vectors. Matches are used to build signatures to identify markup/script as replayed in the HTTP response.
2. Generated signatures are used to scan the HTTP response. Markup/script which has been identified by a signature is neutered to block execution.
Validating that an XSS attack has actually been replayed into the response maximizes XSS detection reliability – “reflected XSS” requires reflection. Having the capability to identify and neuter the replayed markup/script allows the filter to avoid overbearing mitigations such as querying the user, modifying outgoing requests, or blocking entire pages.
Our approach is performant in that the only notable “heavy lifting” is the scan of the HTTP response body, which will only occur in cases where signatures are generated. Signature generation is highly indicative of an actual XSS attack and it is rare during everyday browsing.
Fun with Regular Expressions – Part 1: Heuristics
If a navigation has met the criteria for filtering, the filter takes the URL as well as any POST data associated with the request, decodes it as necessary, and uses regular expressions to identify XSS attack vectors. These case-insensitive patterns are the filtering heuristics. Here is an example:
{<sc{r}ipt.*src[whitespace or forward-slash]*=}
This heuristic will identify SCRIPT tags with SRC attributes. While SCRIPT tags may be common in HTML, their presence in a URL or POST data is one indication of an XSS attack.
In the example heuristic above, note that the character within the inner braces is what we will refer to here as the neuter character. Each heuristic can have one or more neuter characters. Each neuter character, in this case ‘r’, indicates a character that will eventually be modified by the filter in the HTTP response body in order to block the XSS attack. The ‘#’ character is used as the neuter replacement character – it is effective in breaking HTML elements as well as script blocks into which it is injected.
The selection of neuter characters in any heuristic is very important. The wrong neuter characters chosen for a heuristic can subvert the filter. As an example, picking a quote symbol as a neuter character would cause the filter to neuter quotes. A smart attacker could use this behavior to force a match and neuter a quote on a page, intending to enable an XSS attack that wouldn’t otherwise be possible.
A match on a heuristic does not in and of itself trigger the filter to detect XSS. Rather, it indicates to the filter that the HTTP response body must be examined to validate that the script in the input URL or POST data was in fact replayed to the output page.
The decoding process briefly mentioned above is flexible and can also account for artifacts of various web platforms. As necessary, the filter generates additional signatures (see below) based on alternate interpretations of the same input data. So for example, because malformed URLEncoded characters may be handled differently for different web platforms, the filter must be capable of building proper signatures regardless.
Fun with Regular Expressions – Part 2: Signatures
As heuristics are matched, the filter generates one signature for each match. A signature is a new regular expression that will be used to scan the HTTP response body for the replayed suspect input. The neuter replacement character is temporarily put into place in the input after a signature is matched. Matching then continues for a heuristic until no more matches can be found in the input. Signatures are generated for URLs without neuter replacement characters in place. Otherwise the signatures would themselves contain neuter replacement characters and they would not correctly match attacks present in the HTTP response.
With each heuristic, a list of safe characters is provided. For the heuristic that detects script tags, the safe characters are the greater-than and less-than characters and also alpha-numerics. The safe characters effectively form the essence of the XSS attack the filter is attempting to identify.
If the filter were to simply search for a match verbatim it would not necessarily find one. The web server may incidentally remove or translate particular characters from the request as it is replayed. It is in fact common and attackers can use this behavior to their advantage.
Safe characters are restricted to the “low-ASCII” range (0x00 – 0x7F) so that we can essentially remain character-set agnostic. Character sets that are capable of alternate “low-ASCII” encodings (eg: UTF-7) are not currently special-cased, however some new restrictions are being placed on the general usage of these character sets moving forward. (These changes are outside the scope of this blog post but stay tuned to my blog for more details).
Here is an example match for the heuristic that detects script tags:
<SCRIPT src=”http://www.fabrikam.com/evil.js”
The signature generated for this match would be:
<SC{R}IPT¤src¤¤http¤¤¤www¤fabrikam¤com¤evil¤js¤
Each ¤ in the signature indicates a non-safe character from the original match. A sequence of zero to N unspecified characters will match any ¤. (Currently N is 10)
If no signatures have been generated for a particular page then the filter permits the page to load without modification – no XSS was detected.
However, if signatures do exist, the filter scans the HTTP response body for each signature. Once identified, the filter records exactly which character(s) must be neutered, as indicated in the signature by the characters within the braces. Once the signature list is fully processed the neuter replacement characters are put into place and the HTTP response body is passed on to render in the browser.
The page will render normally except the information bar will notify the user that the page was modified and the XSS attack will be disabled.
XSS Filter Limitations
Like all security mitigation and protection technologies, the XSS Filter’s approach does have limitations, being that it is a pragmatic balance between application compatibility, security, and performance. Some examples:
These are all issues that undoubtedly occur on real web sites. The XSS Filter design philosophy dictates that we make a distinction between issues that generally enable the XSS Filter to be bypassed vs. issues that apply only in certain situations. The issues above, while very notable, clearly fall into the latter category. As time goes on we will continue to enhance the XSS Filter to maximize its effectiveness, however we will not compromise web site compatibility in the process.
It is challenging to mitigate XSS in a way that balances the needs of compatibility, security, and performance. The XSS Filter’s two-stage approach helps us achieve these goals by very specifically targeting reflected (“Type-1”) XSS attacks. This architecture allows us to mitigate the XSS most commonly found across the web today, by default, for users of Internet Explorer 8.
- David Ross, SVRD Blogger
August 19, 2008, 4:15pm: Updated with correct date
The new Internet Explorer security vulnerability described by Microsoft Security Advisory 979352 has received a lot of interest over the past few days. The Internet Explorer team is hard at work preparing a comprehensive security update to address the vulnerability and the MSRC announced today that as soon as the update is ready for broad distribution, it will be released.
We have heard several questions from customers attempting to protect their environment in the meantime. Most questions have been around Data Execution Prevention (DEP), a mitigation we discussed in our previous blog post. To help you better understand DEP specifically as it relates to Internet Explorer 8, we have prepared the following video where I discuss some of the higher level concepts:
To summarize:
Which versions of Internet Explorer have enabled DEP by default?
Hardware-enforced DEP is enabled by default for Internet Explorer on the following platforms:
· Internet Explorer 8 on Windows XP Service Pack 3,
· Internet Explorer 8 on Windows Vista Service Pack 1 and later,
· Internet Explorer 8 on Windows Server 2008, and
· Internet Explorer 8 on Windows 7.
Windows 2000 has no support for hardware-enforced DEP. Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, and Windows Vista support hardware-enforced DEP do not have the SetProcessDEPPolicy API that Internet Explorer 8 uses to enable DEP.
How can users of other versions of Windows or Internet Explorer enable DEP?
Windows XP SP2 and Windows Vista RTM users can click this button to launch an MSI that will enable DEP for Internet Explorer.
How can you determine whether hardware-enforced DEP is available with your hardware?
Microsoft KB 912923 describes in more detail how to determine that hardware DEP is available and configured on your computer.
What is the difference between "Software DEP" and hardware-enforced DEP (/NX)?
"Software DEP" is unfortunately really not DEP at all. "Software DEP" is just another name for /SAFESEH [MSDN link]. Unfortunately, /SAFESEH is not an effective mitigation for this vulnerability. Only hardware-enforced DEP disrupts exploits attempting to abuse this vulnerability.
Does IE’s DEP behave differently in the Intranet Zone (as compared to the Internet Zone)?
DEP itself is enabled per process, regardless of application-layer content. However, a well-known DEP bypass is used by attackers to mark pages executable using .NET classes. IE8 does not allow these .NET class to load in the Internet Zone. In the Intranet Zone, the .NET classes are allowed to load. Therefore, an attacker capable of hosting content on your corporate network may be able to bypass DEP and successfully exploit this vulnerability.
We hope that helps answer questions you may have had about DEP.
Jonathan Ness
*This posting is provided "AS IS" with no warranties, and confers no rights*