Re: WMF vulnerability was a deliberate backdoor?
On Fri, Jan 13, 2006 at 02:31:16PM -0500, Brooks, Shane wrote:
> I've recently had my attention brought to a post from Steve Gibson in the
> grc.com forums, which contains the following quote:
>
> <snippet>
> The only conclusion that can reasonably be drawn is that this
> [setAbortProc procedure]
> was a deliberate backdoor put into all of Microsoft's recent editions of
> Windows.
> </snippet>
>
> full article here:
> http://www.grc.com/x/news.exe?cmd=article&group=grc.news.feedback&item=60006
>
> thoughts?
This debate has been raging in many forums for a coupla days, including the
Security forum at DSLReports:
http://www.dslreports.com/forum/remark,15234283
Most of the experienced software development/security people I talk to
are chalking this up to Steve Gibson's penchant for hyperbole, and to
a surplus of tinfoil.
Steve clearly understands the low-level technical aspects of how the
SETABORTPROC escape works (which is related to but different from
the SetAbortProc API call), but he's ascribing motives which are
conspiratorial and downright silly.
I think it's much more easily explained by overlooking an attack vector
to problematic but scary-to-change functionality.
This ABORTPROC issues has been in Windows for many, many years (I think I
read 1990 somehere), so it's clearly in the category of crufty code. The
notion of having an abort procedure was much more important in the old
Win3.1 days because the operating system wasn't preemptive: this hook gave
an application the ability to interrupt some long-running GDI operation.
It's not really needed any more, and though I think that PlayMetaFile()
can be used to play a program-generated stream, it should never have
allowed SETABORTPROC when the stream is backed solely by a *file* stream
from outside the program.
Whether this is a good idea or not, it's part of a published API to the
operating system, and Microsoft is reasonably reticent to change that
API without a really good reason. It's easy to predict that changing
the API will break things, and there are scattered reports of printing
issues with third-party drivers and/or applications.
It may be that these drivers/apps are broken, but they're part of the
customer base, and you don't break them unless you have to. You only
have to if the problem is a critical one.
Clearly this was critical when looked at in retrospect, but it's not the
narrow issue of whether the particular functionality was bad or not. I
think it smelled troublesome, but absent an attack vector, it could
be left alone. This tells me that beyond the original design issue,
the mistake was to overlook the attack vector.
The fun of late December answered that question for good, but the fact
that this had been dormant in Windows for *so long* without surfacing
in public suggests that it's not any kind of trivial matter to realize
its full potential.
In order to believe that this is a deliberate back door, you'd have
to believe a conspiracy which I think is beyond Microsoft's ability to
pull off. It's not some buffer overflow which requires a disassembler,
but part of a *documented API* which is available to anybody:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_0d6b.asp
The number of people whose job it is to find security issues in their
products is substantial, and I'd love to have been in the room when they
raised this issue and were told "Shhhh. That's one we're leaving in".
Steve, who wears no tinfoil
---
Stephen J Friedl | Security Consultant | UNIX Wizard | +1 714 544-6561
www.unixwiz.net | Tustin, Calif. USA | Microsoft MVP | steve@xxxxxxxxxxx