I really don't get why folks like to bash Gibson. I've been reading
this stuff for many years now. He's a good guy as far as I can see.
He's also entertaining from a technical POV. Moreover, he doesn't seem
to be a MS "yes man," either. And when he points out stuff like this,
which no one will ever be able to lay solid claim/blame for, at least
there is some meaningful basis to his comments. As far as I can tell,
he's definitely not "nutty" or and certinly not full of shit. Perhaps
he's a bit like the boy who cries wolf, because he comes up with stuff
that is potentially a big deal...but ends up not being so because of his
efforts. Perhaps he should be elevated to some kind of PC sainthood. :)
Brian Weeden wrote:
Okay this is from the SysInternals writeup (very good btw, thanks for
the link). Here is what Gibson based his conclusions on:
1. There is no need for WMF files to include support for the SetAbortProc API.
2. Even if an abort procedure is set by a WMF file, Windows shouldn't
execute it unless some abort condition is triggered, which should
never occur when executing a WMF file.
3. He could only get his WMF file's abort procedure to execute when he
specified certain invalid values for the size of the record containing
the SetAbortProc command.
4. Windows executes code embedded within the SetAbortProc record
rather than expect the record to reference a procedure within the
application executing the WMF file.
Given that same sort of evidence I would have concluded the same exact
thing. And I hope many of the other security professionals would have
as well. SysInternals goes on to explain why some of Gibson's
reasoning was incorrect, and I can see where he made his mistakes.
But then there is this comment that follows the blog (one of many good ones):
"While I applaud your efforts to explain the *details* of this
vulnerability (and nicely done too) and why it may have been allowed
to exist, there's one point Gibson brought up you didn't cover: Why,
if as you claim that this was seen as a 'feature' in days so long ago
(Win 3.x) that code inside a .wmf file could rely upon 'hard-coded
addresses when patches didn't exist,' did Microsoft make sure
embedded-code-execution couldn't happen under Windows 9x (in fact
adding extra code to keep it from ever doing so!) yet still allow it
(or more correctly added it to?) their Windows NT series? Therefore,
it seems at least one person in the 'NT development' dept. (who could
have checked how Windows 9x handled .WMF files) chose to allow for
arbitrary code execution instead. It's not a coding error: The
'mistake' was for Microsoft during many code reviews to allow it to
continue that way in Win 2000, XP and beyond until an exploit finally
made use of it!"
And this one:
"Mark, I don't claim to be the expert that either you or Steve Gibson
are. I am fans of both and have been for many years. But there is one
flaw in your argument that even I can spot. You stated, about the
ability to run code inline with the SetAbortProc: The actual reason
is lost with the original developer of the API, but my guess is that
he or she was being as flexible as possible. That defines a back
door. Code put in place by a developer that is not documented in the
requirements or specifications! This may not be a back door
intentionally placed by Microsoft, but it smells awfully much like a
backdoor put in intentionally by someone at Microsoft."
I completely agree. Gibson and the guy and SysInternals came up with
the exact same results. One concluded that it was a "backdoor", the
other concluded that it was bad code written for an unkown reason,
which could be exploited as a backdoor.
IMHO, everyone who looks at this function and code knows what it is.
Gibson is the only "security expert" with the balls to call it what
everyone is thinking - a backdoor. And it's because you cannot prove
it one way or the other. Everyone else doesn't want to risk the wrath
of M$ unless they have proof. And even the term "backdoor" can be
used differently. It's like the differnence betwen "hacker" and
"cracker". To us geeks there is a subtle but real difference between
those camps. To the non-geek world they are exactly the same. I
think the same semantics is at play here between the words "badly
coded feature" and "backdoor".
The other thing I can't understand is why there seems to be a very
vocal number of poeple out there who seem to use every single
opportunity to bash and flame and destroy Gibson. I've been through
all his stuff and I think the worst he can be accused of is sometimes
going overboard on the ramifications of some of the problems he has
found.
--
Brian
