The official corporate security response blog
@MSFTSecResponse
How to Report a Vulnerability to the MSRC
Just as a followup to our last post, this evening we have posted a security advisory detailing what you can do to protect yourself from the Win32/MyWife.E worm (hint, don't open attachments!) as well as additional info on how to get cleaned from it if you have been infected (hint, we recommend using the Windows Live Safety Center Beta at http://safety.live.com). The Antimalware team has also blogged on this as well.
Here's the advisory:
http://www.microsoft.com/technet/security/advisory/904420.mspx
S.
*This posting is provided "AS IS" with no warranties, and confers no rights.*
Hi everyone, just wanted to quickly point out that the Anti-malware team has posted a short note on the Win32/Mywife.E mass mailer worm. Pretty much all current AV protects against this worm, so running updated anti-virus is an important thing to do. In addition Windows OneCare members are also protected. The worm doesn't exploit a vulnerability, and requires user interaction. There's more over at the anti-malware blog.
Why is security@microsoft.com an auto-responder and not a redirect to secure@microsoft.com?
Well, security@microsoft.com is the Microsoft internal physical security alias, and has been since we started using email. As I am sure you can imagine, the amount of email we get at that alias that is external is quite a lot. Thus the autoresponder instead of a human filter which informs you that secure@microsoft.com is the appropriate alias to report security vulnerabilities (and points to other security related resources).
Good question. Remember that PlayMetafile and its ability to call code out of the metafile itself was designed 16-17 years ago for Windows 3.0/3.1. Again, this was back when more of what an application could do was trusted (like executing code out of a metafile) because the environment was cooperative. There was nothing to be gained by trying to elevate privilege through a memory crash, every process already ran at the same privilege cooperatively in the Windows 16 bit world. Seems like a long time ago in a galaxy far far away doesn't it?
The general Windows NT team's implementation of the functionality worked the way it was originally designed. A separate team, the Windows 95 team, took a different route when they supported the function by adding the step mentioned in my previous post. Now here's an interesting factoid. People tend to think that one team developed all the operating systems in a linear fashion, Windows 3.1 to Windows NT 3.5 to Windows 95, to Windows NT 4.0 to Windows 98/98SE, to Windows Me to Windows 2000, to Windows XP to Windows Server 2003.
Actually, Windows 95 and Windows NT 3.5 were developed almost concurrently by two separate teams. Then, Windows NT 4.0 was developed, while a separate team developed Windows 98. That team went on to develop Windows 98 Second Edition and Windows Me while the NT team developed Windows 2000. The teams and codebases started to really combine around the time of Windows XP’s development. I'm leaving out some interim products like Windows 95 Service Pack 1, Windows 95 OSR2, and Windows NT 3.51, but you get the drift. The Win9x guys had implemented the functionality differently than the NT codebase team and that change didn't get migrated. As I mentioned before, this is why we have implemented new changes in the SDL to help us catch old functionality like this and learn from it.
Hi everyone, Stephen Toulouse here. Now that the monthly release has passed and people are deploying the updates I wanted to take a moment to discuss some things related to questions we’ve been receiving on the recent WMF issue. (Which was addressed in MS06-001).
One question we’ve gotten is about SetAbortProc, the function that allows printing jobs to be cancelled. (The link is to the public documentation of the function)
Specifically people are wondering about how the vulnerability was present. Bear with me, I’m going to get rather technical here in the interests of clearly pointing it out. The long story short is that the vulnerability can be triggered with either correct OR incorrect metafile record size values, there seems to have been some confusion on that point.
To detail it a little bit, SetAbortProc functionality was a needed component in the graphics rendering environment for applications to register a callback to cancel printing, before even the WMF file format existed. Remember, those were the days of co-operative multitasking and the only way to allow the user to cancel a print job would be to call back to them, usually via a dialog. Around 1990, WMF support was added to Windows 3.0 as a file-based set of drawing commands for GDI to consume. The SetAbortProc functionality, like all the other drawing commands supported by GDI, was ported over (all in assembly language at this point) by our developers to be recognized when called from a WMF. This was a different time in the security landscape and these metafile records were all completely trusted by the OS. To recap, when it was introduced, the SetAbortProc functionality served an important function.
The vulnerability was introduced when all that GDI functionality was allowed to be called from metafiles. The potential danger of this type of metafile record was recognized and some applications (Internet Explorer, notably) will not process any metafile record of type META_ESCAPE, the overall type of the SetAbortProc record. That restriction is the reason it's not possible to exploit this vulnerability by simply referencing an image directly in HTML. IE just won't process it. How then is Internet Explorer an attack vector for the vulnerability? An example of that is through the Windows Picture and Fax Viewer. That application can convert a raw WMF into a printable EMF record. During this conversion, the application will process the META_ESCAPE record. All the current exploits we’re aware of are based on creating an html construct using an IFRAME. At a high level, the IFRAME passes off content to the Windows shell to display. The shell looks up the registered handler for WMF which is the Windows Picture and Fax Viewer (shimgvw.dll) by default. It can run into the vulnerability when converting a raw WMF to a printable EMF if MS06-001 is not applied to the system.
Now, there’s been some speculation that you can only trigger this by using an incorrect size in your metafile record and that this trigger was somehow intentional. That speculation is wrong on both counts. The vulnerability can be triggered with correct or incorrect size values. If you are seeing that you can only trigger it with an incorrect value, it's probably because your SetAbortProc record is the last record in the metafile. The way this functionality works is by registering the callback to be called after the next metafile record is played. If the SetAbortProc record is the last record in the metafile, it will be more difficult to trigger the vulnerability.
The next question we’ve been getting is around previous operating systems like Windows 98, Windows 98 SE, and Windows Me. Specifically people are wondering why there is no update available for these platforms. Well first off it’s extremely important to note that these products are under an extended support lifecycle. Back in 2004, we made a decision that we would extend support for security updates for updates rated as Critical only through June of 2006 for these older operating systems. We publicly posted the policy at the following location:
http://support.microsoft.com/gp/lifean1
With WMF we want to be very clear: the Windows 9x platform is not vulnerable to any "Critical" attack vector. The reason Windows 9x is not vulnerable to a "Critical" attack vector is because an additional step exists in the Win9x platform: When not printing to a printer, applications will simply never process the SetAbortProc record. Although the vulnerable code does exist in the Win9x platform, all "Critical" attack vectors are blocked by this additional step. The remaining attack vectors that we have identified require extensive user interaction and are not rated "Critical". Again the "Critical" rating refers to code execution attacks that could result in automated attacks requiring little or no user interaction.
I’d like to thank the members of the Secure Windows Initiative team for the supplemental research and history on this.
Once again we urge everyone to deploy MS06-001 for the supported platforms, and thanks for the feedback we’ve been getting!
I wanted to let you know about a new offering that those of you enterprise customers that download multiple security updates in multiple languages might find useful. Starting with the January 2006 release, each month we're making security and high-priority non-security updates that are available on Windows Update also available on an ISO-9660 CD image. This has items available from Windows Update only, so this means that you won't find updates for things like Office or Exchange.
This isn't intended for end users. It doesn't have any automated version detection or any comprehensive installation mechanism. Instead, it's really intended to make life easier for folks who download and manage multiple updates. For example, MS06-002 has 125 separate packages for all languages and versions.
We still want to encourage folks to use tools like WSUS and SMS. However, if you're not using these and have your own internal deployment methodology, this is a great option to save yourself some time.
For more Information on the January 2006 Security and Critical Releases ISO Image, see Knowledge Base article 913086: http://support.microsoft.com/kb/913086 . I’m also going to add a link in the January Summary so that you can get to it from there. We’ll try and make that regular offering in the summary when it is applicable.
Thanx,
Craig Gehre
Hey folks – Mike Reavey here stepping in for Craig as he continues to work through some last minute issues on this Tuesday’s release. Today we’ve released two Security Bulletins. The first one, MS06-002 resolves a vulnerability in Font processing in Windows and is rated Critical. The second bulletin, MS06-003 is also rated Critical, and applies to Office and Exchange customers, and resolves an issue in Transport Neutral Encapsulation (TNEF). We’re actively working through a delay on getting the MS06-003 updates to propagate through the global servers for Microsoft Update and WSUS. We expect the updates to be on-line and ready by 12:00PM Pacific Time. For folks using the ITMU and SMS, the catalog will be live for the entire release once the issues are resolved. Estimated time is 1:30PM Pacific Time. In the meantime, the updates are available on the Microsoft Download Center and can be accessed from the links with in the Security Bulletin. For folks using Windows Update, SUS, and SMS with MBSA 1.2 there are no delays for any packages.
One question we get when there are delays is “Why not hold everything, until it all goes at the same time, everywhere?” We always aim for that as a goal and when we’re aware of the delays before propagation begins we do work to sync it all up. However, in order to hit a 10AM target through all systems, we have to publish through several independent channels at once, in parallel. In today’s case, pausing the posting of updates to the Download Center and Windows Update to wait for the posting to Microsoft Update would actually have resulted in a delay in these updates appearing on the Download Center and Windows Update as we reset the release process. This means we would then see the updates appear first on Microsoft Update ahead of the Download Center and Windows Update. Based on this, we’ve gone ahead and released the bulletin for MS06-003 so folks would be able to read and understand the issues being resolved in detail while we continued pushing through Microsoft Update.
Updated: 10 January 2006 2:44 PM PT
Quick update folks – I wanted to let everyone know that all the updates for MS06-003 went live on Microsoft Update at 12:00PM as expected, and the catalog for the ITMU http://www.microsoft.com/smserver/downloads/2003/tools/msupdates.mspx is now live as well. Thanks very much for your patience.
Also, I know there was a question out there about the behavior of the WMF update through autoupdate, just wanted to be clear that the update behaves just like any update released through automatic update and will respect your existing settings regarding prompting for a restart or automatic restart, depending on what you have chosen.
Lennart Wistrand here. I wanted to write a few lines about the public post made over the weekend about a new specially crafted WMF image that could potentially cause the application using the Windows Graphics Rendering Engine to crash. As it turns out, these crashes are not exploitable but are instead Windows performance issues that could cause some WMF applications to unexpectedly exit. These issues do not allow an attacker to run code or crash the operating system. They may cause the WMF application to crash, in which case the user may restart the application and resume activity. We had previously identified these issues as part of our ongoing code maintenance and are evaluating them for inclusion in the next service pack for the affected products.
Just to be clear, the security update accompanying MS06-001 did not include fixes for these performance issues. Security updates sometimes do include other fixes, quite often this is a result of the cumulative nature of development, i.e., it may be that those types of fixes get checked in to the code tree and then picked up when a file is serviced in that code branch. However, in order to keep the code churn in security updates to a minimum we try to avoid, as a general rule, including other code fixes for performance issues such as this. It may seem counter-intuitive to not want to improve the code quality whenever opportunity arises, but the fact is that code churn incurred might have a negative impact on the quality of the update or yield a need for even more testing to ensure that we meet the quality bar for security updates. Service Packs or Update Rollups are typically the preferred method of servicing software. If a fix for an issue cannot wait until the next service pack we do consider other forms of servicing. You can read more about the different servicing mechanisms and our terminology for these in this article: http://support.microsoft.com/kb/824684
Kind regards
/Lennart
Hi there. Mike Nash from Microsoft here. For those of you who don’t know me, I am the Corporate Vice President responsible for security at Microsoft. Given the recent events around the Windows Meta File format vulnerability, an ongoing dialogue I have had with some customers and our recent decision to release an update for Windows out of band to correct this vulnerability, I thought I would take a minute to give you a sense of the thought process behind Microsoft’s decision.
As you know, we first heard about this vulnerability and the beginnings of the exploit last Tuesday, December 27. At that point, we immediately started investigating the reports, identified the problem and started working on a security update. At the same time, we started monitoring activities around the exploit to understand the rate of infection and the growing threat level.
There are three things we know for sure:
So back to the WMF issue, actually creating the update was a straight forward process. The challenge was testing the update on all of the supported versions of Windows and the 23 languages we support and making sure that the set of applications that might be effected by this update are not negatively affected by this change.
On Tuesday morning, we announced that our goal was to have an update available as part of our regular update cycle on January 10th. That date was based on our forecast on where we would be with quality.
So what changed to make us decide to release an update today? Two things: The first is that we have an update that we believe in. The team worked very hard to run all of the key scenarios that we are concerned about. While we would always like to have more time, we are confident in the quality of the update. The second issue is that while there is no imminent threat, a number of customers are seeing exploit traffic hitting their AV, IDS and IPS systems. Interestingly, when you talk to the security vendors they are seeing the rate of infection and the rate of spread actually decrease. But, when I spoke to a number of customers and asked if the current situation warranted an out of band release of the update, they said yes, if we had hit our quality goals. I reminded them of their past feedback about out of band updates being an inconvenience and their preference for the monthly release schedule. Overall, they felt that we had made these out of band releases so infrequent, that doing it once when it matters was not a big deal.
So the thing that I know you are all wondering is what should I do? So here is my advice. If you are a consumer or a small business, you should use either Windows Update (or ideally Microsoft Update) to automatically install the update. If you are running Windows XP SP2, you are likely already at least using Windows Update or Automatic Update. If you are an enterprise customer, you should deploy the update as soon as is feasible. Put it through your testing process and get it deployed. With the update available today, you certainly have the choice of deploying now or waiting until your normal release process. If it were my decision, I would move up the schedule. That is what we are doing in our IT operation here at Microsoft.
More information is available here: http://www.microsoft.com/technet/security/bulletin/advance.mspx.
-Mike Nash
Hi everyone, Stephen Toulouse here. There is a lot of activity happening within the MSRC this week so I wanted to make sure that, in addition to the guidance we’ve put out around the WMF vulnerability, that we also let you know that we’ve issued a security advisory regarding recent variants of the Win32/Sober worm. To be clear, these are separate and unrelated issues, however getting guidance out to customers is equally important when customers are faced with any sort of malicious threat.
The antivirus community has been tracking variants of Win32/Sober, a mass mailer worm that attempts to entice users into opening an attached executable or clicking a malicious URL via IM. The worm doesn't appear to target a security vulnerability, but rather relies on the user opening the attachment or clicking a link in their IM window to execute.
On systems already infected by Win32/Sober.Z@mm, the malware is programmed to download and run malicious files from certain Web domains beginning on January 6, 2006. Beginning approximately every two weeks thereafter, the worm is set to begin downloading and running malicious files from additional sites on the same Web domains.
We've added detection for the latest Sober variants to the Malicious Software Removal Tool and the Windows Live Safety Cente and customers who think they might be infected can go to http://safety.live.com and choose "Protection Scan" to remove all known variants of Win32/Sober. The Malicious Software Removal Tool will also be updated as part of the regular, security update release cycle on January 10, 2006 to scan and remove any known infections of Win32/Sober.Z from a users’ computer.
We have issued a security advisory to provide guidance to affected customers to help protect themselves which is available here.
Mike Reavey here from the MSRC- I just wanted to provide another quick update on the WMF vulnerability situation. Microsoft is continuing to work on finalizing a security update for the vulnerability in WMF that is currently being exploited by some malicious attackers. The update has been on an expedited track since Microsoft became aware of the attacks on December 27th. We still anticipate releasing the security fix for this issue on January 10, 2006, once testing for quality and application compatibility is complete.
The expedited track to investigate the vulnerability and develop the security udpate includes redirecting resources from other security development and testing efforts to primarily focus around the clock on producing and releasing the WMF security update.
In our effort to put this security fix on a fast track, a pre-release version of the update was briefly and inadvertently posted on a security community site. There has been some discussion and pointers on subsequent sites to the pre-release code. We recommend that customers disregard the postings and continue keep up-to-date with our latest information on the WMF issue at http://www.microsoft.com/technet/security/advisory/912840.mspx.
-Mike Reavey