Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
How can you protect yourself, your business, and your customers when faced with an unknown or unpatched software vulnerability? This question can be difficult to answer but it is nevertheless worthy of thoughtful consideration. One particularly noteworthy answer to this question is provided in the form of exploit mitigation technologies such as DEP and ASLR, which are designed to make it difficult and costly for an attacker to exploit a software vulnerability. The protection offered by exploit mitigations is generally independent of a single vulnerability and therefore opens the door to protecting against the exploitation of vulnerabilities that may currently be unknown or that have not yet been addressed through a security update.
The virtues of exploit mitigations are something that we strongly believe in at Microsoft. This belief is clearly demonstrated by the exploit mitigation features we have added to our products over time (DEP, ASLR, /GS, etc) and through policies in the Microsoft’s Security Development Lifecycle (SDL) that require product teams to leverage these features. Although many of these technologies have been available for quite some time, we have found that adoption by third-party software vendors has been slower than we would like. We have also heard from many enterprise administrators that they have difficulty justifying the use of exploit mitigations or are hesitant to make use of them because of performance and compatibility concerns. This is something we would like to change.
In the interest of helping to encourage adoption within the enterprise and by third-party software vendors, we have published a paper entitled Mitigating Software Vulnerabilities. This paper provides justification for the use of exploit-mitigation technologies and enumerates the set of technologies that are available today. The description of each technology includes an overview of how the technology works and what performance, compatibility, and deployment considerations should be taken into account, if any. The availability of each technology is also presented for supported operating system and compiler versions. The paper concludes with a set of recommended actions for software developers, enterprise administrators, and home and business users. In particular, we recommend that the Enhanced Mitigation Experience Toolkit (EMET) be used to evaluate the impact of enabling certain mitigations and to protect systems and applications that may be at-risk.
It is our hope that this paper will demonstrate the need for exploit mitigations and help encourage adoption of exploit mitigation technologies within the Windows ecosystem. We encourage you to check back frequently for more information about upcoming security tools and technologies at http://www.microsoft.com/security/msec.aspx.
- Matt Miller, Microsoft Security Engineering Center
The single Critical vulnerability in today’s batch of security updates addresses an issue in the Bluetooth stack. Your workstations’ risk to this vulnerability varies, depending on a number of factors. I’d like to use this blog post to outline those risk factors.
How can I protect my system?
The best way to protect any potentially vulnerable system is to apply the MS11-053 security update. If you are not able to apply the security update, you can close off the attack surface by preventing any Bluetooth device from connecting to your computer. The graphic below shows the Windows 7 Bluetooth Settings option for doing so. Side effect: Your Bluetooth mouse or headset will stop working until you re-allow Bluetooth devices to connect to your computer.
Am I vulnerable to remote code execution attacks today?
Short answer: Probably not. And here’s why:
Exploitability: First, we assigned this vulnerability with an Exploitability Index rating of “2”. We believe it will be difficult to build a reliable exploit for code execution using this vulnerability. It’s more likely that attackers will discover a way to cause a system denial-of-service (“bugcheck” / “bluescreen”) using this vulnerability.
Discoverability: Secondly, your system’s 48-bit Bluetooth address is not “discoverable” by default. Notice in the Bluetooth Settings screenshot above that Bluetooth devices are not allowed by default to “find” this computer. If your system were “discoverable,” it would respond to attacker SDP queries with its Bluetooth address. But in the default state, an attacker must obtain your Bluetooth address another way – either via bruteforcing it or extracting it from Bluetooth traffic captured over-the-air.
Extracting Bluetooth address by sniffing traffic: If you have paired a Bluetooth peripheral and are actively communicating, it is hard but not impossible to extract the Bluetooth address from the traffic sent over-the-air. A device is available on the market for $10,000 - $30,000 to do this in about 5 minutes. Research continues to advance in this space and we expect in years to come that this will become quicker for attackers. But for now, it remains difficult but not impossible to extract the Bluetooth address from over-the-air traffic.
Proximity: Finally, while this vulnerability is exposed remotely, it is not reachable over the Internet. An attacker must be physically nearby to target you. Again, recent research has widened the definition of “nearby” for Bluetooth but suffice to say that an attacker would need to be within line-of-sight. This nearby attacker then could spend several hours brute-forcing your Bluetooth address and attempting to exploit the vulnerability.
This combination of factors leads us to believe that systems are unlikely to be exposed to reliable remote code execution exploits via this vulnerability in the next 30 days.
Thanks to Krupa Poobala-chandran from the Windows Sustained Engineering team for the help yesterday afternoon pulling this blog post together.
- Jonathan Ness, MSRC Engineering
Today we released security update MS11-056 to address vulnerabilities in the Windows Client/Server Runtime Subsystem (CSRSS) and Console Host (conhost.exe). We also closed an internally found elevation of privilege attack vector on Windows 7 and Windows Server 2008 R2, significantly reducing the opportunity for any console issues discovered in the future to result in elevation of privilege on those platforms.
What’s the risk?
An attacker already able to run code on a system could use the vulnerabilities addressed in MS11-056 to elevate privileges on the system. On Windows XP and Windows Vista systems, an attacker able to execute code at a low privilege could potentially execute arbitrary code as SYSTEM within the context of the Client/Server Runtime Subsystem. On Windows 7 and Windows Server 2008 R2 systems, the affected code was moved to a different process (conhost.exe) running at the same privilege level as the logged-in user.  Therefore, an attacker could potentially execute arbitrary code in the context of another Console Host process if there is a higher privileged process with a console.
The vulnerabilities are caused by insufficient validation of specific console API messages. On Windows XP and Windows Vista, the handling of Console API messages happens inside the Client/Server Runtime Subsystem, while on Windows 7 and Windows Server 2008 R2 a separate conhost.exe process is created running with the same credentials as the associated console application. 
Internal research discovered a scenario on Windows 7 and Windows Server 2008 R2 in which a memory corruption issue inside Console Host still could lead to elevation of privileges. MS11-056 fixes the memory corruption vulnerabilities on Windows XP and Windows Vista and also closes this cross-user scenario on Windows 7 and Windows 2008 R2. Console Host memory corruption issues on Windows 7 and Windows Server 2008 R2 should now result “worst-case” in code running in the same context as the attacker already able to execute code directly.
-Richard van Eeden, MSRC Engineering