Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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]
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\iexplore.exe]
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.*
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.
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.
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
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 3rd 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.
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.
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:
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.
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.
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:
· 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.
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’.
· 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:
; Zone 1 is the local intranet zone
; 1604 is the Font download policy
; dword:00000001 sets the policy to prompt
; Zone 3 is the internet zone
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:
; dword:00000003 sets the policy to disable
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