Coding Mistake Microsoft Responds... http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx Looking at the WMF issue, how did it get there? 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! S. *This posting is provided "AS IS" with no warranties, and confers no rights.* posted on Friday, January 13, 2006 11:57 PM by stepto ------------------------------------- You are subscribed as eugen@leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]