WMF Vulnerability is an Intentional Backdoor? 788
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.
Length==1 (Score:5, Insightful)
Anyone remember NSA KEY in the registry? (Score:1, Insightful)
Re:And this door leads to... (Score:5, Insightful)
Interesting evidence (Score:4, Insightful)
It's a straightforward way to add a backdoor that will bypass firewalls, etc. It can be triggered by a browsed page, email, etc. It's better than gif/jpeg encoding because those are more "platform independent." and the payload would be more likely noticed by a 3rd party decoder.
On the other hand, isn't this flagged as an attempt to execute code on a data page?
Also, if it were official, doesn't MS have easier ways into a general box - say through security updates, or even the entire existing code base?
Re:Length==1 (Score:4, Insightful)
Re:Length==1 (Score:5, Insightful)
I can see this being a programmer supplied backdoor, like a hook for easter eggs, but based on the other security work done in MS, anything that can be gotten into that is there on purpose is locked up pretty tight to any casual attempts.
You're on (Score:3, Insightful)
Re:Unparalleled BS from MS. (Score:5, Insightful)
It's nothing like that actually, you are comparing apples to supernovas.
~S
Thread Creation (Score:5, Insightful)
I don't think it's surprising that a piece of code might behave in an odd way if it's given invalid input, i.e., if a buffer length is wrong.
I think the real giveaway here is that Windows creates a new thread when presented with this magic length. That's like rolling out the red carpet for the attacking Huns. I don't think the average buffer overflow type exploit gets it's own thread or process.
And of course it's still possible that it was all a mistake. The C language can be used to write some extremely tangled code, if one is so inclined. Something like an incorrectly used setjmp/longjmp could have effects like this.
Re:I would not be suprised at all. (Score:5, Insightful)
This seems to be only useful if MS itself wanted to use it. Use your imagination as to what they'd do with it. I can think of all kinds of things.
Patch (Score:3, Insightful)
Who DOCUMENTS their evil backdoor? (Score:5, Insightful)
Lest we forget that Wine also proved vulnerable, and it was a clean-reimplementation of the specs!
Re:Possible uses? (Score:2, Insightful)
That's got to be at least a few.
I imagine they could just turn this [msn.com] into a wmf file and run whatever code they want on millions of PCs.
Re:Government backdoor? (Score:3, Insightful)
Ah, nice Ad-Hominem attack in there... (Score:5, Insightful)
IMHO your "debunking steve gibson" site is nothing but a smokescreen to divert the attention from Microsoft's vulnerabilities and backdoors.
Re:And this door leads to... (Score:4, Insightful)
Since profit is all a corporation cares about, suing away those profits is the only way to punish it.
Re:Thread Creation (Score:5, Insightful)
Again, agreed. But again, the catch is in the particular kind of odd behavior. If I were writing that code and it hit an invalid length, I'd probably abort processing of the whole file, presuming data corruption. Failing that I'd just skip over the flawed block and proceed with processing the next one. In that case, I could imagine not checking the length very carefully and just going to " + " to process the next block -- this would produce the observed "next byte" pointer.
The problem is in the semantics: I said *process* the next block, not *execute* it. If anything this would just cascade into more error cases, since the data that was expected to be the "next block" would almost definitely also have a malformed header (since it wasn't intended to be a header at all), etc.
So, I guess you're right - the tipoff is still that actual code is executed without having to be specifically pointed to (i.e. buffer overrun), and that it's executed in its own thread, rather than taking over the processing thread that was interpreting the metafile in the first place.
Re:Yeah... (Score:0, Insightful)
Even if SG is a flaming idiot, that doesn't mean he isn't or can't be right. Even a stopped clock has the right time twice a day, as the saying goes. Crank or not, he could be on the money in this case and since those who have read the article seem to think he is on to something at least worth looking at... it seems ignorant to just dismiss him outright.
This is what is called having an open mind.
--SD
Re:Length==1 (Score:2, Insightful)
I'm not entirely convinced. The code for the valid case presumably reads the subroutine address from the file, then starts a new thread which jumps to that address: it's not inconceivable to me that if the header is invalid it won't read the target address from the file, so the address variable just contains whatever was previously on the stack... which could well be the address of the data that's been loaded from the file (e.g. if it was previously used to hold the pointer into the header).
It may well be an evil backdoor, but it could just as easily be plain old bad programming.
Re:Government backdoor? (Score:3, Insightful)
Re:I would not be suprised at all. (Score:5, Insightful)
- How about a totally stupid idea that MS thought was good?
I mean MS has a long history of ignoring security for usability, lock in and whatnot. WMF dates back to close to 10 years, back when MS really didn't give a damn about security. Even after a the big Gates propaganda email and Trusted Computing Initiative and all the hoopla, XP SP2 allows blank passwords for administrators, the user created during installation is an administrator, again if password is blank no one gives a shit. Remote registry is on by default. RPC on by default. Administrative shares are on by default. Not to mention a plethora of completely useless services.
MS just doesn't understand security. This WMF example is nothing different. It's some ancient code that never got looked at. Add to that the fact everyone and his mother is root, AND that the OS is a big bowl of spaghetti (hi2u IE deep in kernel), you get another attack vector vs Windows systems.
Did someone maliciously implement this WMF "feature"? I doubt it. It looks like another regular MS security hole that shows that MS has no clue about security.
Re:Yeah... (Score:5, Insightful)
Slash used to be a much better place (Score:2, Insightful)
Re:And this door leads to... (Score:3, Insightful)
If you buy a cell phone and decide the interface is sucky, you don't punish the company by suing them. You punish the company by buying another brand next time.
Re:And this door leads to... (Score:4, Insightful)
A lawsuit is not the answer to everything.
Too true.
This is a case for criminal prosecution. Gibson has uncovered evidence that at face value demonstrates that there has been a conspiracy to defraud Windows users, and possibly to defraud Microsoft Corporation itself. Microsoft's internal documents would identify the coder(s) involved in this deceit, and possibly other conspirators.
I think it is time for the Washington State Attorney General to give this to a Grand Jury. (IANAL, but I think it is the business of a Grand Jury to determine if a crime has been committed in this kind of circumstance).
Let a Grand Jury hear this evidence and decide whether it appears that some person(s) deliberately set out to violate the privacy of Windows users.
Not sure... (Score:3, Insightful)
1 as an input value is one of those classic boundary conditions that developers should always specifically test against (but sometimes don't...along with 0, negative numbers, MAX_whatever, etc)...so I'm not convinced that it was just a coding error. If the "magic key" length was something completely random like 6385492, then I would be more suspicious.
C'mon MS...let's see the code!
Re:Thread Creation (Score:4, Insightful)
But that's only an issue if the WMF-processing code doesn't create a new thread in order to call the subroutine in the valid case. In reality you'd almost certainly want the callback to happen in its own thread, rather than to allow anyone to run abitrary code in the same thread as the print server.
Re:Unparalleled BS from MS. (Score:5, Insightful)
Comment removed (Score:4, Insightful)
Re:Please not Gibson again... (Score:5, Insightful)
Easy one to test. (Score:3, Insightful)
However, there are a few very specific ways in which you would write code to deliberately look for that specific value in a specific portion of an operation. These ways can be checked by inspecting a disassembled version of the code. (But do this outside of the US, or the DMCA droids will Use The Force.)
Since WINE shows the same hole and the coders are not the same, it would be my guess that the problem is specifically in a DLL that is used/usable by both. It should also be possible to massage WINE to fire up a disassembler with the correct entry point into the DLL that has the hole, when passing the exploit payload. It might take a while (I suggest getting a few month's supplies in advance), but it should be possible to determine exactly where the exploit is, whether it looks "natural" or not*, and whether that specific section of code is likely called by other graphics routines.
*A "natural" bug could include a series of conditionals and jumps, where the 1 is simply the untested case that falls into random code. An "unnatural" case would be to test specifically for 1 and to jump in a different way than for other cases. (eg: If other cases jump to subroutine, and 1 does a one-way jump OR on return is the sole case that jumps over all error conditions.) If that one case has an abnormal test and an abnormal jump, it would be next to impossible for it to be accidental.
Actually, it might be useful against Microsoft in their appeal over the EU ruling. The EU ruling demands greater transparency of protocols and code, and demands code be uninstallable by someone. The politicians might not care much about the exploit, even if it were deliberate, but I'd be willing to bet the EU's lawyers would. Even if Microsoft as a corporation were innocent (yeah, right), it demonstrates a valid legal concern that cannot be resolved using totally closed, airtight methods.
Re:Unparalleled BS from MS. (Score:1, Insightful)
I can't believe even on Slashdot that drivel like this was moderated +5 insightfull. That you even consider a software exploit even remotely close to Nazi concentration camps shows us that you have a very poor understanding of the scale of tragedy. You should be ashamed of yourself.
Re:Thread Creation (Score:3, Insightful)
The whole Escape/SetAbortProc vulnerability is built around some (admittedly stupid) functionality in WMF files. WMF files have the ability to set an application callback function for an abort condition.
If the code which prcoesses this WMF file is going to call a user-supplied abort procedure, it's very reasonable for it to create a separate thread for that to happen in, rather than blocking. After all, it has no way of knowing what the application's response will be, or how long it will take.
Re:Government backdoor? (Score:2, Insightful)
Re:Not sure... (Score:3, Insightful)
Gibson's findings are interesting, and as you say, certainly merit more study. As someone else said somewhere around here, stepping into and/or disassembling the relevant Microsoft code would give greater insight, as would finding out what old versions of Windows carry this problem - including old old versions like Win3.1 or whichever version introduced WMF in the first place.
It's his assertions based upon those findings that may be a bit suspect, but that's what future research would hopefully clear up. Considering that we can't rely upon Microsoft for full disclosure, we need someone in a country that's a bit more, um, liberated than the U.S. in terms of reverse engineering to take a look at it. Gibson's rantings may seem over the top sometimes, but his strategy is to get someone with the expertise/legal protections/authority/etc. to get involved. (For that matter, it's not unlike the kickback rumors that CmdrTaco responded to the other day. Few people believed that they were actually taking kickbacks, even among the people who posted those rumors in the first place, but the rumors were enough to get CmdrTaco to take action concerning the actual problem of people abusing Slashdot for PageRank.)
Re:Possible uses? (Score:3, Insightful)
Probably more to be found, may work together? (Score:3, Insightful)
That we know of that is. This has been lurking about in every version of windows since 95, right? And it's taken until now to be brought to light. How many other similar seemingly innocent bits of code in those millions of lines of legacy windows code do similar things? The question is not what can this exploit do on its own, but what can it do in concert with others that may exist? OK, so maybe I'm giving MS or the rogue programmer, or whoever did this (length==1 check and seperate thread would imply it's not a mistake) too much credit, but if whoever did this was very clever they might have implemented a waterfall backdoor of sorts. In other words there's two or three exploits that when used in concert spell pwnage for almost any windows box. I'm willing to bet there's more here that hasn't been found yet. I'm also betting, along with others, that MS will not accpet responsiblity, nor even point the finger at a programmer or contractor/company to take the fall because that would also make them look completely unsecure. How many programmers have contributed to windows code over the years? And MS would be admitting they don't have knowledge of any backdoors those programmers may have introduced? No, more likely as Benanov (583592) suggested, MS will simply try to smear Gibson as someone with a vendetta and/or crackpot/idiot and try to downplay the whole thing as it has been.
This is exactly why closed source is dangerous. Even security through obscurity is useless when the code holders don't know what's in their code. Open source may have similar problems, but at least there's plenty of people looking, and plenty who will be motivated to correct an issue when it's found instead of trying to pretend like it never happened. Which includes the issue of whodunnit and how to stop that from happening again.
Re:I would not be suprised at all. (Score:4, Insightful)
Re:Government backdoor? (Score:3, Insightful)
You'd want something in the base system of ALL Windows version, which couldn't be disabled AT ALL, doesn't require a user to be logged-in as an admin, or stupid enough to open anything sent to them.
If I was making a backdoor, I'd put it in something basic... Have the IP stack open a port when recieving a specially-crafted packet. Have the filesystem driver silently execute a file if it find a special signature in it (eg. code embedded in a cookie/web-page), etc.
Re:Rootkit (Score:3, Insightful)
Re:I would not be suprised at all. (Score:3, Insightful)
Furthermore, if Gibson is so sure of himself, why isn't his own test utility available to everyone? (Apparently it was only available to Laporte's listeners... not likely to be the most unbiased audience.)
Net result: I knew Gibson's tinfoil hat was a trifle snug, but now I'm sure it needs a complete refitting.
Re:I would not be suprised at all. (Score:3, Insightful)
It's just simple observation to say that the only site that would be consistent on every Windows system is a Microsoft site, somewhat how on my mac I am connected to apple after a clean install when I open Safari. One could say the only site that would be consistent on every mac would be apple.com.
-PS I don't think it was an intentional backdoor.
Re:blank admin password (Score:4, Insightful)
If you're going to accuse someone of trolling, you want to be pretty sure about your facts.
if you have a blank admin password, XP prevents ANY remote network access using that account.
Hmmmn, thats an interesting band-aid.
You are actually more secure with a blank password.
Really? More secure with a blank password? I doubt it.
Would make privilige escalation pretty damn easy after you'd hacked a user account.
And it makes all that least priviliged user stuff that MS goes on about a little irrelevant too.
Re:I would not be suprised at all. (Score:3, Insightful)
And considering how old is the code in question, why hasn't any exploit for it ever been seen in the wild? Surely Gibson is not the only person poking into obscure corners of Windows.
I'm reminded of how malicious code can be embedded in the comment field of GIFs, and executed by an accomplice program... that exploit was never seen in the wild either, but has been known about for as long as GIFs have existed. Was it part of a grand conspiracy to force us all to subscribe to Compu$erve??
Re:Government backdoor? (Score:3, Insightful)
I.e. the back door has to look like enough like a bug that finding it won't cause people to immediately realize that you're installing back doors intentionally.
Something like a buffer overflow in the TCP stack that only happens with packets of an exact size (off by one in some checking routine.)
Re:Ah, nice Ad-Hominem attack in there... (Score:5, Insightful)
In my ever-so-humble opinion you completely missed the point of the parent. The reputation, sanity, motives, and anything else dealing with the person making the claim has nothing to do with the validity of the claim itself.
In this particular instance, there is at least some apparent merit to the idea that this was an intentional backdoor, and that merit would be there regardless of who points it out.
If you want to discredit the idea that this is an intentional backdoor (of which I am far from convinced), then you should attack the argument directly, not the man making it.
Re:I would not be suprised at all. (Score:5, Insightful)
I can't personally think of any kind of official reason why Microsoft would want to shove code onto Windows machines just from visiting their website. They've got tons of other ways of doing this.
Re:Reflections on Trusting Trust (Score:2, Insightful)
Re:I would not be suprised at all. (Score:3, Insightful)
I assume that you're thinking of Windows Update, but at a guess I'd imagine that most (recent) Windows machines get most of their updates via automatic updates, or not at all. I'd be very surprised if "all Windows machines" visit any given site on a regular basis.
(In fact it's trivially easy to disprove your assertion - I have access to 3 XP machines, and none of them visit any of MS's sites on anything approaching a regular basis, but that's beside the point)
This seems to be only useful if MS itself wanted to use it. Use your imagination as to what they'd do with it. I can think of all kinds of things.
I can't think of a single thing that would be worth it. An attack like that would be discovered and traced back to them, and they'd be crucified for it. Unless they could achieve their aim before that happened, there'd be no point, and short of taking over the world, I can't think of anything that would be worth it. Even if they could think of a way to make money using it, the courts would sieze it all anyway.
Re:I would not be suprised at all. (Score:2, Insightful)
Comment removed (Score:3, Insightful)
Re:Ah, nice Ad-Hominem attack in there... (Score:1, Insightful)
http://it.slashdot.org/comments.pl?sid=173878&cid
*and confused he is*
Re:Old coding practises, not conspiracy (Score:2, Insightful)
I get the feeling you don't spend your days mired in Win32 application coding. The Win32 libraries are all written in C, not C++. This is why different languages such as C, C++, VB, and even the new
And oh yes, don't think that MS is re-implementing CreateWindowEx() (in user32.dll) in the
Take a look at the actual Win32 API
http://msdn.microsoft.com/library/default.asp?url
See any classes in there?
ENOUGH. Gibson was right about raw sockets. (Score:3, Insightful)
After the relentless pounding and smearing of Gibson, Microsoft quietly disabled the raw sockets code, whatever the hell it was.
Gibson was right. They fixed the problem. He was right, The Reg was wrong.
Jesus, it's like arguing with 20,000 Bill O'Reilly's. Truthiness! Gibson is a maaaaadddmaaaannn!
And since people rarely followup to what they think is truthy, they missed the fact that the only reason the Raw Sockets disaster didn't happen is because MICROSOFT QUIETLY FIXED THE PROBLEM, JUST. LIKE. GIBSON. SAID. THEY. SHOULD.
And as for being a top security professional, something he never claimed to be - he's a developer - what makes you all think that the very best security people at the NSA and Microsoft don't already know all about the exploit, because it's one of the many that they placed there in the first place?
Listen, everyperson, Microsoft has cooperated with Justice, the FBI, the NSA and all the other alphabet boys since the beginning. Windows and Office are monitored at will, you can bet your last god damned dollar. Can you imagine MS refusing to cooperate, especially during a ten year monopoly trial??
(originally posted as AC because I'd moderated; however, even posting as an AC, the code retroactively undid my moderation. Didn't know that would happen. A little warning, Slashcode?)
Plenty evidence....like the backdoor CODE! (Score:3, Insightful)
(Defending Microsoft - only on Slashdot. Ok, so some monkees tapping on a keyboard while the programmer wasn't looking snuck this code in ;)
First of all, Gibson is no bomb thrower, he's uncovered some pretty serious security issues with Microsoft. I'd suggest reading his web site - he's a very thorough person, and doesn't make any wild unsubstantiated, naive, biased claims, like, say, Slashdotters. He's a long time Windows user, not a Mac fan, nor an open-sourcer (at least until recently, for reasons like this)Now, to quote the transcript, curious where you would even be able to make the claim that that this *isn't* a backdoor:
Yeah, he's saying this is a deliberate backdoor. Listen to the article or read the transcript, then think about it a little. Now, he's not saying *what* Microsoft put this in for. Did someone put this in for testing -that's my take, from a programmer perspedctive but .. who the heck knows. That's sorta the problem with proprietary software, we might never know. Buyer beware.