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
