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.

Comments

Length==1

[atfrase]

This does look awfully like a special-case trigger. The idea of a backdoor is to have it look for a specifically crafted but completely nonsensical and invalid input sequence -- this serves as the "key" to the backdoor, ensuring that no other designer or user accidentally stumbles onto it. Since we assume that legitimate users and developers will only provide valid input, we design our "key" to be definitely invalid. For me, that length==1 trigger is the most convincing evidence. It's not just that it's the wrong input, it's that it's the one specific value of wrong input that triggers the behavior. That seems like design.

Re:Length==1

[stevied]

Obviously SetAbortProc should not be implemented for WMF playback, but assuming somebody screwed up and just called the normal version of Escape(), could the behaviour we're seeing here not somehow be the result of not checking the validity of the length parameter properly, performing some arithmetic on it, and possibly falling through to some other code that happens to a jump or call?

Re:Length==1

[Procyon101]

Possibly, but I doubt it's a Microsoft sanctioned backdoor. Any "OFFICIAL" backdoor from MS would have a much more complex key to get in than "1".

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.

Re:And this door leads to...

[Tebriel]

A lawsuit is not the answer to everything.

Re:Unparalleled BS from MS.

[Soporific]

I't a lot like the Allied soldiers who were fighting in Germany, being told all these horror stories about how evil the Nazis actually were, and then coming upon a concentration camp and finding out that these stories were real after all.

It's nothing like that actually, you are comparing apples to supernovas.

~S

Thread Creation

[Lagged2Death]

For me, that length==1 trigger is the most convincing evidence.

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:Thread Creation

[atfrase]

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.

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:I would not be suprised at all.

[NtroP]

I could see someone deliberatly doing this, maybe a contractor or a disgruntled employee.

The problem with that argument is that in order to exploit this backdoor you'd have to get the target computer to load a WMF file. The main practical way to do this would be to embed it in a web page and have the target visit that page. The only sites that all windows machines access on a regular basis are Microsoft's. The employee would also have to have access to Microsoft's web site to exploit this reliably.

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.

Who DOCUMENTS their evil backdoor?

[nweaver]

Who writes an evil backdoor, which dates back to Win3.1 days (when you didn't NEED an evil back door, and Windows had no clue what this Internet thing was about), and then DOCUMENTS it?

Lest we forget that Wine also proved vulnerable, and it was a clean-reimplementation of the specs!

Ah, nice Ad-Hominem attack in there...

[Spy der Mann]

The name means nothing. It's the facts that matter. Whether he is a one-day hacker or some looney, he discovered that for Length==1, (a completely invalid value that makes no sense for WMF's), Windows creates a new thread and starts executing the code.

IMHO your "debunking steve gibson" site is nothing but a smokescreen to divert the attention from Microsoft's vulnerabilities and backdoors.

Re:Ah, nice Ad-Hominem attack in there...

[TheNumberless]

In my not so humble opinion, you don't know what you are talking about. Go read some of the links in that site, and you'll see that Steve Gibson is one of the many "security experts" that have no clue but gives dangerous and very wrong "solutions".

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.

[dc29A]

I could see someone deliberatly doing this, maybe a contractor or a disgruntled employee.
- 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...

[NtroP]

Isn't this the same Steve Gibson that was freaking out about how Raw Sockets in XP were going to destroy the world a couple of years ago?

Didn't that get quietly fixed in a subsequent update and therefore NOT become an issue? He may be an alarmist, but he's normally a Pro-MS guy. In this case, I think he's on to something.

Re:Unparalleled BS from MS.

[mattbot 5000]

It's nothing like that actually, you are comparing apples to supernovas.

It's worse, actually. He's comparing security holes to concentration camps.

Re:Please not Gibson again...

[NtroP]

Steve Gibson is not a security expert

I'm not a security expert either. But if I came up with this evidence, how would that change the reality of the situation. The evidence stands on its own merit. His reputation has nothing to do with it. This is easily verifiable by anyone with at least his level of knowledge. It will be interesting to see what happens when other "real" experts start looking at this.

Re:I would not be suprised at all.

[mrseigen]

I'm not quite sure why they'd want to use it. End-users already trust Microsoft implicitly because they made the operating system, so if they wanted to, for instance, install some software on all Windows machines that reports home if it detects a pirated copy, they could just do it through a service pack update. Most people would willingly install it (or click the little automatic button in Windows Update), and there'd be none of this Tom Clancy technothriller intrigue.

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.