Security Research & Defense

Assessing the risk of the February Security Bulletins

swiblog — Tue, 09 Feb 2010 18:05:00 GMT

This morning, we released 13 security bulletins. Five have maximum severity rating of Critical, seven Important, and one Moderate. One security bulletin (MS10-015, ntvdm.dll) has exploit code already published, but we are not aware of any active attacks or customer impact. We hope that the table and commentary below helps you prioritize the deployment of the updates appropriately.

Bulletin	Most likely attack vector	Max Bulletin Severity	Max Exploit- ability Index	Likely first 30 days impact	Platform mitigations
MS10-013 (Quartz)	Victim opens malicious AVI or WAV file.	Critical	1	Likely to see working exploit in next 30 days.
MS10-007 (ShellExecute)	Attacker hosts a malicious webpage, lures victim to it.	Critical	1	Likely to see exploit code released resulting in binary on WebDAV share being executed. For more detail, see this SRD blog post.
MS10-006 (SMB Client)	Locally logged-in attacker with low privilege runs a malicious executable to elevate to high privilege.	Critical	1	Likely to see working exploit code for local attacker escalation. For more detail, see this SRD blog post.
MS10-008 (ActiveX kill-bits)	Attackers host a malicious webpage, lures victim to it	Critical	2	Likely to see working exploit for vulnerabilities in third party ActiveX controls.
MS10-012 (SMB Server)	Attacker sends network-based malicious connection to remote Windows machine via SMB.	Important	1	Likely to see working proof-of-concept in next 30 days for CVE-2010-0231 resulting in attacker luring remote victim user to open file on attacker server and initiating a connection back to machine where remote victim is logged on. Less likely to see working exploit code for the authenticated code execution vulnerability (CVE-2010-0020) or unauthenticated denial-of-service vulnerabilities (CVE-2010-0021 and 0022) For more detail, see this SRD blog post.
MS10-015 (Kernel)	Attacker already able to execute code as low-privileged user escalates privileges.	Important	1	Proof of concept code already widely available. No active attacks.
MS10-011 (CSRSS)	Attacker who logs onto console of system where victim later logs onto console of same system can potentially run code with victim’s identity.	Important	1	Likely to see proof-of-concept code published for this vulnerability. However, unlikely to see wide-spread exploitation due to extensive user interaction required.
MS10-009 (TCP/IP)	Attacker sends network-based attack against system on local subnet.	Critical	2	May see denial-of-service proof-of-concept code published leveraging CVE-2010-0239 or CVE-2010-0241. Attackers are less likely to discover real-world attack surface in next 30 days for CVE-2010-0240.	/GS effective mitigation for CVE’s: CVE-2010-0239 CVE-2010-0240 CVE-2010-0241. CVE-2010-0242 is denial of service only.
MS10-003 (Excel)	Attack sends malicious .xls file to victim who opens it with Office XP or lower. (Office 2003, 2007 not affected.)	Important	1	Likely to see working exploit file effective on Office XP in first 30 days.	Office 2003 and Office 2007 not affected.
MS10-004 (PowerPoint)	Attacks malicious .ppt file to victim who opens it with Powerpoint Viewer 2003.	Important	1	Likely to see working exploit file effective on PowerPoint Viewer 2003. However, PowerPoint Viewer 2003 was replaced online by PowerPoint Viewer 2007. Only victims who use PowerPoint Viewer 2003 from Office 2003 install disk would be vulnerable to the PowerPoint Viewer vulnerabilities. Less likely to see working exploit for other PowerPoint vulnerabilities.
MS10-010 (Hyper-V)	Attacker running code on virtual machine crashes host OS.	Important	3	Unlikely to see working exploit code in next 30 days.
MS10-014 (Kerberos)	Attacker potentially able to cause denial of service via Kerberos traffic if victim server configured with trust relationship to MIT Kerberos realm.	Important	3	Unlikely to see public exploit code in next 30 days.
MS10-005 (GDI+)	Attacker sends malicious JPEG to victim. Victim saves JPG, launches mspaint, and then file->opens the malicious JPEG	Moderate	1	Likely to see exploit code developed. Unlikely to have broad impact as mspaint is not registered file association for JPEG.

We also released Security Advisory 977377 covering the TLS man-in-the-middle vulnerabilities disclosed several months ago. The advisory describes more about the Microsoft attack surface (and a mitigation option). You can read our blog post about the issue here: http://blogs.technet.com/srd/archive/2010/02/09/details-on-the-new-tls-advisory.aspx.

Thanks to all of MSRC Engineering for providing data for this table. Thanks Jerry Bryant, Andrew Roths, and Mark Wodrich for your ordering / priority thoughts.

- - Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

MS10-007: Additional information and recommendations for developers

swiblog — Tue, 09 Feb 2010 18:01:00 GMT

Today we are releasing MS10-007 to address a URL validation issue generally applicable to the ShellExecute API.

How would a malicious user leverage this vulnerability?

This issue involves how ShellExecute handles strings that appear to be legitimate URLs, but are malformed such that they result in execution of arbitrary code. Various technologies use ShellExecute to initiate a browser navigation. It is assumed that the operation is safe if the parameter passed to ShellExecute “looks like a URL.” It seems reasonable to expect that if a string is a valid URL, it cannot possibly result in execution of arbitrary code when processed by ShellExecute.

But while it may be valid to assume that

ShellExecute(URL)

will not execute a system command, it should be understood that the core purpose of the ShellExecute API is to execute files. This vulnerability involves the use of a valid-looking URL that ShellExecute will run as a system command. To get exploited, a user might click on a link appearing outside the context of the browser, for example as an address book contact. At that point, a remote executable could run without prompting.

Recommendations for Developers

We recommend that application developers wishing to use ShellExecute for URL-based navigation take a conservative approach to validation. First, developers should heed the specific guidance in KB943552 as it pertains to this scenario. Additionally, rather than simply validating that a URL is of the format [scheme]://[FQDN]/[path]?[querystring], it is advisable to also validate that the URL scheme is one of a specific set of allow-listed URL schemes, for example “http” or “https.” This is consistent with guidance provided in Chapter 4 of the Microsoft Design Guidelines for Secure Web Applications.

As it turns out, many commonly-used code paths actually do perform this level of URL scheme validation and thus do not present viable attack vectors, even in the presence of the ShellExecute bug. Defense-in-depth FTW!

Acknowledgements
Thanks to Chengyun Chu for insight and analysis on this issue.

- David Ross, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

MS10-006 and MS10-012: SMB security bulletins

swiblog — Tue, 09 Feb 2010 18:00:00 GMT

Today we released two bulletins to address vulnerabilities in SMB. MS10-006 addresses two vulnerabilities in the SMBv1 client implementation, and MS10-012 addresses four vulnerabilities in the SMB server implementation. In this blog entry, we want to help you understand the vulnerabilities and better prioritize the updates.

What are the SMB server vulnerabilities and how could they be exploited?

The first issue is an authenticated remote code execution (RCE) vulnerability (CVE-2010-0020) in the server SMBv1 implementation on all versions of Windows. A long filename can lead to kernel pool memory corruption in an error path. This issue has a severity rating of important as an attacker needs to be authenticated to perform the attack.

The second and third issues (CVE-2010-0021 and CVE-2010-0022) are remote unauthenticated denial-of-service (DoS) vulnerabilities in the SMBv1 and SMBv2 server implementations and have Important severity ratings. CVE-2010-0021 is caused by a race condition when handling valid Negotiate requests. CVE-2010-0022 is caused by an integer underflow when handling a path name in the SMB request.

The final server-side issue is CVE-2010-0231, an Important-severity remote unauthenticated elevation of privilege (EoP) affecting all versions of Windows. This issue is unusual in that it is caused by weak entropy in the cryptographic challenge values generated by SMB. An attacker could exploit this issue and gain access to the SMB server under the credentials of an authorized user.

We recommend placing higher priority on the SMB server-side update due to the risk of RCE and EoP on all systems.

What are the SMB client vulnerabilities?

The first issue is a Critical severity kernel pool memory corruption vulnerability (CVE-2010-0016) in the client SMBv1 implementation on Windows 2003 and below. The vulnerability happens during the SMB client/server negotiation phase and does not require authentication. A remote attacker who successfully exploits this issue could gain complete control of the target system.

The second one is an Important severity race condition in the client SMBv1 code on Windows Vista and higher (CVE-2010-0017). The vulnerability is in the SMB client/server negotiation phase and does not require authentication. The severity of this issue depends on the version of Windows on the client computer:

On Windows Vista and Windows Server 2008 a remote attacker would not be able to gain control of a target system using this vulnerability; instead the impact would be a system DoS. However, a local authenticated user could potentially exploit this vulnerability and gain control of the system. On these platforms, the severity of this issue is Important. The update should be prioritized for Terminal Servers and other system that allow users to log on locally.
On Windows 7 and Windows Server 2008 R2 a remote attacker can potentially gain control of a target system using a variation of this vulnerability. Due to the RCE impact, the severity of this issue on these platforms is Critical. Unsuccessful attempts to exploit the vulnerability would result in a system DoS. This update should be applied to all affected systems due to the RCE risk; however, due to the nature of the issue, DoS is much more likely.

Why does the SMB client update have an aggregate severity of Critical on Windows 7 and Windows Server 2008 R@, but only Important on Vista and Windows Server 2008?

As outlined above, CVE-2010-0017 affects Vista and higher systems and is rated Important on Vista and Windows Server 2008. However, on Windows 7 and Windows Server 2008 R2, the severity is higher (Critical) due to the risk of RCE. The reason for this difference is a design change made during the Windows 7 development process, when the SMB client code moved to use a new kernel-mode networking I/O mechanism – Winsock Kernel (WSK). This change exposed the SMB client code to different timing conditions, exposing a race condition. This race condition is different to the issue present on Vista and Windows Server 2008, although it is reachable under similar conditions.

It should be noted that WSK is not the source of the vulnerability and no change to WSK is being made in this update.

How could a malicious user exploit the SMB client vulnerabilities?

It is important to understand that both of the vulnerabilities in MS10-006 are in the SMB client implementation and do not affect SMB server roles. (For more details regarding SMB client/server roles, see ref. 2 below) Therefore, in order to exploit this vulnerability, an attacker would have to setup a malicious SMB server and trick the client to connect to it. If your environment does not allow outbound SMB connections to the Internet (best practice), then you are protected from the Internet attack vector. A malicious user on the local network (or a compromised computer) would be able to exploit this issue by performing man-in-the-middle attacks and responding to SMB requests from clients within the Intranet.

The Internet attack vector would involve browsing to a malicious or compromised website, or receiving HTML email with embedded links to a malicious SMB server. If a victim attempted to retrieve the files or other content specified in the HTML file, an outbound SMB connection would be made and assuming SMB traffic were allowed through the perimeter firewall, the issues could be exploited.

Depending on your environment, you may not need to place a high priority on the SMB client-side update.

We would like to thank Dustin Childs from MSRC and Kowshik Jaganathan and the Windows Sustained Engineering team for their hard work on this update.

- Bruce Dang and Mark Wodrich, MSRC Engineering

References:

1. Winsock Kernel on MSDN (http://blogs.msdn.com/wndp/archive/2006/02/24/538746.aspx)
2. SMB client/server roles (http://msdn.microsoft.com/en-us/library/aa365233(VS.85).aspx)

Details on the New TLS Advisory

swiblog — Tue, 09 Feb 2010 17:00:00 GMT

Security Advisory 977377: Vulnerability in TLS Could Allow Spoofing

In August of 2009, researchers at PhoneFactor discovered a vulnerability in the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. As the issue is present in the actual TLS/SSL-standard, not only our implementation, Microsoft is working together with ICASI, the Industry Consortium for Advancement of Security on the Internet to address this vulnerability. Today, Microsoft released an advisory and an associated workaround package that experienced administrators can use to protect their web services.

Explaining the risk of the security vulnerability

The issue, CVE-2009-3555, allows an attacker who successfully became a man-in-the-middle to prepend information to a TLS/SSL protected connection. It does not allow an attacker to read, change or edit the encrypted data. This vulnerability exists because certain SSL-protected protocols, such as HTTP, assume that information received after a TLS-renegotiation is sent by the same client as the information sent before that renegotiation. Renegotiation is a feature of the TLS protocol, described in RFC 2246 which allows either peer to renegotiate the parameters of a protected connection at any point in time. An attacker could exploit this vulnerability by intercepting a legitimate connection from a client, then initiating a renegotiation to the vulnerable server, or by piggybacking on a TLS renegotiation initiated by the web server.

This vulnerability can affect different protocols that use TLS/SSL, but most clearly affected is the HTTPS protocol which protects web transactions.

IIS 6, IIS 7, IIS 7.5 not affected in default configuration

Customers using Internet Information Services (IIS) 6, 7 or 7.5 are not affected in their default configuration. These versions of IIS do not support client-initiated renegotiation, and will also not perform a server-initiated renegotiation. If there is no renegotiation, the vulnerability does not exist. The only situation in which these versions of the IIS web server are affected is when the server is configured for certificate-based mutual authentication, which is not a common setting.

Scope of the vulnerability in IIS 5

IIS 5 does allow clients to initiate a TLS renegotiation and is vulnerable in its default configuration. Our investigation has shown it is unlikely that these attacks will be exploited successfully. An attacker would already need to successfully leverage a man-in-the-middle attack to intercept a connection between a client and vulnerable server in order to exploit this vulnerability.

Likelihood of the vulnerability being exploited in general case

Eric Lawrence, a Program Manager in the Internet Explorer security team also evaluated the exploitability of the vulnerability and found the following:

The below is an example of an exploitation of this vulnerability. The text in red is prepended to an SSL connection by an attacker, the text in blue is sent by the unwitting victim client, and the text in green is the web server’s response:

GET /app/transaction.asp?action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000 HTTP/1.1
X-Ignore-This-Line: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)

Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk

Host: www.victim.com

HTTP/1.1 200 OK
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close

<html><body>Successfully sent $2000USD from account #12345 to account #6666.</body></html>

The lines highlighted in yellow represent client state or identification information; by being in the same header block as the attacker’s request, they effectively authorize that spliced request.

There are two reasons why this attack is unlikely to be exploited:

· If a site is vulnerable to this attack, they are almost certainly vulnerable to classic Cross Site Request Forgery style of attack. The attacker need only send the client some HTML containing an IMG SRC to the victim URL and the client will dereference that URL, automatically providing the credentials to the server. This is a simpler mechanism of accomplishing the same thing than the more complicated TLS/SSL and request-splicing attack hopes to achieve.

· If an attacker were able to overcome the previous issue, this technique will not work for a site that only accepts parameters via HTTP POST requests. The reason is that the attacker must convey the malicious request within the POST’s body. By definition, the HTTP POST body occurs after the request header block has completed. So, the malicious attack would look something like this:

POST /app/transaction.asp HTTP/1.1
Host: www.victim.com

Content-Type: application/x-www-form-urlencoded

Content-Length: 62

action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)

Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk

Host: www.victim.com

HTTP/1.1 400 Bad Request
Content-Type: text/html
Server: Microsoft-IIS/6.0
Connection: close

<html><body>Credentials required.</body></html>

Because the victim’s spliced request is sent after the header block, the credentials will not be used to authenticate the submitted transaction. The only way an attacker could make this work is if the server accepted what are called “Trailer” headers from the HTTP request, like so:

POST /app/transaction.asp HTTP/1.1
Host: www.victim.com

Content-Type: application/x-www-form-urlencoded

Transfer-Encoding: chunked

Trailer: Authorization, Cookie, X-Ignore

3E
action=sendMoney&srcAcctID=12345&targetAcctID=6666&amount=2000
0
X-Ignore: GET /app/updatecheck.asp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; Trident/4.0;)

Cookie: PREF=ID=0d3e398a45b12d8a:U=ed647eec50a4edca:HSID=AOHxfGVRaYatVUIUs
Authorization: Basic c2VjcmV0OnBhc3N3b3Jk

Host: www.victim.com

However, it is unlikely that real-life web applications actually would accept this type of Trailer header, as it is a very little-used part of HTTP, not supported by mainstream browsers such as Internet Explorer.

Workaround package available to disable TLS renegotiation

While a comprehensive, multi-vendor fix is in the works, today we released a workaround package which allows system administrators to disable TLS renegotiation on their server. This package is described in KB article 977377 and disables TLS/SSL renegotiation for all TLS/SSL-protected protocols. We need to stress that TLS/SSL renegotiation is a feature of the protocol that is used by several applications. One common example is Microsoft Exchange and ActiveSync. These applications may operate inappropriately upon installation of this workaround package. We recommend that administrators carefully test the workaround prior to deploying it on production systems. The package will protect all clients making SSL connections to the server on which it is installed. Installing it on clients will not provide any security benefit.

We recommend that customers only install this workaround if they have very specific concerns regarding this vulnerability and require an ad-interim solution while Microsoft and other vendors work on a revision of the protocol.

Despite the low risk of active exploitation, this vulnerability breaches a security promise made by the TLS protocol and we intend to address it comprehensively. We are working with the relevant standards body and our partners in ICASI to ensure that our fix for this issue is compatible with third party SSL/TLS-enabled solutions.

Thanks to Nasko Oskov from Windows Security, Eric Lawrence from Internet Explorer and Jonathan Ness from the MSRC Engineering team for their significant contributions to this blog post.

-Maarten Van Horenbeeck, MSRC Program Manager

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Reports of DEP being bypassed

swiblog — Wed, 20 Jan 2010 18:01:00 GMT

Yesterday we heard reports of a commercially available exploit that bypasses DEP. This exploit was made available to a limited number of major security vendors (Antivirus, IDS, and IPS vendors) and government CERT agencies. We wanted to use this opportunity to give an overview of current customer risk related to this DEP bypass.

Real-world attacks so far still only effective against Internet Explorer 6

We have seen an increase in attacks attempting to exploit the vulnerability detailed in Security Advisory 979352. However, all attacks we have seen so far still target Internet Explorer 6 - this is also confirmed by the attack samples our Microsoft Active Protections Program (MAPP) partners have sent in.

While we have not seen real-world attacks for any other platform, we have seen researchers poking at other platforms and have seen the following:

Private proof-of-concept code exploiting IE7 on Windows XP for arbitrary code execution
Private proof-of-concept code exploiting IE7 on Windows Vista without DEP enabled for code execution within the Protected Mode sandbox. We are not aware of any proof-of-concept code exploiting Windows Vista with DEP enabled.
Commercial, limited distribution proof-of-concept code exploiting IE8 on Windows XP with DEP enabled for arbitrary code execution.

State-of-the-art of attacker research on various platforms

Here’s the current state-of-the-art on each platform:

	Windows XP	Windows Vista	Windows 7
IE 6	Public exploit code consistently reliable for arbitrary code execution	N/A	N/A
IE 7	Private proof-of-concept is likely consistently reliable for arbitrary code execution	Private proof-of-concept is likely consistently reliable for limited code execution within the Protected Mode sandbox.	N/A
IE 8	In our testing, the commercially-available, limited distribution exploit does result in successful code execution with DEP enabled.	No known proof-of-concept code. Current exploits modified for use on Windows Vista would likely be effective for limited code execution within the Protected Mode sandbox on 1% of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows Vista.	No known proof-of-concept code. Current exploits modified for use on Windows 7 would likely be effectively for limited code execution within the Protected Mode sandbox on 1% of exploit attempts. It would result in an Internet Explorer crash for 99% of exploit attempts. Exploits are substantially less reliable due to the presence of ASLR on Windows 7.

Other mitigations (besides DEP)

We have discussed DEP at length in this blog. As you can see in the table above, two other mitigations help prevent or limit the impact of attacks on later platforms.

Internet Explorer Protected Mode limits the impact of Windows Vista and Windows 7 exploits. Attackers who are able to successfully exploit Internet Explorer on those platforms are stuck in a “sandbox”, potentially able to read data but unable to install programs or change system configuration.
Address Space Layout Randomization (ASLR) makes exploiting vulnerabilities more difficult by relocating normally-predictable code locations pseudo-randomly in memory. ASLR re-bases DLL’s to random locations in memory, making ret2libc type attacks unreliable. Due to ASLR we believe exploits for Internet Explorer 8 on Windows Vista or Windows 7 could result in limited code execution for 1% of attempts.

Out-of-band update coming tomorrow

We’ll be releasing a comprehensive, well-tested security update tomorrow morning PST to address this vulnerability. In the meantime, we hope this information helps you assess risk and protect your environment.

Acknowledgements

Thanks Matt Miller and John Lambert for help with the ASLR arithmetic and other feedback.

Update Jan 20, 2010: Updated "less than 1%" to "1%". Thanks reader Larry for catching arithmetic error.

Update Jan 22, 2010: Updated to reflect new understanding of the commercially-available, limited distribution exploit on IE8 / XP SP3. Also removed formula behind the theoretical 1% ASLR success chance. The formula was off by a fraction of a percentage point and the math to describe it would be difficult to explain. The chance is approximately 1.1%.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Additional information about DEP and the Internet Explorer 0day vulnerability

swiblog — Tue, 19 Jan 2010 02:13:43 GMT

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:

More listening and viewing options:

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*

Assessing risk of IE 0day vulnerability

swiblog — Sat, 16 Jan 2010 00:00:00 GMT

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.)

	Windows 2000	Windows XP	Windows Vista	Windows 7
Internet Explorer 6	Exploitable	Exploitable (current exploit effective for code execution)	N/A (Vista ships with IE7)	N/A (Windows 7 ships with IE 8)
Internet Explorer 7	N/A (IE 7 will not install on Windows 2000)	Potentially exploitable (current exploit does not currently work due to memory layout differences in IE 7)	IE Protected Mode prevents current exploit from working.	N/A (Windows 7 ships with IE 8)
Internet Explorer 8	N/A (IE 8 will not install on Windows 2000)	DEP enabled by default on XP SP3 prevents exploit from working.	IE Protected Mode + DEP enabled by default prevent exploit from working.	IE Protected Mode + DEP enabled by default prevent exploit from working.

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.

Disable JavaScript. Microsoft Security Advisory 979352 includes this workaround but we understand that this workaround significantly impacts usability of many Web sites.
Disable code executing from random locations of freed memory. Data Execution Prevention (DEP) prevents the execution of code from pages of memory that are not explicitly marked as executable. DEP is a supported feature on Windows XP Service Pack 2 and higher, Windows Server 2003 Service Pack 2 and higher, and all versions of Windows Vista, Windows Server 2008, and Windows 7. Some platforms enable DEP by default (see below). You can read more about DEP in this blog here and here. You can enable DEP on Windows XP and Windows Vista by clicking the Microsoft Fix It button below. (DEP is enabled by default for Internet Explorer 8 running on XP Service Pack 3, Windows Vista Service Pack 1 and higher, and Windows 7, so you do not need to use the "Microsoft Fix It" for those configurations.)

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.*

MS10-001: Font file decompression vulnerability

swiblog — Tue, 12 Jan 2010 18:00:00 GMT

MS10-001 addresses a vulnerability (CVE-2010-0018 ) in the LZCOMP de-compressor for Microtype Express Fonts. This blog aims to answer some questions regarding the updates we’ve made in this area.

What is the issue?
t2embed.dll improperly performs bounds-checking on lengths which are decoded from the LZCOMP bit-stream. This made it possible for a copy loop to violate the intended working buffer.

Is the EOT functionality reachable through 3rd party code?
Yes, the t2embed library provides EOT functionality that can be used by 3rd party code. Many 3rd parties import t2embed for their font rendering, though some may choose to implement their own font rendering.

Why an Exploitability Index rating of 2?
The Exploitability Index rating or 2 is due to the low likelihood of successful exploitation. Hurdles exist around heap preparation and predictability, heap data corruption, and a race condition to get an exception handler making successful exploitation unlikely.

What is the likelihood of successful exploitation?
Due to the nature of bounds-checking performed in t2embed on 32-bit systems XP and later, the only buffer+index combinations which would pass the old checks will point into address 0x80000000 and above. Because these regions cannot be accessed while running at IOPL 3, the process will crash (Access Violate) and the attempt to run arbitrary code would fail.

On Windows 2000, this vulnerability could be abused to leverage code execution. On 32-bit platforms post Windows 2000, improper memory access would commonly be observed in the form of a Read Access Violation at address 0x80000000 or above, though the memory layout on /3GB-enabled systems could be manipulated to compromise the integrity of the hosting process. Stability (Denial of Service) implications exist on these systems when /3GB is not enabled (default), whereas /3GB-enabled systems run a risk of code execution, though no known attack vectors exist in Microsoft products.

Third party products which are (A) large address aware (http://msdn.microsoft.com/en-us/library/wz223b1z(VS.80).aspx), (B) consume the t2embed, and are (C) running on a /3GB-enabled system should be considered exploitable.

On 64-bit platforms, improper memory access would commonly be observed in the form of a Read Access Violation at a kernel mode address which would affect application stability (Denial of Service) with no threat of code-execution.

Here is a table to represent the exploitation scenarios described above:

	/2GB not running Large Address Aware Application	/3GB not running Large Address Aware Application	/2GB running Large Address Aware Application	/3GB running Large Address Aware Application
32-bit XP and newer	Denial of Service	Denial of Service	Denial of Service	Chance for Code Execution
64-bit XP and newer	Denial of Service	Denial of Service	Denial of Service	Denial of Service
Windows 2000	Chance for Code Execution	Chance for Code Execution	Chance for Code Execution	Chance for Code Execution

The Windows 2000 severity rating of critical was chosen due to the vulnerable code being exposed through client applications that can render EOT fonts in a way that does not require user interaction/notification. (such as Microsoft Internet Explorer, Microsoft Office PowerPoint, and Microsoft Office Word)

What are the attack vectors?
Remote attack vectors are all in user-mode:

Malicious fonts (EOT) delivered within files hosted on malicious web sites which are rendered in all versions of Internet Explorer by default.
Malicious office documents e-mailed to victims with social engineering to entice the victim to open the document which contains a malformed embedded font which would then be rendered upon opening the Office document (PowerPoint and Word documents are the most likely attack vectors).

How do I protect myself?
The best option for protecting against this vulnerability is to apply the update for MS10-001.

As stated in a previous SRD blog post, another option is to disable support for parsing/loading embedded fonts in IE. The side effect of this approach is that it will cause web sites which make use of embedded font technology to fail to render properly.

What is /3GB and how can I tell if /3GB is enabled on my system?
/3GB is a switch and it allows 32-bit systems to benefit from 3GB of addressable memory versus the default 2GB of memory. More information on /3GB can be found here. You can check to see whether you have /3GB enabled on your system by typing the following command in a shell:

C:\>bcdedit.exe /v

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=D:
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {4a81cc63-2e99-11de-a190-00188b749f31}
resumeobject            {4a81cc62-2e99-11de-a190-00188b749f31}
displayorder            {4a81cc63-2e99-11de-a190-00188b749f31}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {4a81cc63-2e99-11de-a190-00188b749f31}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Microsoft Windows Vista
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
bootdebug               Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {4a81cc62-2e99-11de-a190-00188b749f31}
nx                      OptIn
increaseuserva          3072
debug                   No

Note the increaseuserva variable. If unset (or set to 2048), you do not have /3GB enabled. If this value is set to 3072 (as seen here) you have /3GB enabled.

What is LZCOMP?
LZCOMP is a compression algorithm variation of the LZ77 theme. A great explanation of LZCOMP and how it differs from LZ77 can be found here.

Where does the LZCOMP de-compressor component reside on my system?
The LZCOMP de-compressor exists within the t2embed dynamically linked library. It commonly resides in %SystemRoot%\System32 and is imported by programs such as Office and Internet Explorer.

How does this Fonts vulnerability differ from the previous Fonts vulnerability addressed by MS09-065?
This vulnerability exists in a user-mode component (t2embed.dll) whereas the previous Fonts vulnerability (MS09-065) addressed a kernel-mode component (win32k.sys).

I’d like to thank Matt Miller for general guidance, Bruce Dang and Robert Hensing from the MSRC Engineering Team for their efforts on this release.

-Brian Cavenah, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Assessing the risk of the December security bulletins

swiblog — Tue, 08 Dec 2009 18:00:00 GMT

This morning we released six security bulletins, three Critical and three Important, addressing 12 CVE’s. Please apply the Internet Explorer update right away as it poses the most risk of all the bulletins due to severity and exploitability.The Internet Explorer update addresses the vulnerability described by Security Advisory 977981. We hope that the table and commentary below will help you prioritize the deployment of the other updates appropriately.

Bulletin	Most likely attack vector	Bulletin severity	Max Exploit- ability Index	Likely first 30 days impact	Platform mitigations
MS09-072 (IE)	Attacker hosts a malicious webpage, lures victim to it.	Critical	1	Public exploit code already exists for CVE-2009-3672 affecting IE6 and IE7. We expect to see exploits for other vulnerabilities that affect other IE versions within 30 days.	DEP is enabled by default for IE8 on Windows XP SP3, Windows Vista SP1 and later, Windows Server 2008, and Windows 7. DEP makes exploiting the public vulnerability significantly more difficult.
MS09-073 (Wordpad converter)	Attacker sends malicious .doc file (saved in legacy Word version 8 format) to victim who opens it in Wordpad.	Critical	2	Less likely to be exploited in first 30 days.	Affects only older platforms.
MS09-071 (IAS)	Attacker on a wireless LAN attacks the Microsoft IAS server providing the 802.1x authentication and encryption via PEAP. Attack would be via the RADIUS protocol.	Critical	2	Less likely to be exploited in first 30 days.
MS09-074 (Project)	Attacker sends a malicious Project file (MPP) to victim who opens it with Project 2003 or earlier.	Critical (Critical on Project 2000 only)	2	Less likely to be exploited in first 30 days.	Affects only older versions of Project.
MS09-070 (ADFS)	Attacker able to authenticate to ADFS running in IIS can execute code within the IIS worker process.	Important	1	While an exploit may be developed in the first 30 days, the risk to most organizations is low because attack surface is only exposed to authenticated attackers.
MS09-069 (LSASS)	Attacker on enterprise network authenticates to a server and remotely causes CPU exhaustion.	Important	3	Unlikely to be exploited in first 30 days.	No chance of code execution

This month, we’ve also released an advisory and non-security updates changing Windows behavior around credential forwarding. Maarten Van Horenbeeck explains the current protections against credential reflection and credential forwarding in a blog post at http://blogs.technet.com/srd/archive/2009/12/08/extended-protection-for-authentication.aspx. Definitely take a look if you are concerned about safeguarding credentials against these types of attacks.

Also, we have also released an advisory describing a security mitigation offered to all customers through Windows Update. The Indeo Codec is an older codec that is known to have several security vulnerabilities. Instead of fixing one-off vulnerabilities in this older codec, we’ve released an update that blocks this codec from running in common attack scenarios, such as watching videos or browsing the internet. See Security Advisory 954157 for more information.

We hope that helps you understand this month’s security updates. We recommend that you apply all security updates but especially please prioritize and deploy MS09-072 as it has a Critical severity rating, an Exploitability Index rate of 1 (“Consistent Exploit Code Likely”), and public Proof of Concept (PoC) code is available.

Have a safe holiday season and let us know if you have any questions.

Special thanks to the entire MSRC Engineering team for their work on this month’s security bulletins! Thanks Andrew Roths for the help with this blog post.

- Jonathan Ness, MSRC Engineering

*Posting is provided "AS IS" with no warranties, and confers no rights.*

Extended Protection for Authentication

swiblog — Tue, 08 Dec 2009 17:59:00 GMT

This month, Microsoft is releasing several non-security updates that implement Extended Protection for Authentication as a mechanism to help safeguard authentication credentials on the Windows platform. These new updates are not security bulletins, but non-security updates that allow web clients using the Windows HTTP Services, IIS web servers and applications based on the HTTP Protocol Stack (http.sys) to use this feature, which was initially released in August of 2009. After release, developers and administrators still need to take action to configure the feature. More information can be found in Security Advisory 973811.

Extended Protection for Authentication helps protect authentication credentials when using Integrated Windows Authentication. Practically, they prevent an attacker that is able to get access to these credentials through another attack, for instance by soliciting a client to connect to him through social engineering, to use these credentials to log into another server to which the client has access.

These types of attacks are not new, but can pose a risk in specific deployment scenarios. Hence, this month as well, we released Security Advisory 974926, which documents how these attacks work, and the different steps Microsoft has taken to help administrators prevent them from being exploited. These include various updates we and our industry partners have released in the past, and the release of the Extended Protection feature that hardens authentication credentials.

This blog aims to clarify what this new feature really does, and how an administrator can start using it.

Why Extended Protection for Authentication?

Microsoft released Extended Protection to allow applications to better safeguard the use of authentication credentials being transferred between a client and server when using Integrated Windows Authentication (IWA). IWA allows a client to authenticate to a server without exposing the user’s password to any potential eavesdropper, typically by using NTLM or Kerberos authentication protocols.

A certain type of attack, known as credential relaying, is possible when using IWA as deployed in certain scenarios. If an attacker manages to elicit a client to connect to him, that attacker could take advantage of the authentication mechanism and use it to authenticate against a third party server on which the client has an account with identical credentials. In addition, the attacker could even authenticate against a service running on the client itself. However, an attacker could never learn the user’s password.

What does Extended Protection for Authentication do?

Extended Protection for Authentication aims to prevent this type of credential relay. It does this by implementing a protocol based on RFC 5056, “On the Use of Channel Bindings to Secure Channels”.

EAP creates the ability for a client’s authentication to be tied to an outer security channel so that the client authentication only happens under the protection of that same outer channel. To see how this works, suppose the client wants to authenticate to a web site. Here we can establish an outer TLS channel. EAP enables a connection to this channel in such a way that the client authentication won’t occur unless the outer TLS has been successfully established.

To see how this helps thwart credential relaying attacks, let’s take a look as an example. Let’s say that an attacker would manage to impersonate a server and succeed at having a client connect to him instead. The client would believe he is connecting to e.g. “webmail.contoso.com”. The attacker would take the credentials, set up a connection to another server on which the client has an identical account, for instance “fileserver.contoso.com.” He would then authenticate against that server.

At that point in time, if the server has Extended Protection for Authentication enabled, it will validate whether the authentication request was really intended for him, which it is not. In addition, if a TLS channel is present, it will validate whether the credentials were transferred over the same TLS channel. As the client initiates a TLS connection with the attacker, and he subsequently set up a new one with “fileserver.contoso.com,” this will also not match and the server will fail the authentication attempt.

How do I deploy Extended Protection for Authentication?

Deployment of Extended Protection for Authentication must happen on both the client and server for any given application. If only one side supports the feature, the connection will not benefit from the additional protection offered.

Below, we will provide a brief example on how to configure Extended Protection for a scenario that involves Internet Explorer and the Internet Information Services (IIS) web server.

The following prerequisites apply:

· On the client, KB968389 must be installed, which enables the Extended Protection feature in the Security Support Provider Interface (SSPI). This feature is automatically present on Windows 7 and Windows Server 2008 R2 machines;

· On the client, Internet Explorer cumulative update MS09-054 must be installed to enable Internet Explorer to use the feature;

· On the server, both KB970430 and KB973917 must be installed, which deploy this feature to HTTP.sys and the IIS web server.

An administrator must now enable the functionality offered by these updates:

· On the client, enabling Extended Protection is a machine-wide setting. It will apply to all applications that opt-in to the protection mechanism and use the SSPI for authentication. On Windows 7 and Windows Server 2008 R2 machines, the feature is enabled by default. On older platforms, upon installation of KB968389. Extended Protection must be enabled by setting the value of the registry key HKLM\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to 0. In addition, administrators should validate that the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel key is set to 3. This means that the client will only use NTLMv2 authentication, and will use NTLMv2 session security if the server supports it. This is important because Extended Protection for Windows authentication only protects NTLMv2 and Kerberos authentication, not NTLMv1.

· On the server, enabling the feature is a per-application setting. In order to protect the IIS web server, Extended Protection must be enabled as well. The instructions differ per IIS version, and more detailed configuration information can be found in KB973917.

On Internet Information Services 7.5, follow these guidelines to enable Extended Protection for Authentication in IIS:

1. On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

2. In the Connections pane, expand the server name, expand Sites, and then site, application or Web service for which you want to enable Extended Protection for Windows authentication.

3. Scroll to the Security section in the Home pane, and then double-click Authentication.

4. In the Authentication pane, select Windows Authentication.

5. Click Enable in the Actions pane.

1. Click Advanced Settings in the Actions pane.

2. When the Advanced Settings dialog box appears, select one of the following options in the Extended Protection drop-down menu:

a. Selecting Accept will enable a connection terminating on the IIS server to benefit from Extended Protection if the client has been configured to support it. Clients that have not enabled the feature will still be allowed to connect, but will not benefit from the additional protection.

b. Selecting Required will require clients to use Extended Protection. If they do not support it, any authentication attempts against IIS using IWA will fail.

Click OK to close the Advanced Settings dialog box.

If a user enables Extended Protection for Authentication, and attempts to connect to a server that does not support the feature, that authentication attempt will still succeed.

Can I support Extended Protection in my application?

This depends on the protocol. Many protocols can be protected, but some cannot. For instance, RPC does not support Extended Protection for Authentication, but can also be protected by enabling confidentiality/integrity.

Applications implementing other protocols, such as HTTP, can definitely benefit from this feature. We encourage developers to implement this feature. If your application uses the WinHTTP or WinINET programming interfaces, then you are indirectly already benefiting from this protection, as updates for both APIs are now available. Developers can find the SSPI headers for Extended Protection here.

Thanks to Mark Novak, Larry Zhu, Paul Leach and Paul Miller for their design and implementation work on this feature. Thanks also go out to Andrew Roths from the MSRC Engineering team for his technical feedback on this blog post.

-Maarten Van Horenbeeck, MSRC Program Manager

*Posting is provided "AS IS" with no warranties, and confers no rights.*

12/8/09 Update: Updated the links to security advisories 973811 and 974926.

SEHOP per-process opt-in support in Windows 7

swiblog — Sat, 21 Nov 2009 00:09:00 GMT

In a previous blog post we discussed the technical details of Structured Exception Handler Overwrite Protection (SEHOP) which is an exploit mitigation feature that was first introduced in Windows Vista SP1 and Windows Server 2008 RTM. SEHOP prevents attackers from being able to use the Structured Exception Handler (SEH) overwrite exploitation technique when attempting to exploit certain types of software vulnerabilities. SEHOP is enabled by default system-wide on Windows Server 2008 and disabled by default on Windows Vista. These are also the defaults settings in Windows Server 2008 R2 (enabled) and Windows 7 (disabled).

Although some applications have had compatibility problems with SEHOP, the vast majority of applications work without issue. In order to make it possible for compatible applications to take advantage of SEHOP, we have added support in Windows 7 that allows SEHOP to be enabled or disabled on a per-process basis. This setting will override the system default policy when it is used. SEHOP can be enabled for a process by setting the new DisableExceptionChainValidation Image File Execution Option (IFEO) to 0 (or disabled by setting it to 1). For example, SEHOP can be enabled for Internet Explorer on Windows 7 by applying the following registry script*:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\iexplore.exe]

"DisableExceptionChainValidation"=dword:00000000

Users running Windows Vista SP1+ or Windows 7 who would like to enable SEHOP for all applications (which we strongly recommend) can do so by installing the following FixIt:

Enable SEHOP for all applications

If enabling SEHOP for all applications leads to a problem with a specific application, the new IFEO in Windows 7 and Windows Server 2008 R2 can be used to disable SEHOP for just the affected process as described above. Alternatively, you can disable SEHOP for all applications by following the steps described in KB956607. If you cannot enable SEHOP for all applications we strongly recommend enabling SEHOP for all internet facing applications, such as your preferred browser and mail client.

Matt Miller, MSEC Science

* If you are running a 64-bit version of Windows, you will need to set the IFEO under the Wow6432Node portion of the registry which corresponds to the registry hive used by 32-bit applications (e.g. HKLM\Software\Wow6432Node\...)

*Postings are provided "AS IS" with no warranties, and confers no rights.*

Details on the License Logging Service vulnerability

swiblog — Tue, 10 Nov 2009 18:00:00 GMT

Today, we released MS09-064 which addresses a vulnerability in the License Logging Service. In this post, we provide some background on the service and the severity of the underlying vulnerability.

Background

License Logging Service (LLS) is a feature that was originally designed to help customers manage licenses for Microsoft server products licensed in the Server Client Access License (CAL) model. See http://support.microsoft.com/kb/824196 for more details. The service has been removed from the Windows Server product line starting with Windows Server 2008. Of the remaining supported platforms this issue only affects the Windows Server 2000 version of LLS.

Why is the bulletin severity “critical”?

The bulletin is marked as “critical” for several reasons:

· The service is enabled by default on Windows Server 2000.

· It is accessible by anonymous network connection.

· The underlying issue can lead to extensive heap memory corruption.

What are the mitigating factors?

There are two circumstances though that may lower its severity significantly.

First, the most common scenario of LLS feature calls for managing CALs within trusted enterprise environment, which in most cases means that the network access to the server hosting LLS will be limited to the local segment of a network, usually separated from the Internet by a firewall, proxy server, or other barrier.

Second, the issue leads to a memory corruption, which based on our analysis is very difficult to turn into remote code execution.

Technical details

The root cause of the problem is a lack of string verification for the presence of NULL-terminating characters. An unverified string lacking NULL-termination can be passed to a function, which performs following steps:

· calculate length of the unverified string,

· allocate buffer for a new string, using the calculated length and the length of some other string,

· concatenate two strings in the new buffer.

Since the length calculation of the unverified string can run beyond the string buffer (because of missing NULL termination), we may end up with four different scenarios depending on the heap memory layout at the time of execution:

1. During the string length calculation, code runs beyond string buffer and hits an unallocated memory page, causing read access violation.

2. During the string length calculation, code finds a NULL terminating character beyond the string buffer, returning an exaggerated length. The terminating character falls at lower address than the memory block allocated for the new string. The “exaggerated” string is concatenated with the other string in the new buffer, causing no memory access exception, because the length of the new buffer was calculated using the “exaggerated” length.

3. In scenario 2, another thread owning the block of memory containing the NULL-terminating character incorrectly used for the length calculation, changes the content of memory right after the length calculation, but before string concatenation. This causes a new buffer overflow during concatenation, leading to semi-controlled heap corruption and/or write access violation.

4. In scenario 2, the memory block allocated for the new string includes the NULL-terminating character. The character then gets overwritten during concatenation process, leading to extensive memory copying and causing write access violation.

Scenario 3 relies on a very narrow race condition and thus any attempt to exploit it is likely to be unreliable. The only scenario leading to a potentially reliable exploit is scenario 4. This leads us to a conclusion that real-life exploitation of this vulnerability will be less likely.

-Greg, MSRC Engineering

Vulnerability in Web Services on Devices (WSD) API

swiblog — Tue, 10 Nov 2009 18:00:00 GMT

MS09-063 addresses a critical vulnerability (CVE-2009-2512) in the Web Services on Devices (WSD) API. Web Services on Devices allows a computer to discover and access a remote device and its associated services across a network. It supports device discovery, description, control, and eventing.

The WSD API functionality is implemented in the WSDApi.dll module in Windows, and is used by several services and applications. The API is also documented on MSDN for 3^rd party developers to use. Therefore, a comprehensive list of services and application that are vulnerable to this issue is hard to define, but here are some examples:

· Print Spooler service

· Function Discovery Resource Publication service

· Function Discovery Provider Host service

· Windows Network Projector

There are mitigating factors that limit the scenarios where the vulnerability can be exploited. We will describe the vulnerability and mitigating factors in more detail in this blog post.

What is the issue?

A long header value within a WSD message can lead to stack corruption within the process hosting WSDApi.dll. This can cause the service or application to crash, or could lead to Remote Code Execution. To be clear, the vulnerability is in the Windows module used to interact with devices that support Web Services on Devices, and does not affect the devices themselves.

What platforms are affected?

Windows Vista and Windows Server 2008 are affected. WSDAPI was introduced in Windows Vista and hence earlier versions of Windows are not vulnerable.

Only systems with the WSD TCP ports active and listening are vulnerable to the most likely attack vector. Whether a system has WSD ports active and listening depends on the system configuration and applications that are installed.

What are the attack vectors?

By default, WSDAPI will listen on TCP ports 5357 and 5358. The Windows Firewall will allow messages in to these ports if the interface firewall profile is anything other than Public. This means under non-Public profiles (e.g. Private or Domain) the vulnerability can be reached by remote, unauthenticated users.

For an attacker to be able to trigger the vulnerability on a target, they need to know the WSD Address value for the target, which is a UUID (Universally Unique Identifier). This value is automatically sent in broadcast UDP messages to port 3702 (WS-Discovery) in an effort to discover devices that support WSD. Being broadcast UDP the message will only be visible to attackers on the same subnet. Attackers on other subnets, or on the Internet, will not be able to launch attacks against distant targets using this approach.

A system could also be exploited by a malicious device which responds to a client computer using WSDAPI. It is possible for the user to manually enter the URL of a device to connect to, in which case the device could respond with a malformed message and trigger the vulnerability. This requires user-interaction and social engineering, however.

Mitigating factors

As explained above, the most common exploit scenario requires that the attacker is on the same subnet as the target system in order for the target’s WSD Address to be discovered.

The default Windows Firewall rules limit inbound WSD messages to sources on the local subnet for Private and Domain profiles. The Public firewall profile blocks WSD messages completely.

If WSD functionality is not needed, the security bulletin provides information on using the Windows Firewall to block the inbound and outbound ports used to trigger this vulnerability.

I’d like to thank Rob Hain and Dan Driscoll from the WSD team, and Kevin Brown from MSRC Engineering for their work on this issue.

- Mark Wodrich, MSRC Engineering

Font Directory Entry Parsing Vulnerability In win32k.sys

swiblog — Tue, 10 Nov 2009 18:00:00 GMT

MS09-065 addresses a vulnerability (CVE-2009-2514) in the font parsing subsystem of win32k.sys. If not addressed, this vulnerability could allow an attacker to bluescreen (DoS) the machine (best case scenario) or run code of his/her choice, possibly in the context of the kernel (worst case scenario).

In this blog entry, I'll attempt to answer a few questions regarding the vulnerability addressed in this month’s win32k.sys security update:

What is the issue?

An integer-wrapping vulnerability exists in the font parsing subsystem within win32k.sys, which is responsible for constructing a table of directory entries. The integer wrap can occur when adding a directory entry’s’ offset and size members, which could lead to improper memory access in subsequent code. This improper memory access would commonly be observed in the form of a Read Access Violation.

The severity rating of critical was chosen since the vulnerable code is exposed through Internet Explorer and can be exercised without user interaction/notification. It has also been given an Exploitability Index rating of 1.

What platforms are affected?

Users of Windows 2000, Windows XP, and Windows Server 2003 are affected by this vulnerability. Windows Vista, Windows 7, Windows Server 2008, and Windows 2008 R2 users are not affected.

What are the attack vectors?

Remote attack vectors (worst case scenario is Remote code Execution):

- Malicious fonts (TTF’s) delivered within .eot files hosted on malicious web sites which are rendered in all versions of Internet Explorer by default.

- Malicious office documents e-mailed to victims with social engineering to entice the victim to open the document which contains a malformed embedded font which would then be rendered upon opening the Office document (PowerPoint and Word documents are the most likely attack vectors).

Local attack vectors (worst case scenario is Local Elevation of Privilege):

- Malicious fonts (TTF’s) delivered to win32k.sys by an authenticated user in a multi-user environment (Terminal Services (TS)) scenario. Such scenarios might abuse AddFontResource() to achieve this.

How do I protect myself?

The best option for protecting against this vulnerability is to apply the update for MS09-065.

If you are unable to apply the update, another option is to disable support for parsing/loading embedded fonts in IE. The side effect of this approach is that it will cause web sites which make use of embedded font technology to fail to render properly. The steps involved in disabling support for parsing embedded fonts in IE are as follows:

Interactive

· Launch Internet Explorer

· On the ‘Tools’ Menu select ‘Internet Options’.

· Click the ‘Security’ Tab.

· To change the setting for the ‘Internet’ zone select ‘Internet’ and press the ‘Custom Level’ button.

· Scroll down to the ‘Downloads’ section and select ‘Prompt’ or ‘Disable’ for the ‘Font Download’ security setting.

· Press OK to close the ‘Security Settings’ dialog box.

· Press OK to close the ‘Internet Options’ dialog box.

Group Policy

NOTE: The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit or an entire domain. It is assumed that the reader will know how to deploy the steps below for their particular environment.

· Open the group policy management and configure it to work with the appropriate group policy object (i.e. local machine, OU or domain GPO).

· Navigate to the following node:

o User Configuration -> Windows Settings -> Internet Explorer Maintenance -> Security.

· Double click ‘Security Zones and Content Rating’.

· On the ‘Security Zones and Content Rating’ dialog box select ‘Import the current security zones and privacy settings’ and then click the ‘Modify settings’ button.

· NOTE: This will create a group policy for Internet Explorer based on the settings of the currently logged in user.

· On the ‘Internet Properties’ dialog box ensure the ‘Internet’ zone is selected and then press ‘custom level’.

· Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.

· Press OK to return to the ‘Internet Properties’ dialog box.

· On the “Internet Properties’ dialog box select the ‘Local Intranet’ zone and then press ‘custom level’.

· Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.

· Press OK to return to the ‘Internet Properties’ dialog box.

· Press OK to return to the ‘Security Zones and Content Ratings’ dialog box.

· Press OK to return to the group policy management console.

· Refresh the group policy on all machines or wait for the next scheduled group policy refresh interval for the settings to take effect.

Managed Deployment Script

This security setting can be manually entered into the registry by creating a registry script and importing it either by double clicking it or running regedit.exe as part of a logon or machine startup script. For managed deployments Regedit.exe can be used to import a registry script silently with the ‘-s’ switch. For more information on regedit command line switches refer to: http://support.microsoft.com/kb/q82821/

To set this setting to ‘Prompt’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00

; Zone 1 is the local intranet zone

; 1604 is the Font download policy

; dword:00000001 sets the policy to prompt

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]

"1604"=dword:00000001

; Zone 3 is the internet zone

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]

"1604"=dword:00000001

To set this setting to ‘Disable’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00

; Zone 1 is the local intranet zone

; 1604 is the Font download policy

; dword:00000003 sets the policy to disable

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]

"1604"=dword:00000003

; Zone 3 is the internet zone

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]

"1604"=dword:00000003

Big thanks to Robert Hensing from the MSRC Engineering Team for his work on defensive workarounds for this issue as well as to Andrew Roths from the MSRC Engineering Team.

-Brian Cavenah, MSRC Engineering

Announcing the release of the Enhanced Mitigation Evaluation Toolkit

swiblog — Tue, 27 Oct 2009 16:21:00 GMT

Even as you read this, people around the world are hunting for vulnerabilities in software applications. Odds are some of them will be successful. Depending on their motives and what they find, your software and systems may be put at risk. So how do you protect your software from unknown vulnerabilities that may or may not exist? One option is to use security mitigations.

Microsoft offers a number of different mitigation technologies that are designed to make it more difficult for an attacker to exploit vulnerabilities in a given piece of software. Take a look at Michael Howard’s article “Protecting Your Code with Visual C++ Defenses” (http://msdn.microsoft.com/en-us/magazine/cc337897.aspx) for a brief overview of some of these technologies.

To help on this front, we are announcing the initial release of a new utility called the Enhanced Mitigation Evaluation Toolkit (EMET). Version 1.0.2 is now available, free of charge at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkID=162309). This utility builds on our current offerings in several key ways:

1. Until now, many of the available mitigations have required for an application to be manually opted in and recompiled. EMET changes this by allowing a user to opt in applications via a simple command-line utility without recompilation. This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available.

2. EMET provides a higher degree of granularity by allowing mitigations to be applied on a per process basis. There is no need to enable an entire product or suite of applications. This is helpful in situations where a process is not compatible with a particular mitigation technology. When that happens, a user can simply turn EMET off for that process.

3. Mitigations that have previously been limited to up-level versions of Microsoft Windows now ship with EMET and are available down-level. Users can benefit from these mitigations without the need to upgrade their systems.

4. EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from mitigations before they are included in the next versions of our products. It also gives users the opportunity to provide feedback and help guide the future of mitigation technologies in Microsoft products.

Supported Mitigations

This initial release of EMET is primarily focused on providing an extensible framework that will have future mitigations added to it. A total of four mitigations are also being included with this release and are listed below. We will provide announcements as future mitigations are added. If you have ideas about mitigations you’d like to see (whether they already exist or not) feel free to contact us.

SEHOP

This mitigation performs Structured Exception Handling (SEH) chain validation and breaks SEH overwrite exploitation techniques. Take a look at the following SRD blog post for more information: http://blogs.technet.com/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx. With this protection in place, the msvidctl exploit we already blogged about (http://blogs.technet.com/srd/archive/2009/07/28/msvidctl-ms09-032-and-the-atl-vulnerability.aspx) would have failed.

Dynamic DEP

Data Execution Prevention (DEP) is a memory protection mitigation that marks portions of a process’ memory non-executable. This makes it more difficult to an attacker to exploit memory corruption vulnerabilities. For more information on what DEP is and how it works, take a look at the two part SRD blog available at http://blogs.technet.com/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-1.aspx and http://blogs.technet.com/srd/archive/2009/06/12/understanding-dep-as-a-mitigation-technology-part-2.aspx.

NULL page allocation

This blocks attackers from being able to take advantage of NULL dereferences in user mode. It functions by allocating the first page of memory before the program starts. Right now the exploitation techniques for these types of vulnerabilities are only theoretical. However, this mitigation will protect you even if that changes. Please note this protection does not impact kernel mode NULL dereferences as the current version of EMET only supports user mode mitigations.

Heap spray allocation

Heap spraying is an attack technique that involves filling a process’ heap with specially crafted content (typically including shellcode) to aid in exploitation. Right now, many attackers rely on their content being placed at a common set of memory addresses.

This mitigation is designed to pre-allocate those memory addresses and thus block these common attacks. Please note that it only aims to break current exploit that take advantage of these common addresses. It is not a general mitigation for the larger heap spraying attack. That said, if attackers do change the addresses they use, EMET users can change the addresses

A Note about Application Compatibility

Security mitigations carry an application compatibility risk with them. Some applications rely on precisely the behavior that the mitigations block. For this reason mitigations are typically turned off by default and require opt-in from a developer before they are enabled. While EMET allows users to override this, it is important to be aware of the risk. EMET is intended for tech savvy users such as IT professionals and security researchers who can troubleshoot issues that these mitigations may introduce. We also recommend testing your applications and use scenarios with these mitigations prior to deploying them on any production systems.

Feedback

We encourage you to download and try out the tool. If you have any feedback on your experiences with the tool, you can reach us at switech@microsoft.com .

Special thanks to Matt Miller for his assistance with EMET.

- Fermin J. Serna and Andrew Roths, MSRC Engineering