MSHTML, a.k.a. Trident, is the Internet Explorer browser rendering engine. MSHTML is a great solution for rendering HTML content, either in the context of a web browser, or simply to display rich UI in an application. You are likely not even aware of some of the many ways MSHTML is hosted within Windows and third party applications. For example, the Windows XP Add/Remove Programs control panel is implemented using MSHTML. Care must be taken in order to host MSHTML with appropriate security. This FAQ will help you avoid making some common MSHTML hosting mistakes.
MSHTML may be hosted directly or via SHDOCVW. The information in this FAQ applies to either hosting scenario unless otherwise specified.
The MSHTML Host Security FAQ – Part I
How do I evaluate the level of risk posed by my MSHTML hosting scenario?
Here’s how to quickly evaluate the risk of any MSHTML hosting scenario:
Risk level 3: No arbitrary content There is low risk when MSHTML is simply displaying static content loaded from a local source (Ex: A resource file, HTML on the local drive, etc.). That is not to say there is zero risk. For example, think about any possibility that an attacker may force navigation of the host somehow, perhaps using a command line parameter passed via a registered protocol handler.
Risk level 2: Controlled content It is possible to lock a MSHTML instance to a single site. However, when this is implemented without SSL, MitM (Man-in-the-middle) or DNS poisoning attacks can enable execution of script within the hosted MSHTML instance.
Even when SSL is used (and the certificate is validated), it can still be problematic to ensure that content rendered only comes from an “unhackable” / bulletproof site. Even if the source were secure, content coming from the source still should not have authorization to automatically execute arbitrary code on the user’s machine. This is in line with the general security principal of least privilege. Really, all content should execute securely within the hosted MSHTML instance, no matter where the content appears to have originated. That being said, if the content source is locked down sufficiently, this does at least serve as a mitigating factor for potential vulnerabilities.
Risk level 1: Fully arbitrary content In this case, the MSHTML host should not take any shortcuts in enforcing the same security as is applied within the Internet Explorer web browser. Otherwise, attacks may be possible within the MSHTML host that wouldn’t otherwise be possible within Internet Explorer.
One mitigating factor may be that the navigation would have to occur within the MSHTML host. For example, using Visual Studio to navigate to web sites is not a very common usage scenario. If the Visual Studio MSHTML host has a vulnerability, it may not be very practical to exploit. Still, clearly it must not be possible for web content within Visual Studio’s MSHTML instance to run arbitrary code, read local files, etc.
Risk level 0: Fully arbitrary content available “zero-click” from e-mail or the web As an example, imagine a media player were to host MSHTML and allow arbitrary navigation. If certain security restrictions were in place in the browser but not in the media player hosting scenario, these restrictions could be immediately circumvented. (A media file presumably could cause the media player's MSHTML instance to navigate to an arbitrary web site.) Web browsers serve as the vector for many real-world attacks so this is a compelling attack scenario that must be avoided.
How do I offer advanced functionality to HTML within my hosting environment, safely?
It is often desirable to expose some special functionality to content running within the hosted MSHTML instance. Heed the guidance in the “Elevated Sandbox” section in Part II of the FAQ and resist the temptation to enable unsafe behavior (execution of arbitrary system commands, etc.) within your MSHTML instance.
Some of the common MSHTML extensibility mechanisms include:
How can my MSHTML host regulate the security policy applied by IE Security zones?
By default, MSHTML regulates security policy based on the calculated zone of the page it is rendering. This is often an issue for MSHTML hosts because while the model may make sense for the Internet Explorer browser, it doesn’t necessarily map to the MSHTML host’s security model unless care is taken.
Imagine a news reader application that downloads HTML to the local hard drive and then navigates a MSHTML instance to this downloaded content. Data from the Internet is now likely to render within the Local Machine Zone. Within the Local Machine Zone, the content has access to unsafe functionality enabling the execution of arbitrary code. In the browser, this may have been mitigated by Local Machine Zone Lockdown, however this would not apply to the news reader by default unless it were to opt-in to the appropriate Feature Control Key (FCK). To ensure application compatibility, Local Machine Zone Lockdown is not enabled for all MSHTML hosts by default.
The example above demonstrates why it is very important to understand the security policy applied by Internet Explorer Zones when a page is rendered within your MSHTML hosting environment.
Implementing a Security Manager The default Internet Explorer security policy very well may make sense for your MSHTML host. However, if it does not, be sure to implement a security manager. The browser policy that may be enforced using a security manager is a superset of what is available in the advanced zone options in Internet Explorer:
For example, a security manager can allow your host to disable all script yet only allow one specific ActiveX control to run. The policy flags that can be controlled from a security manager are called URL Actions and are defined in urlmon.h. Be aware that even if your security manager blocks script and ActiveX by default, there are likely other URL Actions to consider disabling. For example, your host may disable frames and active content, but without also disabling URLACTION_HTML_META_REFRESH it will still be possible for HTML to trigger automatic navigation.
Regardless of whether or not you implement a security manager, you may want to implement an Asynchronous Pluggable Protocol Handler (APP). It is possible for an APP to implement IInternetProtocolInfo and provide support for PARSE_SECURITY_URL and PARSE_SECURITY_DOMAIN in order to control the zone into which URLs are placed.
When implementing an APP for your Trident host, avoid registering it globally on the system if at all possible. Instead, load it dynamically at runtime only for your process. Registering it globally adds unnecessary attack surface to Internet Explorer. See “About Pluggable Protocols” here.
- David Ross, MSRC Engineering
*Postings are provided "AS IS" with no warranties, and confers no rights.*
Yesterday we noticed a blog post and securityfocus article about a potential new vulnerability in Microsoft GDI+ when parsing a specially-crafted EMF file. You might have heard about it referred to as ‘GpFont.SetData()’. We wanted to address some speculation about this EMF parsing bug.
First, our initial investigation shows that it is not exploitable for code execution. We are still investigating all the potential ways to hit this code but in all the common cases so far, our /GS mitigation is an effective defense-in-depth measure. The EMF parsing bug ends up writing 0x0000, a single Unicode 0 character, over the lower two bytes of the /GS security cookie. Only those two bytes are overwritten and the application is terminated due to the /GS failure.
Here’s where the issue occurs:
0:000> k ChildEBP RetAddr 0007e37c 4ec9e783 gdiplus!GpFont::SetData+0x6a 0007e3a0 4ec9e70f gdiplus!MetafilePlayer::AddObject+0x8f 0007e3b4 4ec9d1b5 gdiplus!ObjectEPR::Play+0x1a 0007e3d0 4ec9ce34 gdiplus!GdipPlayMetafileRecordCallback+0x35 0007e3fc 4ec9cd4e gdiplus!MetafilePlayer::EnumerateEmfPlusRecords+0x66 0007e414 77f2072f gdiplus!EnumEmfWithDownLevel+0x52 0007e490 4ec9e625 gdi32!bInternalPlayEMF+0x707 0007edd4 4eca0c90 gdiplus!MetafilePlayer::EnumerateEmfRecords+0xd7 0007ee70 4ec9e67f gdiplus!GpGraphics::EnumEmfPlusDual+0x27d 0007ef90 4ed03350 gdiplus!GpMetafile::EnumerateForPlayback+0x686 0007efc0 4ec9bb58 gdiplus!GpMetafile::Play+0x26
The gdiplus!GpFont::SetData code shows an obvious off-by-one bug. This was subsequently fixed before Vista shipped. Here’s the Windows XP code:
#define FamilyNameMax 32...WCHAR familyName[FamilyNameMax];... length = fontData->Length; // this comes from the EMF file...if (length > FamilyNameMax){ length = FamilyNameMax;}...// read in the familyName/dataUnicodeStringCopyCount (familyName, (WCHAR *)dataBuffer, length);familyName[length]=0;
Here’s what it looks like from the assembly:
gdiplus!GpFont::SetData: 4ecff9e9 8bff mov edi,edi 4ecff9eb 55 push ebp 4ecff9ec 8bec mov ebp,esp 4ecff9ee 83ec44 sub esp,44h 4ecff9f1 a10000dd4e mov eax,dword ptr [gdiplus!__security_cookie (4edd0000)] ds:0023:4edd0000=00006ea3 4ecff9f6 53 push ebx 4ecff9f7 8945fc mov dword ptr [ebp-4],eax // Security cookie saved in ebp-4 4ecff9fa 8b4508 mov eax,dword ptr [ebp+8]
You can see from the top of the function that the security cookie is 00006ea3. Now let's look lower.
4ecffa29 8b4804 mov ecx,dword ptr [eax+4] 4ecffa2c 894f10 mov dword ptr [edi+10h],ecx 4ecffa2f 8b4808 mov ecx,dword ptr [eax+8] 4ecffa32 894f18 mov dword ptr [edi+18h],ecx 4ecffa35 8b480c mov ecx,dword ptr [eax+0Ch] 4ecffa38 894f14 mov dword ptr [edi+14h],ecx 4ecffa3b 8b7014 mov esi,dword ptr [eax+14h] 4ecffa3e 8d4c3618 lea ecx,[esi+esi+18h] 4ecffa42 83c018 add eax,18h 4ecffa45 394d0c cmp dword ptr [ebp+0Ch],ecx 4ecffa48 0f8283000000 jb gdiplus!GpFont::SetData+0xe8 (4ecffad1) 4ecffa4e 83fe20 cmp esi,20h 4ecffa51 7603 jbe gdiplus!GpFont::SetData+0x6d (4ecffa56) 4ecffa53 6a20 push 20h 4ecffa55 5e pop esi 4ecffa56 56 push esi 4ecffa57 50 push eax 4ecffa58 8d45bc lea eax,[ebp-44h] //0x20 WCHAR buffer 4ecffa5b 50 push eax 4ecffa5c e8d7750600 call gdiplus!GpRuntime::UnicodeStringCopyCount (4ed67038) 4ecffa61 a15009dd4e mov eax,dword ptr [gdiplus!Globals::FontCollection (4edd0950)] 4ecffa66 66895c75bc mov word ptr [ebp+esi*2-44h],bx 4ecffa6b 8b7008 mov esi,dword ptr [eax+8] 4ecffa6e 395e08 cmp dword ptr [esi+8],ebx
If we break in just before that string copy, we see the following:
eax=00913658 ebx=00000000 ecx=00000020 edx=05aa010c esi=00000020 edi=0091c798 eip=4ecffa66 esp=0007e32c ebp=0007e37c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 gdiplus!GpFont::SetData+0x7d: 4ecffa66 66895c75bc mov word ptr [ebp+esi*2-44h],bx ss:0023:0007e378=6ea3
Remember from the assembly above that the security cookie was 00006ea3. Here’s how memory looks before the mov instruction:
0:000> dd ebp-0x10 0007e36c 44332211 001d0b0b 44332211 00006ea3 0007e37c 0007e3a0 4ec9e783 05aa00b4 00000024 0007e38c 0091e008 0091e008 00000030 0091e001 0007e39c 0091e008 0007e3b4 4ec9e70f 00000000 0007e3ac 05aa00b4 00000024 0007e3d0 4ec9d1b5 0007e3bc 0091e008 00004008 00000600 00000024 0007e3cc 05aa00a8 0007e3fc 4ec9ce34 00004008 0007e3dc 00000600 00000024 05aa00b4 0091e008
You can see the cookie on the stack protecting the return address. And then after the copy it is overwritten:
0:000> dd ebp-0x10 0007e36c 44332211 001d0b0b 44332211 00000000 0007e37c 0007e3a0 4ec9e783 05aa00b4 00000024 0007e38c 0091e008 0091e008 00000030 0091e001 0007e39c 0091e008 0007e3b4 4ec9e70f 00000000 0007e3ac 05aa00b4 00000024 0007e3d0 4ec9d1b5 0007e3bc 0091e008 00004008 00000600 00000024 0007e3cc 05aa00a8 0007e3fc 4ec9ce34 00004008 0007e3dc 00000600 00000024 05aa00b4 0091e008
As always, we encourage responsible disclosure of potential vulnerabilities. Best way to get ahold of us is secure@microsoft.com. Thanks.
- Jonathan Ness, MSRC Engineering
Last summer at BlackHat Vegas, Alexander Sotirov and Mark Dowd outlined several clever ways to bypass the Windows Vista defense-in-depth protection combination of DEP and ASLR in attacks targeting Internet Explorer. One approach they presented allowed attackers to use .NET framework DLL’s to allocate executable pages of memory at predictable locations within the iexplore.exe process. They were then able to demonstrate how .NET behavior could be combined with a separate exploitable memory corruption vulnerability to run arbitrary code. It was actually pretty brilliant. You can find the paper here.
We are always learning from the security community. The feedback we receive from the community is invaluable. It is usually a different view of our products that we can use to help protect customers. Last week, the IE team launched IE8 with an interesting mitigation that comes directly from the security community's feedback. The final release of Internet Explorer 8 on Windows Vista blocks the .NET DEP+ASLR bypass mechanism from malicious websites on the Internet. Specifically, IE8 created a new URLAction that regulates loading of the .NET MIME filter. By default, the URLAction prevents it from loading in the Internet and Restricted Sites Zones. The .NET MIME filter is allowed to load by default in the Intranet Zone.
IE8 is pretty cool technology. We have been using it internally now for a while. One of the great things about it is the layering of defenses on top of defenses. No browser is 100% secure but we are hoping if we keep adding defenses they will be harder and harder to exploit. We heard from security researchers and exploit writers at both CanSecWest last week and SOURCE Boston the week before that writing exploits for Windows Vista is “very, very hard” with all these mitigations to work around. We expect that blocking the .NET DEP+ASLR bypass will make it even harder.
We have smart engineers thinking all day every day about mitigations and testing ways to bypass our defense-in-depth approach to security. If you have an idea that you'd like to share, please email us at switech _at_ microsoft.com. Thanks!
In a previous post we noted some stack-based vulnerabilities, such as MS08-067, that GS was not designed to mitigate due to the degree of control available to an attacker. However, other vulnerabilities such as the ANI parsing vulnerability in MS07-017 would have been mitigated if the GS cookie protection had been applied more broadly. The strict_gs_check pragma was mentioned as one way of achieving broader coverage.
One downside of the strict GS heuristic is that it is very aggressive. It will GS protect any function that has an address-taken local variable (even an address-taken integer). MSEC undertook some basic code analysis and identified that a number of functions currently protected with a GS cookie were actually provably safe. The idea was born to give GS an overhaul as part of the Visual Studio 2010 release – Enhanced GS:
1. Enhancing the GS heuristic to consider a greater scope of local variables worthy of protection
2. Implement a new optimization that would remove cookies identified as unnecessary.
Any cookie increase is bound to lead to performance questions due both to the direct overhead of the extra cookie checks and indirect impact on inlining other aspects of code generation and optimization. The goal was for the resulting scheme to be applicable system-wide – as for the original GS work – rather than be a targeted approach such as the strict_gs_check code pragma.
The highest priority was to update the heuristic to protect data structures such as the ANIHEADER structure in MS07-017. There have been other security bulletins where pure data structures such as these have been overflowed. For example consider the structure involved in the Office Publisher vulnerability in MS06-054:
typedef struct _STTBF { ulong bMax; ulong ibstMac; ulong reserved3; ulong cbExtra; uchar fNoShrink; uchar wReserved2; ushort wReserved; } STTBF;
Protecting all structures would likely be too expensive in terms of the number of extra cookies that would result. We decided to increase the scope of the structures that GS would treat as potentially vulnerable to only those structures that contained no members of a pointer type. It seems less likely that a component would read in a pointer value to local memory from an untrusted file, compared to it reading document/media or some other kind of data. Thus the ANI structure in the previous post and the STTBF Publisher structure above are both covered by the enhanced GS heuristic in Visual Studio 2010. However a structure defined as follows is not:
typedef struct _MYSTRUCT { int bMin; int bMax; int bAverage; void *pSomePointer } MYSTRUCT;
In a similar vein, whereas the legacy GS heuristic only protects arrays where the element size is 1 or 2 bytes (such as chars and wchars), the Visual Studio 2010 enhanced GS heuristic protects any kind of array as long as the element type is not of pointer type.
char myStringBuffer[256]; // protected DWORD myIPAddresses[256]; // protected HANDLE myPointerTable[256]; // not protected
There are also a number of additional criteria: an array needs to have more than 2 elements in order to qualify, any structure including an array of the kind described above would be protected, and so on. However, the two examples above capture the main new cases that the enhanced GS heuristic is designed to cover.
It is also worth mentioning that any variable considered as potentially vulnerable under the legacy GS heuristic is also considered potentially vulnerable under the new heuristic. By carefully designing the heuristic around past security bulletin history and in tandem with performance measurements from internal product teams in Microsoft, we believe this to be truly deployable as an application-wide mitigation.
Just because a variable (due to its type or size) is considered potentially vulnerable does not mean that its use will necessarily lead to a vulnerability! This insight has led to a new compiler optimization that is planned for Visual Studio 2010. Specifically, the new optimization recognizes instances of safe variable usage and suppresses GS cookie emission in such instances.
For example the code snippet below would normally lead to the function being GS protected due to the presence of a character buffer.
STDAPI ConsumeData(BYTE *pbData) { BYTE Temp[MAX]; if (pbData) { ... memcpy (Temp, pbData, ARRAYSIZE(Temp)); ... }
Analysis of the use of the Temp buffer makes it clear that it can never be overflowed: its only use is in a memcpy instruction, and the number of bytes copied is bounded by the size of the array. In this case, the function does not need to be GS protected and as such can be safely optimized away.
Visual Studio 2010 introduces an enhanced GS heuristic that provides significant security improvements by increasing the scope of GS protection to a carefully targeted superset of those functions protected by the legacy GS scheme.
Of course the compiler change is just the first step. Any application developed using VS2010 is set to benefit from the improved security provided by enhanced GS. Inside Microsoft, MSEC have already started to work with several product teams so that once Visual Studio 2010 has shipped then they can start migrating their future releases to the updated compiler and take advantage of the enhanced GS capability. In the meantime, try out the upcoming Visual Studio 2010 beta and let us know what you think!
MS08-067 and the SDL, SDL blog entry, Michael Howard, October 2008
Lessons learned from the Animated Cursor Security Bug, SDL blog entry, Michael Howard, April 2007
Hardening stack-based buffer overrun detection in VC2005 SP1, Michael Howard’s blog, April 2007
#pragma strict_gs_check , MSDN C/C++ pre-processor reference.
*Posting is provided "AS IS" with no warranties, and confers no rights.*
The Microsoft C/C++ compiler supports the GS switch which aims to detect stack buffer overruns at runtime and terminate the process, thus in most cases preventing an attacker from gaining control of the vulnerable machine. This post will not go into detail about how GS works, so it may be helpful to refer to these MSDN articles for an overview and loads of detail on how GS works and what a GS cookie is. It’s important to note that depending on the exact vulnerability, even if a function is protected by a GS cookie, a stack-based buffer overrun may still be exploitable – for example if the attacker can gain control prior to the cookie check. However even in these circumstances, GS can often be a significant obstacle to exploitation and/or reliability of exploitation. There have been some stack-based attacks recently that were not mitigated by GS – this post takes a couple of examples and looks at why that was.
This companion post looks at how Visual Studio 2010 improves GS in light of some of the limitations covered in this post.
In MS08-067 (see also associated SDL blog entry), there is a fixed size buffer on the stack and the vulnerability is in the code that parses the path for “\..” substrings, replacing them with the explicit directory name as required. For example \\server\A\B\C\..\D\..\..\E” would be resolved to “\\server\A\E”. The vulnerability lies in the fact that when searching backwards through the path string buffer for a ‘\’ character the pointer returned by this search can sometimes end up being before the start of the path buffer.
Let’s look at how this key fact impacts the effectiveness of GS when data is then copied into memory starting at that address. The call stack looks like:
netapi32!ConvertPathMacros+0x101 netapi32!CanonicalizePathName+0x102
The path string buffer is defined in CanonicalizePathNames and that function is GS-protected. The ConvertPathMacros function is not GS-protected: it takes a pointer to the path buffer defined in CanonicalizePathNames as one of its arguments and has itself no local variables that would lead to it being GS-protected.
The initial stack layout is as below, with the ConvertPathMacros function having a pointer to the pathBuffer variable defined in CanonicalizePathName:
Step 1: the search for ‘\’ character causes a pointer to reference address before the start of path buffer.
Step 2: attacker-controlled data is then written starting at that address, overwriting ConvertPathMacro’s stack frame data:
Step 3: ConvertPathMacro function returns, but its return address has been overwritten so that the attacker gains control. In the diagram above the GS cookie in CanonicalizePathName is not overwritten. Note that it is irrelevant whether the overflow overwrote the GS cookie in CanonicalizePathName or not: this is because the cookie in CanonicalizePathName’s stack frame is only checked when CanonicalizePathName returns. And the attacker gains control long before that, when ConvertPathMacros returns.
This is an example of a stack-based vulnerability and attack that GS is simply not designed to mitigate: GS will only protect against an overflow if:
1. The cookie is overwritten as part of the overflow.
2. The cookie check at function return is reached.
In this example neither of the two criteria above need apply.
By way of contrast, compare this with the ANI vulnerability in MS07-017 (see also associated SDL blog entry). The corresponding call stack was:
user32!ReadChunk user32!LoadAniIcon
ReadChunk was effectively just copying data from the ANI file to a pointer provided by LoadAniIcon. The attacker could not control this pointer so exploiting MS07-017 could not be achieved by overwriting ReadChunk’s stack frame as in the previous case. However the LoadAniIcon function where the buffer vulnerable to overflow was defined was not GS-protected at all! So a traditional overflow targeting LoadAniIcon’s return address was feasible.
The ANIHEADER local variable overflowed in the ANI vulnerability was a pure data structure:
typedef struct _ANIHEADER { DWORD cbSizeof; DWORD cFrames; DWORD cSteps; DWORD cx, cy; DWORD cBitCount, cPlanes; DWORD jifRate; DWORD fl; } ANIHEADER, *PANIHEADER;
The compiler uses a heuristic to decide which functions to GS-protect, and this is targeted mainly at protecting against string buffer overflows. As LoadAniIcon contained no such string buffers then it was not GS-protected.
Unlike the previous example then, the ANI vulnerability could in principle have been mitigated by GS, if GS were applied more extensively; eg if LoadAniIcon had been GS-protected then the picture would have looked like:
The overflow would have overwritten the GS cookie and when LoadAniIcon returned then the GS cookie check would have detected the overflow and terminated the process. As noted at the start, depending on the exact control flow in LoadAniIcon between the overflow and the cookie check at function exit it may still be possible to exploit this; however GS has removed the generic method of exploitation making any exploit harder to develop and (experience tells us) often far less reliable.
It turns out that there is a way of instructing the compiler to be more aggressive in what functions it GS-protects via a pragma: #pragma strict_gs_check (blogged about here by Mike Howard). In fact partly as a result of this ANI vulnerability, MSEC worked with product teams in Windows to apply the strict GS pragma to a number of parser components as part of Windows Vista Service Pack 1.
GS is designed to mitigate a specific class of stack-based attacks, making stack-based exploits harder to develop, less reliable, and in some cases reducing what would have been attacker code execution to a denial-of-service. For example at the time of writing, we do not know of an exploit for MS06-040 on Windows XP SP2+ or Windows Server 2003 SP1 platforms. The SDL requires all Microsoft products to be built with GS enabled. Many third-party products use GS too – including recent versions of Quicktime, Adobe Acrobat, and Flash for example.
Where the attacker has more fine-grained control of where to start the overflow, or the direction of an overflow/underflow then the GS mitigation won’t help. In some cases however GS would help if present, and its absence is purely related to the default heuristics that the compiler uses. For high-risk code – code that handles untrusted data for example – consider making use of the strict_gs_check pragma.
Looking ahead I’m also excited at the prospect of “Enhanced GS” – what’s “Enhanced GS”? Well, it’s a whole other article: check back here over the next couple of days and read all about it!
And of course there is no substitute for the code being secure in the first place!
- Tim Burrell, MSEC Security Science
/GS (Buffer Security Check), MSDN Visual C++ compiler options entry
Compiler Security Checks in Depth, MSDN Visual Studio Technical Articles, Brandon Bray, February 2002
Lessons learned from the Animated Cursor Security Bug, SDL blog entry, Michael Howard , April 2007
After releasing security update MS09-008, we received a number of questions on the WPAD issue (CVE-2009-0093) addressed in the update. There are claims that this update is ineffective. Let me be clear that this update will protect you and it should be deployed as soon as possible. Below is an overview on how the complete security update helps protect a system.
This security update resolves a number of different vulnerabilities with different attack vectors:
We’ll review these in a bit more depth starting with the validation vulnerabilities and afterwards looking in more depth at the WPAD registration issue that has attracted most questions.
DNS Server Query and Response Validation Vulnerabilities
CVE-2009-0233 and CVE-2009-0234 are two vulnerabilities that allow an attacker to successfully spoof DNS responses by issuing specifically crafted DNS queries.
A DNS transaction ID is a number that uniquely identifies a single DNS transaction. The DNS server uses it to identify if a response to a query is in fact legitimate. When transaction IDs are predictable, an attacker could spoof valid responses to DNS queries made by the server, and as such introduce arbitrary addresses into the DNS cache.
In both vulnerabilities, the server does not cache specific types of DNS responses, allowing an attacker to cause the DNS server to continuously request a specific Resource Record (RR). This makes it easier for an attacker to match the correct transaction ID and source port combination and successfully spoof a response. The security update resolves these two issues by improving the way the DNS server will cache and re-use answers to these specific types of queries.
DNS Server Vulnerability in WPAD Registration
CVE-2009-0093 describes an issue with how the Web Proxy Auto-Discovery, or WPAD, and the Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP, can be abused by an attacker.
This is typically a local domain attack where there is a degree of trust between the domain members. The Windows DNS server can allow clients to register their own hostname in the DNS server using dynamic updates. In the most common scenario, this takes place using secure dynamic updates, where a client authenticated against the domain can update its own name on the DNS server. If the WPAD or ISATAP names have not yet been registered, a domain-authenticated user could register his own machine as either of these two names.
The reason why ISATAP and WPAD are so interesting for an attacker to register, is because they are default names a client will resolve to obtain specific functionality. In the case of WPAD, the name tells the host where to connect for proxy configuration information. In the case of ISATAP, it points to a tunneling server that connects IPv6 hosts over IPv4 networks.
WPAD in particular is common enterprise functionality, and as such Microsoft needs to be very careful when releasing a security update to ensure that we both protect our customers, and do not break the functionality they have come to rely upon.
The security update we released helps protect customers by implementing a block list on the DNS server, containing a list of names which the DNS server will no longer resolve. This list is implemented as the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\
GlobalQueryBlockList
(3/18/09: Updated registry key)
If the WPAD and ISATAP names are not registered on the DNS server when the security update is installed this block list is populated with both names. When a client issues a query for one of those names the DNS server will return a negative response, even if an attacker registers it.
However, when a DNS server already has an entry for either WPAD or ISATAP before the update is applied, it will not add that name to the block list, and will continue to answer requests for them. As an example, if a DNS server has a resource record configured named WPAD, the security update will add only the name ISATAP to the block list. If a DNS server does not have WPAD nor ISATAP configured, the block list will contain both names.
This is necessary as many of our customers legitimately use this functionality. Implementing a block list that blocks these names in all cases, requiring the administrator to remove them manually would break these configurations.
One concern that was raised by a security researcher is that an attacker may have introduced a malicious WPAD entry through a dynamic DNS update. When you install the security update after such an attack has taken place, the WPAD name will not be added to the block list, and the attack will continue to be effective.
This is indeed not a scenario the security update, or any security update released by Microsoft aims to address. Security updates are intended to help protect the system against future exploitation, and don’t aim to undo any attack that has taken place in the past. The update does not actively change the current configuration. When installing the update, it has no way of knowing whether the WPAD entry was configured by an administrator or an attacker.
Customers who have this specific concern can validate the IP address assigned to the current WPAD/ISATAP entries in their DNS zones using the DNS MMC snap-in:
In addition, KB article 968732 describes in detail how a DNS administrator can manually edit the DNS block list to suit his environment.
WPAD WINS Server Registration Vulnerability
CVE-2009-0094 covers the same attack as the DNS Server Vulnerability in WPAD Registration, but using WINS. A WPAD-configured client can look up a host by resolving the name WPAD in WINS as opposed to DNS. This security update will install a WINS block list which is, as with DNS, pre-populated with the WPAD, “WPAD.” and ISATAP names, unless that name is present in the current WINS database. The WINS block list is implemented as the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WINS\Parameters\QueryBlockList
Customers can validate whether a WPAD name is currently registered in their WINS database using the WINS MMC snap-in:
Any active WPAD name registrations should show in the "Active Registrations" window as shown below:
KB article 968731 describes in detail how a WINS administrator can edit the WINS block list. Note that the WINS block list is independent from the DNS block list, and in both cases block lists do not replicate across multiple servers.
Beyond the two issues we’ve address regarding the WPAD protocol with this update, there may be other ways clients could get redirected to WPAD servers unintentionally. We’re continuing to investigate these. In fact, guidance around this can be found here http://www.microsoft.com/technet/security/advisory/945713.mspx.
We hope this blog entry clarifies the content of the security update and answers any questions you may have. This security update addresses a number of vulnerabilities and we recommend installing it at your earliest convenience.
-Maarten Van Horenbeeck, MSRC Program Manager
We’d like to thank the following contributors to this blog:
3/18/09 Update: Fixed error in the DNS registry key. Thanks to Daniel A Baillargeon for bringing this to our attention.
MS09-007 resolves an issue in which an attacker may be able to log onto an SSL protected server which is configured to use certificate based client authentication with only the public key component of a certificate, not the associated private key. Only a subset of customers who log into SSL protected servers are at risk but it is a little tricky to explain who might be affected due to the unique nature of this vulnerability. This blog entry will help you assess the risk to which your application is exposed by explaining those details.
Affected deployments
This vulnerability does not apply to customers who have mapped certificate-authenticated users against an Active Directory domain. It only applies in those situations where certificates are mapped to local Windows accounts on the server. For domain deployments, we still recommend applying the update as a defense in depth measure.
Customers can find more information on the different ways of certificate mapping here: http://technet.microsoft.com/en-us/library/cc736706.aspx
The vulnerability
In a PKI deployment, digital X.509 certificates contain a public key component, which can be distributed to other parties that allows them to encrypt data that only the holder of the corresponding private key can read. When web sites use certificates for client authentication, they generally require the user to encrypt certain data with his private key to prove that he is really the owner of the certificate used to authenticate. This specific vulnerability occurs due to a flaw in the way the server validates that the user is using his private key to authenticate. As such, in some circumstances a user may successfully authenticate by only providing the public key, and not using the corresponding private key.
Determining if your configuration is at risk
On the Windows client platform, certificates are stored in the certificate store under the user’s individual account. Each certificate has an “Intended purpose” assigned. Common Intended purposes include Secure Email, Client Authentication, Encrypting File System, and All Intended Purposes. These describe for what purpose applications on the Windows client can use a specific certificate. A certificate can have multiple purposes. These intended purposes cannot be changed by the user, but are part of the EKU extension of the digital certificate. They are read-only and set by the certificate issuer.
You can review the intended purpose(s) of your certificates by clicking Start, and running “certmgr.msc”, the Microsoft Management Console certificate snap-in. The “Intended Purpose” shows under Personal, then Certificates, as seen in the screenshot below:
Your configuration would not be at significant risk unless an attacker gets access to your user’s public keys. While the public key component of a certificate is a “public key”, it’s important to understand that when a user authenticates against an SSL protected IIS web server, the public key component of the certificate is not transferred in clear text. During the authentication process, it cannot be sniffed off the wire by an attacker on the local subnet. As such, if the certificate is configured with an intended purpose of “Client Authentication” only, it would be more difficult for an attacker to gain access to the certificate and exploit the vulnerability. He would need to gain access to the certificate on the machine, or convince the user to authenticate against his own, malicious web site.
This deployment scenario is most common in those situations where the owner of a web site himself issues certificates to his users, and can limit the uses to a specific purpose. Another potentially impacted scenario is when the owner of a protected SSL web site allows users to use their own generic certificates to authenticate against a server. In this case, the user may also be using the certificate for other purposes (i.e. the certificate may have multiple intended purposes), such as authenticating against wireless networks or signing e-mail. Depending on the purpose, the public key may be distributed in clear text and to untrusted parties. This would make it easier for an attacker to gain access to the victim’s public key which he needs to exploit this vulnerability successfully, and thus increases the risk significantly.
We hope this blog entry helps address some of the questions you may have, and helps you assess the risk this vulnerability poses to your web application and its users.
- Maarten Van Horenbeeck (MSRC Operations), Robert Hensing and Jonathan Ness (MSRC Engineering)
It’s getting busy around here with people preparing for the CanSecWest security conference (http://cansecwest.com/). Many of the Microsoft Security Engineering Center (MSEC) and Microsoft Security Response Center (MSRC) members that regularly post to this blog will be attending CanSecWest and soaking up the 3 days of presentations & networking.
If you haven’t heard us talk about the Security Science angle of MSEC before, let me explain. The Security Science team is a group of security experts who do applied security research to solve difficult, leading-edge problems in an effort to increase customer security. They do research into new ways of finding vulnerabilities, develop innovative exploit mitigation techniques, and provide tracking and early warning of exploitation events. The team is literally in the same hallways as the MSRC, so the type of problems they tackle spring directly from current vulnerability cases and exploits. After they successfully crack a problem the tools and methods that result are reviewed for inclusion into the Security Development Lifecycle (SDL). This is one of the ways we move the SDL forward and keep it current.
The Security Science team aims to find ways to do security smarter and then enable others to leverage that work. So we’ve submitted a few talks to CanSecWest that will highlight the work that MSEC does:
Final time slots haven’t been assigned yet, so check back at the CanSecWest site.
Matt Miller is also queuing up to do a Lightning Talk on High Signal to Noise Vulnerability Detection, so watch for us there as well.
New Blog URL
As we announced in a previous blog post, we have expanded the focus of this blog to include Security Science work. To eliminate confusion and better align with the actual blog title, we updated the url to better reflect this change. The blog url is now http://blogs.technet.com/srd/
For those who have this bookmarked or are receiving RSS feeds, this will be seamless for you as the old url/feeds redirect to the new ones. Nevertheless we wanted to provide you with a heads-up.
See you in Vancouver!
Matt Thomlinson
Senior Director, TwC Security
The Microsoft Office applications (Word, Excel, PowerPoint, etc) have built-in ActiveX control support. ActiveX support allows a richer experience when interacting with an Office document. For example, a document author could use the Safe-For-Initialization Office Web Components (OWC) ActiveX control to retrieve data from an intranet data source.
Office applications’ prompting behavior
By default, Office applications do not prompt when instantiating a Safe-For-Initialization ActiveX control. This is similar to Internet Explorer’s behavior in the Internet Zone. The main difference between Office and IE is that Office applications such as Word, Excel, or PowerPoint do not care about the ActiveX Safe-For-Scripting setting because they do not have any scripting support besides VBA. If you have malicious VBA code running, you are in big trouble even without using any ActiveX controls.
Also by default, ActiveX controls not marked as SFI can only be loaded if the user enables it via the prompt. Here is what the prompt looks like:
How can an attacker abuse this rich experience enabled by Safe-For-Initialization ActiveX controls?
Attackers have discovered ActiveX support in Office applications and have been using it to more effectively lure victims to web-based malware. They have recently used the “Microsoft Scriptlet Component” to navigate victims to a website exploiting a patched Internet Explorer vulnerability (CVE 2009-0075, fixed by security bulletin MS09-002). Seems like attackers have discovered it is easier to trick a user to open a Word document attached to email compared to luring a user to click a dubious-looking link. This specific attack is mentioned in a Trend Malware Blog posting last week (http://blog.trendmicro.com/another-exploit-targets-ie7-bug//).
Let’s take a closer look at this Scriptlet ActiveX control:
Clsid: {ae24fdae-03c6-11d1-8b76-0080c744f389} Progid: ScriptBridge.ScriptBridge.1 Binary Path: C:\Windows\system32\mshtml.dll Implements IObjectSafety: True Safe For Initialization (IObjectSafety): True **** Safe For Scripting (IObjectSafety): True Safe For Initialization (Registry): False Safe For Scripting (Registry): False KillBitted: False
Because this ActiveX control is marked as SFI, an Office document can use it without showing any prompt, similar to what IE does by default in Internet Zone. This is the “by design” behavior. (We explain how you can get this information about any ActiveX control registered on your system in this SRD blog post from Feb 2008.)
How to configure ActiveX support in Office
If you are concerned about Safe-for-Initialization ActiveX controls being instantiated by Office without prompt, you can configure this behavior in Office 2007. Here is a screenshot from the Office 2007 Trust Center:
Office’s help Topic “Enable or disable ActiveX controls in Office documents“ gives a detail explanation about ActiveX configuration. It describes the default “Prompt me before enabling all controls with minimal restrictions” to be the settings described above:
If you do not want any ActiveX controls to be used by Office documents, you could change the setting to be “Disable all controls without notification”. The ActiveX setting in the trust center can also be set via group policy or registry. For more information, please refer to the following links:
Office 2007: “Security policies and settings in the 2007 Office system”
Office 2003/XP: “How Policies Work” and Microsoft Knowledge Base article 827742.
Chengyun, MSRC Engineering
This morning, we posted Security Advisory 968272 notifying of a new Excel binary file format vulnerability being exploited in targeted attacks. We wanted to share more information about the vulnerability to help you assess risk and protect your environment.
Office 2007 being targeted
The current attacks we have seen target users of Office 2007 running an earlier version of Windows (Windows 2000, XP, 2003). The exploit technique used in these attacks would not work on Windows Vista or earlier versions of Microsoft Office without substantial improvements made by attackers.
We analyze a lot of Office content type exploits and this is the first time we have seen a working exploit in-the-wild that is able to run code on Office 2007. It is always interesting to analyze the first exploit for a new platform, especially one that has held up without being exploited for several years. Note that this is in the legacy binary file format, not the newer XML format. The nature of this vulnerability, unfortunately, lends itself to easier exploitation on Office 2007 compared to earlier versions of Office. The routines that handle object destruction were changed in Office 2007 in a way that makes exploitation for code execution easier. The same vulnerable code is present in earlier versions of Office but will more likely result only in an application crash on those versions. It appears attackers are targeting Office 2007 running on Windows XP.
How to protect yourself
The security advisory lists a couple different workaround options:
1 – Turn on MOICE. MOICE converts the XLS to XSLX before opening. Again, the new XML file format is not susceptible to this vulnerability.
2 – Turn on FileBlock. This option is a little more disruptive to most environments. With FileBlock enabled, Excel will only open the new XML-based file format that is safer. It will not open the legacy binary file format. If your organization has switched over to using the new file format exclusively, this might be a great option, even just long enough for us to get a security update out to address the vulnerability.
- Jonathan Ness and Bruce Dang, MSRC Engineering