Onderwerp: WMF vulnerability was a deliberate backdoor?

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]=20
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=3D....feedback&ite=
m=3D60006

thoughts?


Shane



__________________________________________________ _______

The information contained in this message is privileged, confidential =
and=20
intended only for use of the individual or entity addressed above. If =
you=20
have received this communication in error, please immediately notify us
by reply and delete the same. Thank you.=20

Microsoft response

http://blogs.technet.com/msrc/archiv...13/417431.aspx




-----Original Message-----
From: Brooks, Shane [mailto:SBrooks@orangelake.com]=20
Sent: Friday, January 13, 2006 2:31 PM
To: bugtraq@securityfocus.com
Subject: WMF vulnerability was a deliberate backdoor?


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]=20
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=3D....feedback&ite=
m=3D6
0006

thoughts?


Shane



__________________________________________________ _______

The information contained in this message is privileged, confidential
and=20
intended only for use of the individual or entity addressed above. If
you=20
have received this communication in error, please immediately notify us
by reply and delete the same. Thank you.=20

Brooks, Shane wrote:
> <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>
> [...]
> thoughts?

Nonsense. Even putting my humble opinion about Gibsons "work" aside,
assuming that especially Microsoft, while constantly being under close
public observation, would ever think of creating a backdoor at all and
even putting it somewhere everyone can find and use it, is absolutely
absurd.

Denis Jedig
syneticon netwoks GbR

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=ar...ack&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/de...tspol_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@unixwiz.net

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=ar...ack&item=60006
>
> thoughts?
>

Shane,

What you read was classic Gibson: a thorough discussion of a technical
problem, followed by a wild speculative jump regarding the motives of
the people who wrote the code. He's been doing this for years, which is
why you may notice folks here take a very jaded view of anything he says
- ever.

In the specific case of his commentary on the WMV vulnerability, I have
read the same writeup you have read, and what my read on it was that he
was saying something like the following:
"There's an unhandled exception that doesn't even need to be there in
the first place, therefore it's a deliberate backdoor."
To me, this just screams "Does Not Follow!" I've seen plenty of equally
stupid mistakes coming from Redmond (and elsewhere) that didn't happen
to result in remote code execution, but were nonetheless astonishingly
dumb. For example, up until a couple days ago, you could make the error
handler at ideas.live.com write all sorts of amusing stuff to their 404
page simply by appending it to the URL. Was it a security risk?
Possibly, probably not. Was it really dumb? Duh.

So my take on Gibson's post can be summed up as follows: Interesting
writeup on the problem, but he's come nowhere close to proving to me
that the WMF vulnerability was deliberate. If he wanted to show me the
sourcecode where it has a comment like "/* The following code is here at
the behest of No Such Agency. Do not remove from future versions. */" I
might start to consider the possibility of some dark conspiricy. As it
stands, it just looks to me like Yet Another Dumb Screwup by Microsoft
(YADSM).

Cheers,
Mike Ely

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=ar...ack&item=60006
>
> thoughts?

www.GRCsucks.com

That is the most comprehensive answer you would ever need.

IMO, GRC deserves respect for trying to do good, as well as raising
awareness. Other than that he usually is:
1. Ill informed.
2. Informed of things that happened 3 years ago.
3. Does "disinformation campaigns" on us whenever he is wrong, which is
often (quote taken from him).
4. LOVES TO TALK TO THE MEDIA.

In other words, he is often wrong -- bases little on fact, and does it
in the media.

Gadi.