WMF Vulnerability is an Intentional Backdoor?
An anonymous reader writes "Steve Gibson alleges that the WMF vulnerability in Windows was neither a bug, nor a feature designed without security in mind, but was actually an intentionally placed backdoor. In a more detailed explanation, Gibson explains that the way SetAbortProc works in metafiles does not bear even the slightest resemblance to the way it works when used by a program while printing. Based on the information presented, it really does look like an intentional backdoor." There's a transcript available of the 'Security Now!' podcast where Gibson discusses this.
There was talk about the NSA/CIA having a close relationship with Microsoft and being able to exploit backdoors in Windows. This could have all been conspiracy theories, but the fact that this vulnerability existed throughout the Windows line kinda seems odd..
If this isn't a glaring example on why you should support open source, I don't know what is....
It's possible to get to the bottom of this by legal means.
Agreed, it doesn't seem like the kind of "feature" that was designed in top-secret MS design documents or developed in meetings.
But I still have a hard time seeing how code would *accidentally* behave like this. An invalid length should abort processing right off the bad, for one thing; "falling through" might be an explanation, but what possible code could be "fallen through" into that would set CPU execution *inside* the metafile -- moreover, would set CPU execution to the *next byte* after the erroneous header block. That's awfully convenient; if it were a mistake, I'd expect code execution to begin at some other random location, probably influenced by whatever happened to be in the register or some temporary pointer variable at the time. But the very next byte? That's too insanely convenient -- you get to provide your key *and* your payload in the *same* place.
You could argue that buffer overrun exploits do the same thing, but the idea of the buffer overflow is to specifically overwrite the function-return pointer to *make* it point at your code. In this case, the exploit doesn't have to specify the location of the code to execute, Windows does that for you. Too convenient.
My question is this... If the guy is smart enough to know that windows has kicked off a thread and executed his code, and he's smart enough to experiment with buffer-overflow exploits, why hasn't he stepped through the WMF interpreter code? Could it be that he doesn't want to admit that he has for legal reasons? I know that if I had discovered this problem, that's just what I would do. Call DebugBreak() and you have a call stack. You'd think that the handler for this SetAbortProc function would be pretty identifiable. So... Who's got the balls (or the time, in my case) to do it? That's our answer. Chris.
Code encounters escape character
exit standard processing
encounter SetAbortProc
open thread to communicate with windows print manager
thread attempts to read [length] bytes for sub value, encounters overrun
this is where I'm guessing the real horrendous problem lies. I'm guessing that the original code ignores exceptions while pulling in the sub value, so in this case where code hits an overrun, instead of that sub value getting a few bytes of data, it just graps until . In this case that sub value winds up being the payload.
So there you go, key and payload on an independent thread because of a bad exception handler in a 12 year old block of code.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
The 98 series and NT4 are still in widespread (millions and millions) use. This is called a "problem" then. The auto industry in the US tried to pull this stunt of obsoleting and stopping support for their products in short time frames (sometimes within the SAME model year!) and got legally smacked down for it. Now they are required to provide replacement parts for ten years. Just because normal business productlaws and warranties aren't applied to software-yet, and they certainly should be-doesn't mean it wouldn't be a good idea. Planned obsolesence and forced upgrades might be a spiffy way for some corps to extract a lot more dineros from your wallet, but it doesn't mean it's a good idea for you the consumer/end user...unless you are a pure "caveat emptor" anything-goes styled capitalist. Thankfully, most people see the illogic in that sort of system and that is why we have evolved some consumer protection laws. It is not a perfect solution, but it is light years ahead of legalised snakeoil like it was before. Eventually these sorts of laws will be applied to software,because even the dullest clicker is starting to bingo to the fact that most of this forced upgrade stuff is a cash cow dodge.
I'm surprised nobody's trotted out Reflections on Trusting Trust, by Ken Thompson. Not only does this discuss a backdoor, but also a backdoor that can't be found by examining the source code.
Program Intellivision!