Slashdot Mirror
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.
Its happened before and it will happen again. Whether this is the case remains to be seen.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
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....
This Steve Gibson ?, yeah he is a real security expert, along with his podcast boy wonder we have much to be afraid of
The freakish thing about this, is that if it is indeed a backdoor, it an odd way to go about it. You can't force someone to try to view a WMF. What would its purpose be? You can't use it to get into the exact box you want to, just into a random box that perhaps picks up your WMF from a webpage, or displayed in an application.
It's possible to get to the bottom of this by legal means.
The notion of a backdoor in Windows isn't new. Perhaps the WMF vulnerability was one of the vectors used by Magic Lantern, which was the code word for at least one of the FBI's keylogger programs. Magic Lantern was notable in that antivirus providers participated with the Feebs in a gentleman's agreement to not look for it.
It's certainly a dumb enough solution that the IT-challenged FBI might go for it.
On relative dumbness and smartness, I'd expect smart spies, namely those who work for two other notable three-letter-agencies, to use somewhat more interesting techniques. If it were me, I'd take advantage of equipment I had in place at critical infrastructure points to conduct MITM attacks between a PC and Windows Update servers, in order to transparently install my spookware on only those machines that specifically identify themselves - by means of GUID or whatever other stuff I could glean from the Windows Genuine Advantage and other DRM-related bitstreams - as belonging to my target population.
Paranoid? If you're not paranoid, you're not thinking far enough ahead.
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.
Normally I'd agree with you. But in this case I think he may have found something very important. This WMF flap stinks to high heaven. The fact that there seems to be a specific and deliberate key (length == 1) is very disturbing. Gibson is a wacko and doomsayer, but today he may have found something valid.
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!
I found was that, when I deliberately lied about the size of this record and set the size to one and no other value, and I gave this particular byte sequence that makes no sense for a metafile, then Windows created a thread and jumped into my code, began executing my code.
So, it accidently created a new thread, and directed the new thread to start executing code at the specific position? That's a whole different level of accident.
Oh, and Shimmer, I'll take that 5$.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.