[IP] more on MS responds --more on Steve Gibson: MS WMF is a Backdoor, Not a Coding Mistake
Begin forwarded message:
From: Matt Manor <kingmanor@xxxxxxxxx>
Date: January 14, 2006 4:32:01 AM EST
To: dave@xxxxxxxxxx
Subject: Re: [IP] more on Steve Gibson: MS WMF is a Backdoor, Not a
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 roessler@xxxxxxxxxxxxxxxxxx
To manage your subscription, go to
http://v2.listbox.com/member/?listname=ip
Archives at: http://www.interesting-people.org/archives/interesting-people/