Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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