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
The Khronos Group’s WebGL technology is a cross-platform, low-level 3D graphics API for the web. Recently, Context Information Security published two reports critical of the WebGL technology, WebGL – A New Dimension for Browser Exploitation and WebGL – More WebGL Security Flaws.
One of the functions of MSRC Engineering is to analyze various technologies in order to understand how they can potentially affect Microsoft products and customers. As part of this charter, we recently took a look at WebGL. Our analysis has led us to conclude that Microsoft products supporting WebGL would have difficulty passing Microsoft’s Security Development Lifecycle requirements. Some key concerns include:
The security of WebGL as a whole depends on lower levels of the system, including OEM drivers, upholding security guarantees they never really need to worry about before. Attacks that may have previously resulted only in local elevation of privilege may now result in remote compromise. While it may be possible to mitigate these risks to some extent, the large attack surface exposed by WebGL remains a concern. We expect to see bugs that exist only on certain platforms or with certain video cards, potentially facilitating targeted attacks.
As WebGL vulnerabilities are uncovered, they will not always manifest in the WebGL API itself. The problems may exist in the various OEM and system components delivered by IHV’s. While it has been suggested that WebGL implementations may block the use of affected hardware configurations, this strategy does not seem to have been successfully put into use to address existing vulnerabilities.
It is our belief that as configurations are blocked, increasing levels of customer disruption may occur. Without an efficient security servicing model for video card drivers (eg: Windows Update), users may either choose to override the protection in order to use WebGL on their hardware, or remain insecure if a vulnerable configuration is not properly disabled. Users are not accustomed to ensuring they are up-to-date on the latest graphics card drivers, as would be required for them to have a secure web experience. In some cases where OEM graphics products are included with PCs, retail drivers are blocked from installing. OEMs often only update their drivers once per year, a reality that is just not compatible with the needs of a security update process.
Modern operating systems and graphics infrastructure were never designed to fully defend against attacker-supplied shaders and geometry. Although mitigations such as ARB_robustness and the forthcoming ARB_robustness_2 may help, they have not proven themselves capable of comprehensively addressing the DoS threat. While traditionally client-side DoS is not a high severity threat, if this problem is not addressed holistically it will be possible for any web site to freeze or reboot systems at will. This is an issue for some important usage scenarios such as in critical infrastructure.
We believe that WebGL will likely become an ongoing source of hard-to-fix vulnerabilities. In its current form, WebGL is not a technology Microsoft can endorse from a security perspective.
We recognize the need to provide solutions in this space however it is our goal that all such solutions are secure by design, secure by default, and secure in deployment.
- MSRC Engineering
Today we released 16 security bulletins. Nine have a maximum severity rating of Critical and seven have a maximum severity rating of Important. This release addresses several publicly disclosed vulnerabilities. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
Please let us know (switech at microsoft dot com) if you have any questions about these updates.
Jonathan Ness, MSRC Engineering
Today we have released MS11-044 to address CVE-2011-1271, a remote code execution vulnerability in the .NET framework. Here we would like to provide more technical information about this vulnerability and why we believe this issue to be unlikely to be exploited.
This root cause of CVE-2011-1271 is that there was a bug in the JIT compiler which would cause it to mistakenly determine that a given object is always null (or non-null) and would omit certain checks.
if ((value == null || value == new string) == false)
00000027 test esi,esi ; value == null?
00000029 je 00000075
0000002b xor edx,edx ; new string
0000002d mov ecx,6D913BD2h
00000032 call FFD20BC8
00000037 cmp eax,esi ; value == new string?
00000039 je 00000075
Console.WriteLine("Post-check Value is: " + value);
0000003b mov ecx,dword ptr ds:[03532090h] ; "Post-check value is: "
00000041 xor edx,edx ; Wrong here.
00000043 call 6D70B7E8 ; String.Concat()
00000048 mov esi,eax ;
0000004a call 6D72BE08 ; get Console.Out
0000004f mov ecx,eax
00000051 mov edx,esi
00000053 mov eax,dword ptr [ecx]
00000055 call dword ptr [eax+000000D8h] ; Console.WriteLine()
At offset 0x41, the optimizer has incorrectly concluded that value will always be null so it directly passes a null to String.Concat().
For CVE-2011-1271, the JIT compiler can introduce a logic flaw when running C# or IL code sequences very similar to those describe above. Depending on the .NET application’s business logic, if the NULL check (or non-NULL check) is used to make a security decision, for example the check of certain credentials, and if the attacker controlled data may leverage directly or indirectly this missing logic and gain advantages based on this, then there is a possibility of remote code execution. However, we do not believe this to be a common case for the majority of deployed .NET applications.
Special thanks to Reid Borsuk in .NET team.
Fermin Serna and Chengyun Chu, MSRC Engineering
Today, we released MS11-050, a cumulative security update for Internet Explorer to address several vulnerabilities in IE9.
The following table lists the CVEs included in MS11-050, and whether each affects IE8 or IE9.
As shown above, only a minor fraction of vulnerabilities affecting IE8 (and earlier versions of the browser) would still affect IE9. This is due to various factors related to security work that happened in IE8, ranging from deprecating obsolete features, to improving fuzzing tests in IE9 and so on. For example, CVE-2011-1255 is related to HTML+TIME, which was deprecated in IE9 development.
There are many beautiful things in IE9. Besides all these wonderful new features, we would also recommend you to update to IE9 if you can for security. :)
Chengyun Chu, MSRC Engineering
Today we are pleased to announce a new version of the Enhanced Mitigation Experience Toolkit (EMET) with brand new features and mitigations. Users can click here to download the tool free of charge.
The Enhanced Mitigation Experience Toolkit enables and implements different techniques to make successful attacks on your system more difficult. EMET is designed to mitigate exploitation attempts (even of 0-days) by making “current” exploitation techniques harder and less reliable. Users interested in finding out more about EMET can read more here.
EMET has a proven track record of stopping real-life attacks, as we have detailed in our previous blog-posts here , here and here.
This release marks a big milestone for EMET since this is the first version that is available as an officially-supported product. Support will be forum based available here.
Today’s release comes with some new features:
I would like to thank Matt Miller for his work on EMET.
- Fermin J. Serna, MSRC Engineering
Today we released 17 security bulletins. Nine have a maximum severity rating of Critical and eight have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.
In addition to the bulletins, two interesting advisories are being released today. Security advisory 2501584 describes a great protection mechanism available for Office 2003 and Office 2007 customers to download and install. The Office team’s blog post about the tool is available at http://blogs.technet.com/b/office_sustained_engineering/archive/2011/04/11/office-file-validation-general-availability-announcement.aspx.
The second advisory, KB 2506014, hardens Windows against kernel-mode rootkits. This specifically breaks the hiding mechanism used by the current Alureon/TDL4 rootkit family. It is an update available on WU and WSUS, pushed out automatically to customers who have opt-in to Automatic Updates.
If you have any questions about these updates, please email us at switech [at] microsoft [dot] com. You can also tune into the MSRC webcast tomorrow where I’ll be answering questions on-the-air. The MSRC blog post has all the information for that.
Update April 13: Corrected the MS11-028 bulletin severity and affected products. Also moved this bulletin up higher in priority due to this correction.
*Update April 15: Corrected the MS11-032 bulletin exploitability due to a rating error. Also moved MS11-032 higher in priority order.
- Jonathan Ness, MSRC Engineering
Today we released security bulletin MS11-034 to address vulnerabilities in the win32k subsystem. This update addresses externally reported issues as well as several internally found vulnerabilities that were discovered as part of our variant investigation.
The bulletin may appear to address an alarmingly large number of issues. However, if you dig into the issues themselves, you’ll find that the 30 vulnerabilities addressed in this update really just share three separate vulnerability root causes: insufficient validation or locking of win32k objects after a user-mode callback. The security researcher who discovered these issues, Tarjei Mandt, applied the same technique to every different win32k object type. This blog post aims to outline the differences between the three vulnerability subclasses as well as cover additional details of the vulnerabilities fixed in this month's update.
The first vulnerability class pertains to the absence of locking win32k objects. Objects that are not locked prior to executing user-mode callbacks, therefore objects can be manipulated once control has been passed back to the user via callback. This means an object can be modified or freed before returning back to the kernel. Our observations indicate that memory re-use can be leveraged to gain elevation of privileges in some cases.
The second vulnerability class pertains to the absence of validation on menu items after a user-mode callback returns resulting in a typical use-after-free vulnerability. A malicious user could destroy a menu during the user-mode callback causing certain kernel functions to operate on dangling pointers.
The third vulnerability class pertains to the absence of validation of DDE conversation objects after user-mode callbacks which could result in a NULL pointer dereference. This can allow a standard user to elevate privileges or to cause a denial of service condition depending on the usage of the object after the user-mode callback. Investigation indicated that elevation of privileges was possible for at least a couple of the reported DDE vulnerabilities.
Finally, we would like to clarify the exploitability of these issues. These vulnerabilities can allow a standard user to elevate privileges because arbitrary code can be executed while the CPU is running in Supervisor mode. None of the vulnerabilities we've addressed in this month's update can be triggered remotely, hence the Important severity rating. For a local attacker able to run code on a compromised system, most of the vulnerabilities fixed in this package are straightforward to exploit.
Thanks to Thomas Garnier in the UK Science team, Jonathan Ness, Matt Miller, and Tarjei Mandt
- Richard van Eeden and Brian Cavenah, MSRC Engineering
This month we released updates for the SMB client and server components (MS11-019 and MS11-020 respectively). These bulletins address three externally-reported issues, but also include fixes for several issues that Microsoft identified internally. This blog post provides background on these issues and the work done internally at Microsoft to improve SMB security.
Finding and issuing fixes to additional security vulnerabilities is part of our standard security update process, and is covered in detail in a previous blog post via the following link: http://blogs.technet.com/b/srd/archive/2011/02/14/additional-fixes-in-microsoft-security-bulletins.aspx
Working to enhance the security landscape, a team of people across the Windows, Windows Sustained Engineering and TWC Security groups at Microsoft spent the last year identifying new methods to improve SMB updates. Typically, SMB updates have focused on finding variants of externally-reported issues (“hacking for variations”) to help ensure a comprehensive security bulletin that would not put customers at risk once the update is reverse-engineered by attackers. In order to increase the effectiveness of this month’s SMB update, Microsoft used an even wider scope for identifying variants and increased the time and resources devoted to the update.
What led to the wider scope?
Over the past two years SMB has been a target for security researchers, and Microsoft released several security updates as new issues were reported. As part of each of the preceding updates, we followed our standard “hacking for variations” approach, but with a tighter timeline mandated by the need to address reported issues as quickly as possible.
It was clear that even without additional issues being reported, there were things we could focus on and improve in terms of our internal security testing, code auditing and design reviews. As a result, we kicked off a longer-term project to identify additional security issues in the SMB code, with an eye on releasing fixes in a future security bulletin. This “SMB Security Scrub” led to the fixes included in the April bulletin release.
What was done?
The following initiatives were part of the SMB Security Scrub:
The end result is more than 1000 lines of source code changed per version of Windows.
Given Microsoft’s commitment to improving the security landscape for its customers, this new method will continue, and the improved tools and processes identified from this ongoing research will be applied to future SMB security updates and new versions of Windows.
Do the additional issues affect bulletin severity or deployment priority?
The bulletin severity for both the SMB server and client bulletins is already Critical based on the externally-reported issues. As a result, the internally-found issues do not cause an increase in bulletin severity. The severity, impact and attack scenarios are covered by the externally-reported issues described in the bulletin, and therefore these issues do not affect deployment priority.
Finally, I would like to thank everyone at Microsoft that worked on these SMB updates for their hard work!
- Mark Wodrich, MSRC Engineering
Today Microsoft released MS11-018 addressing one of the three vulnerabilities that were used to win the Pwn2Own contest last month at CanSecWest 2011. It took three vulnerabilities to successfully compromise IE8 and meet all the requirements of the organizers.
The vulnerability we are fixing today, a use-after-free which does not affect IE9, was the primary vulnerability used to gain code execution. A second vulnerability was used to make the exploit more reliable and a third was used to escape IE’s protected mode.
Why IE9 was not affected?
During the development of IE9 several security features were built in to catch as many security issues as possible early in the process. This one was found by fuzzing and was fixed by the IE team about 10 months ago. Also, another vulnerability that was used as an information leak during the contest was also found and fixed during IE9 development.
Why did it take so few weeks to fix this vulnerability?
Normally, all security fixes go through an extensive phase of regression testing. This particular fix did too but since the issue had been previously tested on IE9, we were able to move forward faster with the fix.
When is Microsoft fixing the other two vulnerabilities?
First, it’s important to explain the other two issues:
Both are currently being evaluated and will be fixed in an upcoming release cycle but, without MS11-018 (the vulnerability we are fixing this month) the other two vulnerabilities do not pose a direct threat to customers.
Fermin J. Serna, MSRC Engineering