The Issue
Most netizens will now be familier with the Windows WMF vulnerability. A rumor, instigated by "security expert" Steve Gibson, via a "This Week in Tech" podcast and on his own web site, had it that this was an intentional back-door created by Microsoft.
Slashdot got hold of the story, resulting in a large number of people now mistakenly believe that the WMF flaw was created with malicious intent.
Nuts & Bolts
Let's look at how the flaw works:
A WMF (Windows Metafile) image can trigger the execution of arbitrary code because the rendering engine, shimgvw.dll, supports the SetAbortProc API.
This API was originally intended as a means to cancel a print task, say when the printer is busy with a very large job, or the queue is very long, or there is a mechanical problem, and so on.
Unfortunately, due to some careless coding, it is possible to cause shimgvw.dll (i.e., the Windows Picture and Fax Viewer) to execute code when SetAbortProc is invoked.
Gibson's reasoning:
A metafile is essentially a script to play back graphical device interface (GDI) calls when a rendering task is initiated.
Gibson could not imagine why WMF rendering should need the SetAbortProc API, since, as he mistakenly believed, WMF outputs to a screen, not a printer.
In fact, it can output to a printer as well. But following Gibson's erroneous assumption, the question arose: what would be the point of polling the process and allowing the user, or application, to cancel it?
Having exhausted his imagination on that score, he concluded that there's no good reason for SetAbortProc to be involved in handling metafiles. The more logical explanation, Gibson reckoned, was that someone at Microsoft had deliberately back-doored Windows with this peculiar little stuff-up.
Nothing new here
To anyone well acquainted Microsoft's insistence on ease of use whatever the security cost, the idea of intentional mischief along these lines is immediately suspect.
Microsoft has made a pudding of security from its earliest days, and no amount of malicious intent can possibly account for this. The company's obsession with ease of use is more than adequate to account for this and thousands of other security snafus like it.
Most netizens will now be familier with the Windows WMF vulnerability. A rumor, instigated by "security expert" Steve Gibson, via a "This Week in Tech" podcast and on his own web site, had it that this was an intentional back-door created by Microsoft.
Slashdot got hold of the story, resulting in a large number of people now mistakenly believe that the WMF flaw was created with malicious intent.
Nuts & Bolts
Let's look at how the flaw works:
A WMF (Windows Metafile) image can trigger the execution of arbitrary code because the rendering engine, shimgvw.dll, supports the SetAbortProc API.
This API was originally intended as a means to cancel a print task, say when the printer is busy with a very large job, or the queue is very long, or there is a mechanical problem, and so on.
Unfortunately, due to some careless coding, it is possible to cause shimgvw.dll (i.e., the Windows Picture and Fax Viewer) to execute code when SetAbortProc is invoked.
Gibson's reasoning:
A metafile is essentially a script to play back graphical device interface (GDI) calls when a rendering task is initiated.
Gibson could not imagine why WMF rendering should need the SetAbortProc API, since, as he mistakenly believed, WMF outputs to a screen, not a printer.
In fact, it can output to a printer as well. But following Gibson's erroneous assumption, the question arose: what would be the point of polling the process and allowing the user, or application, to cancel it?
Having exhausted his imagination on that score, he concluded that there's no good reason for SetAbortProc to be involved in handling metafiles. The more logical explanation, Gibson reckoned, was that someone at Microsoft had deliberately back-doored Windows with this peculiar little stuff-up.
Nothing new here
To anyone well acquainted Microsoft's insistence on ease of use whatever the security cost, the idea of intentional mischief along these lines is immediately suspect.
Microsoft has made a pudding of security from its earliest days, and no amount of malicious intent can possibly account for this. The company's obsession with ease of use is more than adequate to account for this and thousands of other security snafus like it.