Skip to comments.The Windows MetaFile Backdoor?
Posted on 01/16/2006 9:48:37 AM PST by ShadowAce
This is a transcript from a show Steve Gibson did with Leo LaPorte. The link to the audio is at the above link. Also, I will excerpt a little of the relevant information here.
Steve: And so, you know, because I'm a developer when I'm not being a hacker, I wanted to understand - oh, and the other thing is, I want to write a robust testing application, you know, that always works all the time. So I wanted to know, like, okay, what bytes have to be set which way, what matters, what doesn't. Because, you know, that's the way you get something that is as solid as, you know, the code that I put out from GRC. So what 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. Okay, Leo? This was not a mistake. This is not buggy code. This was put into Windows by someone. We are never going to know who. We're never going to know - well, actually I'm going to find out when because we're going to know when this appeared because this appeared - I'm guessing this is not in older versions of Windows, which is why this function - or if it is in older versions of Windows, it's done slightly differently. I'm still on the hunt.
So this is not my last report on this. I expect to have a much better sense for this a week from now. But the only conclusion I can draw is that there has been code from at least Windows 2000 on, and in all current versions, and even, you know, future versions, until it was discovered, which was deliberately put in there by some group, we don't know at what level or how large in Microsoft, that gave them the ability that they who knew how to get their Windows systems to silently and secretly run code contained in an image, those people would be able to do that on remotely located Windows machines...
|Leo: So you're saying intentionally or - Microsoft intentionally put a backdoor in Windows? Is that what you're saying?|
|Leo: Well, that's a pretty strong accusation. Could this not have been a...|
|Steve: Well, it's the only conclusion...|
|Leo: It couldn't have been a mistake?|
|Steve: I don't see how it could have been a mistake. Again, I'm going to continue to look at it. But from what I've seen now, this had to be deliberate. It was not what we were led to believe. Well, and it's funny, too, because then I thought, okay, wait a minute, Microsoft has lied to us. I reread the original vulnerability spec in, you know, their vulnerability page. And they never say this isn't the case. I mean, they describe it as a vulnerability, which it certainly is. Nowhere, you know, is even what I'm saying contradicted by their page.|
|Leo: So you're saying Microsoft, or people at Microsoft maybe unbeknownst to Microsoft, intentionally put code in Microsoft Windows that will allow anybody who knew about it access any Windows machine, to get into any Windows machine and run any arbitrary code on it.|
|Steve: Well, it's not like a trojan, where they would be able to contact a remote machine. But, for example, if Microsoft was worried that for some reason in the future they might have cause to get visitors to their website to execute code, even if ActiveX is turned off, even if security is up full, even if firewalls are on, basically if Microsoft wanted a short circuit, a means to get code run in a Windows machine by visiting their website, they have had that ability, and this code gave it to them.|
|Leo: And there'd be nothing anybody could do about it or - and in most cases detect it. So it sounds like - and I really want to be careful here because this is a very serious accusation. It sounds like this was done on purpose by Microsoft or somebody at Microsoft. It sounds like it was accidentally discovered. Microsoft reacted and has pulled it out now.|
|Leo: Could there be other backdoors like this?|
|Steve: Well, yes. I mean, that's the problem with a closed source operating system like...|
|Leo: I have to say, before we go any further, you're not an open source advocate. You're not a Macintosh advocate. You've been a Windows user. And frankly, you're my staunchest friend who's a Windows advocate. I mean, so this is not some plan on your part to discredit Microsoft.|
|Steve: Well, no. And in fact I'm sure, I mean, I'm hoping that we're going to see corroboration from other people who didn't think about or didn't look closely at this. I mean, frankly, if last week Microsoft had patched the older versions of Windows, I would have had no cause to look closely to understand how this exploit worked that was discovered. I believe that some very clever and industrious hacker figured this out, started using it, and Microsoft was caught off guard and thought, whoops, we've got to close this backdoor down. Now, you know, to say that Microsoft did this, I mean, on one level it's clearly true. But we don't know who knows about this in Microsoft.|
|Leo: It could have been a renegade programmer working for Windows who just thought he'd throw this in for fun.|
|Steve: Yes. I mean...|
|Leo: Let me ask you one more time, though...|
|Steve: But that's dangerous, too.|
|Leo: Well, of course. But let me ask you one more - you're convinced there's no way this could have happened by accident. It can't be a programming error or bad design.|
|Steve: No. No. I mean, you know, again, this is as much a surprise to me, Leo, as it is to, you know, anyone who hears this. I did not expect to see this. I expected to find, for example, that the way this exploit worked was that the SETABORTPROC was working correctly, and that I would give it a pointer to my own code a few bytes lower, then I would do something to force the metafile to abort, and then the metafile processing would use the pointer, the legitimate SETABORTPROC pointer, and then basically run the code that was located right there in the metafile. That's what I thought I was going to encounter, something that sort of made sense, like we were originally led to believe. Or actually I think, you know, Microsoft didn't say anything at all. So we just all kind of presumed this was another one of those coding errors that Microsoft now famously makes and corrects on the second Tuesday of every month. This wasn't a programming error. And, you know, so it's like, whoa. When I give it the magic key on the size of the metafile record, then it jumps directly into my code.
Now, again, I will know more in a week. I have to say that, you know, I want to call this preliminary. But I don't see any way that this was not something that someone in Microsoft deliberately put into Windows. And, you know, the other thing, too...
|Leo: Could this have been at the request of a government agency, let's say? I guess not because, as you point out, it's not a trojan horse. You have to go to a site. You have to go to the site of somebody who knows about this exploit to be taken advantage of. And in fact, the scenario you describe is really the only scenario I can think of, Microsoft doing it so that, if worst case happened, they would be able to update a machine. They'd be able to say, go to the Microsoft site and we'll fix you or something. I mean, the NSA wouldn't put this in because they couldn't guarantee access to any computer.|
|Steve: I've looked back over all the documentation. I can't find anything about this documented anywhere. Okay, then I said - I played my own devil's advocate. Okay, so code is running in the metafile. Wouldn't that be useful? Wouldn't it be useful if a metafile could contain executable code, sort of as an undocumented feature? Microsoft never got around to writing about it; but they said, oh, this would be cool, and we'll use the SETABORTPROC. Notice that SETABORTPROC, it was just, I mean, this has nothing to do with printer aborting. It was just sort of a - it was a value that they had handy from other processing, and they sort of reused it. But this has got nothing to do with aborting printing. So it almost helped with the obfuscation and sort of, you know, the plausible deniability, except that this wasn't a coding mistake. And, you know, you even had to put the magic key into the length of the record in order to get this to work. And that was protection from somebody's metafile having a SETABORTPROC metafile record in it and tripping over this backdoor by mistake.|
|Leo: This is exactly what you would do, if you were going to write a backdoor, this is exactly how you would do it.|
|Steve: Yeah. Yeah. So I asked myself, isn't there, like, a constructive purpose for putting code in a metafile? And the problem is, code running in the metafile doesn't have access to the context of the metafile. It doesn't know what to do with it. It's, you know, it's powerless to use the objects that Windows is using. And there seems to be no way to get back to Microsoft's code from this. Again, I've got some more work to do, and then the timing of this Security Now! podcast coincided with, you know, I've known this for a day now. And I've been going back over it and trying to come up with a reason, I mean, a benign reason for this. And I just don't see it.|
|Leo: I suppose we should contact Microsoft and ask them what they think about this. But I doubt that we'd get a straight answer.|
|Steve: I've tried doing that before on other issues like this, Leo. And, you know, it's not useful. So...|
This goes along with intel putting serial numbers in chips that can be remotely read, so your machine can be positively identified. Plus the anti trust suit against microsoft went away rather mysteriously because the feds (clinton) got them to put in this software backdoor as part of the settlement.
In the mid ninties The Clintons were putting pressure on Gates to allow a back-door in their soft-ware obstensibly to allow domestic tracking of computer systems used by criminals as a way of updating federal wiretap rules. The FBI's carnivore system came out of this as well. Gates was refusing to do it, the Clinton administration threatened sanctions(what do you think that lawsuit was really about?), and all of a sudden when Microsoft loses its case, it gets a slap on the wrist then nothing further about "back-doors" in the news.
So tin-foil hat time...or what?
Sounds like a buffer overflow hack.
The bloggosphere is all over this, for example Groklaw:
"Steve Gibson: MS WMF is a Backdoor, Not a Coding Mistake - Updated"
Steve may be over-dramatizing this, but Mr.Bill has a lot
to answer for here.
And security advocates will now be digging even harder
to see what else MS "overlooked" in their "security sweeps"
of the Windows codebase.
IMHO, Gates made windows leak like a seive to benefit business....who has always wanted to know how and for what each one of use really uses a computer.......
When they originally proposed this, there were several AV publishers, such as Frisk, who refused to play along.
It now appears that the FBI went straight to the source, as it were.
By John Leyden
Published Tuesday 27th November 2001 18:44 GMT
Antivirus vendors are at loggerheads over whether they should include in their software packages detection for a Trojan horse program reportedly under development by the FBI.
A keystroke logging Trojan, called Magic Lantern, will enable investigators to discover break PGP encoded messages sent by suspects under investigation, MSNBC reports. By logging what a suspect types, and transmitting this back to investigators, the FBI could use Magic Lantern to work out a suspect's passphrase. Getting a target's private PGP keyring is easy in comparison, and with the two any message can be broken.
MSNBC quotes unnamed sources who says that Magic Lantern could be sent to a target by email or planted on a suspect's PC by exploiting common operating system vulnerabilities.
Although unconfirmed, the reports are been taken seriously in the security community, and are consistent with the admitted use of key-logging software in the investigation of suspected mobster Nicodemo Scarfo. In that case, FBI agents obtained a warrant to enter Scarfo's office and install keystroke logging software on his machine.
Magic Lantern, which would be an extension of the Carnivore Internet surveillance program, takes the idea one step further by enabling agents to place a Trojan on a target's computer without having to gain physical access.
The suggested technique creates a clutch of legal, ethical and technical issues. Greater powers in the Patriot Act, which Congress is considering, may allow the tool to be used. But what if it was modified for use by hackers?
And antivirus vendors are mulling over the rights and wrongs of putting Magic Lantern on their virus definition list.
Eric Chien, chief researcher at Symantec's antivirus research lab, said that provided a hypothetical keystroke logging tool was used only by the FBI, then Symantec would avoid updating its antivirus tools to detect such a Trojan.
Symantec is yet to hear back from the FBI on its enquiries about Magic Lantern.
"If it was under the control of the FBI, with appropriate technical safeguards in place to prevent possible misuse, and nobody else used it - we wouldn't detect it," said Chien. "However we would detect modified versions that might be used by hackers."
Graham Cluley, senior technology consultant at Sophos, disagrees. He says it it wrong to deliberately refrain from detecting the virus, because its customers outside the US would expect protection against the Trojan. Such a move also creates an awkward precedent.
Cluley adds: "What if the French intelligence service, or even the Greeks, created a Trojan horse program for this purpose? Should we ignore those too?"
If, and thats a big *if* there is any meat to this accusation it had to be a lone programmer, no way is MS that stupid or evil..
you guys are all wrong. It's Bush's fault.
> Groklaw links to these, for example:
And the grc site is not responding.
This is likely the slashdot effect (server overload
due to interest), but could also be a DDoS attack on
grc, which has happened before.
> And the grc site is not responding.
This link is working:
Contains links to Steve's latest comments.
I don't know about that. Doesn't Microsoft do code reviews of stuff they put in windows? If this is a backdoor, you can bet it was instigated by FedGov.
does anyone know if a similar backdoor exists in/on Mac OS X?
Gibbie is his own hype machine, ergo he never backs down from anything he says, no matter how ridiculous it ends up being.
This "backdoor" thing is just a buncha bull from a guy who really doesn't know anything about computer security. Gibson is a hack, and not in a good sense either.
> does anyone know if a similar backdoor exists in/on Mac OS X?
Well, that's the thing about closed-source proprietary
operating systems. Who knows?
And if this WMF hook was a Clinton-era-inspired feature,
we can assume that MacOS and most Unix variants have
Linux wouldn't though.
Perhaps but even then it is not something MS wanted to do. ANd code reviews do not always catch back doors..
"I don't know about that. Doesn't Microsoft do code reviews of stuff they put in windows?"
I agree. The Lee Harvey Oswald theory of a lone renegade programming doesn't fly at all. You don't check out code for modification that isn't reviewed and tested to the max in an organization as large as Microsoft. I'm not saying it's a bug and therefore not intentionally done, but it took more than one person to pull this off if it is intentional.
So make sure your next computer has a 64 bit processor and your motherboard has built-in protection against data segment execution.
The latest crop of Supermicro motherboard have this. Both AMD and Intel have suitable chips.
Indeed. One would think having a executible jump in a media file would be a flag thrown up. This is especially true IMO if the jump can only be triggered by a malformed request. If they try to claim the jump was included to conform to some specification, why not have the trigger execute a NOP instead of untrusted (and unknowable) code?
Read the whole thing, it sounds like a command. What's the last buffer overflow you saw where the system purposely spawned your injected code as another thread?
It's not. Gibbie is, as usual, full of it. Here's one commenter who notes that Gibson's assertion that the exploit can only be triggered with a record length of 1 (so therefore it *must* be intentional!!1!1!11) is complete BS.
I hate to be the party-pooper, but Gibson is next to worthless as a source for anything related to computer security.
Sure, he's a one man hype machine. But he also knows his low level Windows/Intel code. His explanations on this one are compelling. Having the code that inteprets WMF files do a subroutine jump directly into a metafile is clear evidence of blatant and intentional hackery. And Steve is entirely qualified to report on that matter. I've used and watched Steve's work for a decade. He is the most reliable reporter I know on such specifics.
And yes, he can be a bit of an arrogant butt head at times as well <grin>.
He is now tearing apart the code, instruction by instruction.
Likely, the record length of one detail was wrong.
What he gets from reading the actual machine instructions will be rock solid - that's how Steve works.
What he has already, the CALL EAX into the metafile (which is supposed to contain image data, not machine instructions), is seriously compelling.
Please quit slandering Gibson. I don't know your agenda here, sir, but something stinks about your postings.
Never attribute to malice that which can be adequately explained by stupidity.
very funny ...
No. Listen to him at your own risk, or take the word of folks who really know TCP/IP and systems security, e.g. the fellow who wrote nmap:
Gibson is a charlatan whose "research" is written for clueless media reporters (for press attention) and the teeming masses of internet newbies (to whom he sells various products). His "findings" are not new, are always filled with massive hyperbole, and are frequently completely false. Instead of presenting evidence to prove his points, he tends to just state them using goofy blue or green fonts as if that somehow adds credibility. We recommend avoiding this guy!
Sorry, but the only thing that keeps Gibbie from being an out-and-out scam artist is that he doesn't have a clue what he's talking about. Nothing personal against you, but he's absolutely worthless. You'd do better with Security Focus/Bugtraq or by spending some time at DEFCON with some real experts.
Exactly. The design was broken in the first place. You don't need anything more tinfoilish than that to understand what happened here.
My "agenda"? I should think it's fairly obvious - Steve Gibson is a fraud when it comes to computer security. And lest you think this is somehow pro-Microsoft shilling, I note with some interest that he has taken up his ridiculous "raw sockets" campaign against Linux now. The difference being that most Linux users, being somewhat more savvy than the average Windows user, will immediately recognize that the whole thing is garbage, right from the get-go. Sorry.
Just curious. What can you do against a 20,000 strong zombie DOS attack?
Gibson earned my respect with his tools since his tool to help with the infamous Zip drive "click of death." He was also one of the first people to push personal firewalls at a time when no one had ever heard of them. I have to give him the benefit of the doubt on this, but temper it with his known propensity for hype.
Obviously, if you're Steve Gibson, you rather inanely blame the whole thing on raw sockets.
That doesn't translate into any sort of expertise on network security, though. And when it comes to network security, he's pretty conclusively demonstrated that he's clueless. The guy somehow managed to take on the problem of SYN floods without managing to learn anything about the extant solutions - i.e., SYNcookies - and thereby managed to craft a totally inferior solution of his own. "Nanoprobes" are, as nearly as anyone can tell, a half-baked reinvention of nmap, and so forth. Whatever he knows/knew about disk drives, it doesn't carry over to security, unfortunately.
More seriously, if you're that important, you temporarily replicate your server and your internet connection elsewhere. It's expensive, but that's your first step - increase the amount of firepower needed to bring you down.
When he finds a certain instruction sequence, I trust his finding.
I conclude from that what I will about Microsoft's involvement and motivation in that code. Gibson is a muck raker, a yellow journalist. But he knows his code.
I buy his products, because they are tightly and accurately coded. I trust his specific technical findings, but not the conclusions he draws from them.
For example, he reported last week that he could only trigger that WMF exploit with a size of one. I believe that, in the most narrow sense, this was a true statement. His conclusions from that black box testing were unwarranted. Even now, he is, I presume, finding other ways to trigger this exploit.
Anyone can be DOS'd, even the biggies like Yahoo or Microsoft. That Steve has been hit means nothing except that he is an inviting target.
"Yes it would be much safer for peasants like us to allow Government to rule supreme in an "open" environment. The government would never be interested in what we do with our computers either".... wait until the Feds provide nationwide "free" highspeed wireless..through their servers...and Google is your online operating system!!
I knew it...their all worms.
But it's obviously not true. I mean, his whole case, that it's deliberate, is built on the belief that you can only trigger bad things with this one "impossible" magic value. Except that this belief is *false* - there are many values that can trigger it. Hence, his conclusion is predicated on an obviously false premise.
Currently, I hold the following:
Yet Another Buffer Overflow Bug.
A buffer overflow bug overwrites executable code or call stack saved registers, that will be executed or restored innocently at a later time.
This flaw seems to have an added, intentional, CALL instruction, into metadata in a file that should not have any executable instructions.
Very different. No flawed buffer arithmetic. Not the faking out of a legitimate call or jump with bad data, but the intentional call into a place that no one would have expect to have machine instructions.
Except that Gibbie has noted the behavior, but not anything like "deliberate placement" of an instruction to do so. In fact, all he's theorizing is that, because it only exhibits this behavior given the magic cookie, it must be deliberate. But what we now know is that it exhibits that behavior on a wide range of metafiles, including correctly formed metafiles.
I hate to break it to Steve, but applications and operating systems misbehaving and treating data as code is not exactly a new phenomenon - it's the basis of every buffer overflow exploit that's ever been implemented, among other things. But really, nevermind that - this is code that's essentially been ported over from Windows 3.0, dating back to a long-gone time when metafiles were implicitly trusted by the OS. Essentially, it was an intentional design decision to allow GDI functions to be called by metafiles.
Bad design? Sure. Bad implementation? Absolutely. Intentional backdoor? Not so far, not by a long shot.
Using Microsoft-provided tools, and the Microsoft sanctioned technique of stepping through a Windows client's code, and continuing into the operating system -- which Microsoft further sanctions by providing "debugging symbols" to help programmers locate and recognize Windows' internal APIs, functions, and subroutines ...
I found the location in Windows, located just in front of the "PlayMetaFile" function's call to "PlayMetaFileRecord", where Windows very clearly and deliberately jumps to the metafile code itself.
Windows first pushes two, as yet unidentified, dword parameters onto the stack, then performs a "CALL EAX", where the EAX register contains the address of the metafile's byte immediately following the Escape/SetAbortProc subfunction.
Upon return from the metafile-resident function, the EAX register is tested for "zeroness". This is typically the way subroutine functions return their success or failure status to the function's caller.
If the metafile-resident function returns "TRUE" (EAX <> 0) a bit more work is performed and the PlayMetaFileRecord function is called again.
I have a great deal more analysis to do before I'll have any sort of handle on exactly what conditions are required to cause this clearly deliberate "subroutine call" into a Windows Metafile. For example, how was the subroutine's location (EAX) value calculated, etc. But this is exactly the sort of thing I was expecting to find once I went looking.
Somebody intended this as a feature of Windows NT4 and all later WMF processing. This system appears to have been deliberately designed to support the direct execution of arbitrary code contained within Windows metafiles.