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? |
| Steve: Yes. |
| 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. |
| Steve: Right. |
| 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... |
.
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.
http://it.slashdot.org/comments.pl?sid=173878&cid=14466008
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!http://seclists.org/lists/nmap-hackers/2001/Apr-Jun/0010.html
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.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.