Inside the WMF Backdoor

Steve Gibson (of SpinRite fame) proposed a theory in his weekly Thursday-night podcast last week that if true, would be the biggest scandal to ever hit Microsoft - that the Windows Metafile (WMF) vulnerability that drew so much media attention last month is actually a backdoor programmed intentionally by Microsoft for unknown reasons. Slashdot picked up the story the next day and I received a flood of emails asking me to look into it. I finished my analysis, which Steve aided by sending me the source code to his WMF-vulnerability tester program (KnockKnock), over the weekend. In my opinion the backdoor is one caused by a security flaw and not one made for subterfuge. I sent my findings to both Steve and to Microsoft Monday morning, but because the issue continues to draw media attention I’ve decided to publicly document my investigation.

Understanding the WMF vulnerability requires a brief background in WMF files. A WMF file is a script for executing graphics commands, called graphics device interface (GDI) functions. Each command is stored as a record in the WMF file and examples of GDI functions include ones to draw lines, fill rectangles, and copy bitmaps. Image files like bitmaps, GIFs, or JPEGs, on the other hand, store the representation of pre-rendered images. Because an application can direct a WMF file’s execution at different devices, like screens and printers, with different graphics resolutions and color depths, their advantage over pre-rendered formats is that they scale to the capabilities of the target device. For this reason, many clipart images, including those used by Microsoft Office, are stored in WMF files.

WMF files originated with early 16-bit versions of Windows that implemented single-threaded cooperative multitasking. In that programming environment a process can’t perform two tasks, such as printing a document and displaying a print-cancel dialog, concurrently. Instead, they have to manually interleave the tasks, periodically polling to see if the user has asked to cancel the printing. The programming model for printing in Windows therefore has the concept of an abort procedure that an application can set before calling the printing API. If such a procedure is registered Windows periodically calls it to give an application a chance to signal that it wants the print job cancelled. Otherwise there would be no way to abort a long-running print job.

The WMF vulnerability stems from the fact that WMF supports the SetAbortProc API, which is the GDI call to set an abort procedure, that Windows expects abort procedure code to be stored directly in the SetAbortProc WMF record, and that Windows will invoke the procedure under certain conditions immediately after processing the record. Thus, if an attacker can get your computer to execute their WMF file through Internet Explorer or Outlook, for example, they can make your system execute arbitrary Windows commands, including downloading malicious applications and launching them.

Steve Gibson’s intentional backdoor theory is based on four suspicious observations he made regarding the vulnerability and the behavior of his tests with WMF files that contain a SetAbortProc record:

There is no need for WMF files to include support for the SetAbortProc API.
Even if an abort procedure is set by a WMF file, Windows shouldn’t execute it unless some abort condition is triggered, which should never occur when executing a WMF file.
He could only get his WMF file’s abort procedure to execute when he specified certain invalid values for the size of the record containing the SetAbortProc command.
Windows executes code embedded within the SetAbortProc record rather than expect the record to reference a procedure within the application executing the WMF file.

Steve’s belief that WMF files should not support the SetAbortProc API comes from the documentation for how Windows calls an abort procedure registered via SetAbortProc:

It [the abort proc] is called when a print job is to be cancelled during spooling.

The statement implies that Windows detects that a user or printer wants to cancel a print job and informs an application by executing the registered abort procedure. Steve echoes this understanding in a posting on his website’s news group:

[the abort proc] is the address of an application-provided "callback" -- a subroutine provided by the application that is expressly designed to asynchronously accept the news and notification of a printing job being aborted for whatever reason.

Steve reasoned that WMF files execute to screens, not printers, and so it makes no sense to abort their execution. Further, his tests showed that Windows calls the abort procedure registered by a WMF file immediately, when there’s no apparent cause for cancellation.

WMF files can be directed at a printer, however, and not only that, but the abort procedure documentation is misleading. Its correct description is in the Microsoft documentation that describes the basic steps for writing code that prints to a printer:

After the application registers the AbortProc abort procedure, GDI calls the function periodically during the printing process to determine whether to cancel the job.

Thus, the abort procedure really works both ways, providing Windows a way to notify an application of printing errors and the application a way to notify Windows that it wants to cancel printing. With this interpretation Windows’ execution of the abort procedure immediately after one is registered makes sense: Windows is calling the procedure to ask it if the playback of the rest of the procedure should be aborted.

Even still, the question remains as to why WMF files implement the SetAbortProc GDI function at all. My belief is that Microsoft developers decided to implement as much as the GDI function-set as possible. Including SetAbortProc makes sense for the same reason that abort procedures for printing make sense: WMF files can consist of many records containing complex GDI commands that can take along time to execute, especially when sent to a printer and on old hardware like the kind on which the cooperatively multitasked Windows 3.1 operating system ran. The abort procedure gives applications the ability to monitor the progress of a playback and to unilaterally abort it if a user makes UI choices that make a complete playback unnecessary. In addition, if a WMF file is sent to a printer and there’s a printer error Windows must have a way to know that an application wants to cancel WMF playback, which is another reason to invoke the abort procedure from within the PlayMetaFile loop. This Microsoft article from 1992 confirms the behavior as designed.

I’ve addressed the first two of Steve’s observations, but what about his claim that the abort procedure only executes when the SetAbortProc record contains certain invalid record sizes? I’ve analyzed the control flow of the PlayMetaFile function that executes WMF file records and found that, if an abort procedure is registered, it calls it after executing each record except the last record of the file. That behavior makes sense since there’s no need to ask an application if playback should be aborted when the playback is already completed.

Steve’s example WMF file contains only one record, the one that specifies SetAbortProc, so under normal circumstances PlayMetaFile will never call his abort procedure. The record sizes that he found trigger its execution cause PlayMetaFile to incorrectly increment its pointer into the WMF file such that it believes that there are more records to process, whereas the values he used that don’t trigger the execution land it on data values that indicate there are no more records. So his assertion that only certain magic values open the backdoor is wrong.

The remaining question is why PlayMetaFile expects the abort procedure to be in-lined in the metafile. It’s that fact that allows a hacker to transport malicious code within a WMF file. The actual reason is lost with the original developer of the API, but my guess is that he or she was being as flexible as possible. When a WMF file is generated in memory and played back by the application in the same run, like it would to create a graphics macro and use it mulitple times, it generally makes no difference if the procedure is copied or not.

For the code in on-disk WMF files to work any references it makes to data or code, such as Windows functions, must be to hard-coded addresses. This means that WMF file code won’t work if Windows system DLLs change in size or load into different locations in memory and therefore WMF vulnerability exploits only work on specific patch-levels of Windows. While this might make an argument against a design that includes the abort code in the WMF file things were different when the format was architected. In the Windows 3.1 “large” memory model code is inherently location-independent and Windows was never patched, so both Windows and an application could simply copy an application function into the WMF file and assume it would work when played back by the same application in a later run session. In any case, its not clear that the developers envisioned applications creating on-disk metafiles with abort procedures. Also, as Microsoft’s Stephen Toulouse pointed out in Microsoft’s rebuttal to Steve’s claims, the security landscape in the early 1990’s was very different than today and all code, including that stored in a WMF file, was inherently trusted.

The vulnerability is subtle enough that the WINE project, whose intent is to implement the Windows API for non-Windows environments, copied it verbatim in their implementation of PlayMetaFile. A secret backdoor would probably have been noticed by the WINE group, and given a choice of believing there was malicious intent or poor design behind this implementation, I’ll pick poor design. After all, there are plenty of such examples all throughout the Windows API, especially in the part of the API that has its roots in Windows 3.1. The bottom line is that I'm convinced that this behavior, while intentional, is not a secret backdoor.

Originally by Mark Russinovich on 1/18/2006 11:05:00 PM
Migrated from original Sysinternals.com/Blog

# re: Inside the WMF Backdoor

Mark, Given your current good reputation, I am sure that this single blog post will put people at ease must better than 20-100 statements from Microsoft :)

1/19/2006 12:00:00 AM by Troy Phillips

# re: Inside the WMF Backdoor

Thanks for this excellent analysis! Steve Gibson certainly does not deserver to be taken seriously by anyone, but unfortunately he is :-(

Do you have ANY wild idea why Microsoft might have kept the AbortProc in WMF files during security reviews?

Could there be any reason like an application using WMF-files to cache rendered content (including all commands, including SetAbortProc) and then replaying them without accessing the disc or internet or so?

While WMF can be seen as a format to store cliparts and vector grahics on disc, could it also be seen as a way to record a macro and playback it without ever touching the outside world?

It would be interesting if the findings would allow such a guess and that Microsoft once decided against removing it because of backward compatibility?

1/19/2006 4:15:00 AM by Anonymous

# re: Inside the WMF Backdoor

Of course it's not a backdoor - if it were a backdoor from so long ago it would have been found a decade ago and exploited by now. It's just an error in judgement. I'm sure Vista will have many of these as well and all in the name of DRM.

1/19/2006 4:20:00 AM by Sime

# re: Inside the WMF Backdoor

I'd made my mind up already: if it's conspiracy vs. "cock up" - it's invariable always the latter.

1/19/2006 6:15:00 AM by Anonymous

# re: Inside the WMF Backdoor

That's a very nice explanation. I came to the same conclusion when looking at the code (my detailed explanation is blogged here: http://www.jgc.org/blog/).

I don't believe that Steve is right, this is not a backdoor. I'm also not clear that Microsoft ever intended there to be in WMF file code. I think this is a side effect of the way they hooked up the metafile Escape function to the GDI Escape. By simply assuming that the metafile parameters could be passed to Escape verbatim they created this vulnerability (especially since the third parameter is an arbitrary pointer; in this case which points into the metafile).

John.

1/19/2006 6:20:00 AM by John Graham-Cumming

# re: Inside the WMF Backdoor

I'd made my mind up already: if it's conspiracy vs. "cock up" - it's invariable always the latter.

That's called "Hanlon's Razor":

Never attribute to malice that which can be adequately explained by stupidity.

1/19/2006 7:14:00 AM by Anonymous

# re: Inside the WMF Backdoor

Steve Gibson is well known for kicking up a fuss about anything that gets him media attention. Raw packets and all that...

1/19/2006 9:06:00 AM by Ed

# re: Inside the WMF Backdoor

Or, as Napoleon said, "Never ascribe to malice that which is adequately explained by incompetence."

1/19/2006 9:29:00 AM by Anonymous

# re: Inside the WMF Backdoor

There was one other point that Steve Gibson made that would be good to hear a rebuttal on.

Wasn't the WMF code recently overhauled, supposedly gone over with a fine toothcomb. I'm no coder, but that the actual function was 'in-line' inside the metafile, and therefore presumably, open to being misappropriated; given the amount of sites out there that have wmf content running unsolicited, you'd think someone would have said, wait a minute, this could be exploited.

In fact, now I see another comment asking the same question.

You think it was just a case of, well, it might be open to exploitation, but it hasn't yet been exploited yet, so let's just leave it in, it'll take too much effort to rip it out?

I wonder how long it would have sat in the code if source code was available. But that's a seperate issue.

1/19/2006 9:42:00 AM by ruy_lopez

# re: Inside the WMF Backdoor

Q: Is this a back door?
A: Yes - that's why it's such a serious vulnerability.
Q: Was it intentionally put into Windows code.
A: Yes.
Q: Was it intended to be misused/abused?
A: Almost undoubtedly not.

Based on the Gibson's transcript (http://www.grc.com/sn/SN-022.txt)
it looks like Steve was right on - it is a backdoor intentionally placed
in Windows code; I guess his sin is calling a spade, a spade. I don't see
where he ever claimed that MS intentionally did this to subvert security
for their own purposes which appears to be the claim of the Gibson
nay-sayers.

On the other hand,
Q: When was this backdoor coded?
A: About 1992.
Q: How old was VMS at that time?
A: 15 years.
Q: Who directed the development of Windows NT?
A: Dave Cutler.
Q: What's Cutler's background.
A: Directed VMS at DEC.
Q: On who's watch was this security lapse ported into the
Windows NT stream.
A: Presumably Cutler's.

While anything's possible, it's hard to imagine how a security lapse
of this magnitude (trusting user-written code) could have made its
way into VMS code.

The point is that Stephen Toulouse's "the security landscape in the early
1990’s was very different than today" is, well, self-serving. Only in MS's
myoptic view is this the case.

1/19/2006 10:14:00 AM by tc

# re: Inside the WMF Backdoor

I believe that the wmf exploit was left im by microsoft mainly because of the amount of checking there would of been earlier, i can also confirm its still affecting windows. try looking at ***usaporn-dot-org*** for one its a well known dropper, i hope the name is nothing to do with the usa and that the person is actually a russian thats registered the name,

damn more conspiracy

either way

a it shouldnt of been there and accessable by anything other than a printer user.

b found during the last 12 months

c fully fixed by microsoft.

the worst thing ever to happen was to provide an operating system with a computer , bios based would of been better

1/19/2006 2:46:00 PM by Anonymous

# re: Inside the WMF Backdoor

ruy: This same vulnerability sat in the Wine source, so having the source available didn't seem to make a difference.

1/19/2006 4:10:00 PM by Anonymous

# re: Inside the WMF Backdoor

You gotta love the people who (obviously can't) and quickly jump to defend MSFT. Let's see now we went through VS, MVS, VMS, OS2, etc... and "we" still can't build an OS? If this explanation is sound, which I have no reason to question, then somebodies at MS need to be shown the door. Come on, they have Security groups and QA groups, and the development groups who SHOULD have caught this.

Now that I think about it, even Mark has to guess at what some coder was thinking when she wrote this, and maybe she did it intentionally. You'll never know will you? Maybe somebody's been watching all of us for years, and it ends up in some massive NSA database.

1/19/2006 4:14:00 PM by Habbab

# re: Inside the WMF Backdoor

Yes, Microsoft Q&A should have caught this. But, well, they didn't.

In 1992, this vulnerability would simply not have caused the fuss it does today. Of course it would still have been a vulnerability, and had it been pointed out it would have been fixed -- but people would not be up in arms about it.

Calling Microsoft incompetent over an old bug that never got fixed is easy, but it's slightly overblown. Let's not forget that this was a feature -- it served a need. It did so in a ham-fisted way that we can easily denounce as foolish with the benefit of hindsight, but let's be honest, sub-optimal solutions ("just make it work") are not exactly uncommon in software development.

Much worse mistakes than this have been made, by people and companies with much better reputations in this department than Microsoft.

1/19/2006 6:01:00 PM by Anonymous

# re: Inside the WMF Backdoor

People are being a bit harsh on Steve here...

1. AbortProc has definitely been in Windows for a long time, without doubt.

2. Was it deliberately put there? Yes - it's usage is so clear that it's not there accidentally. It's not like this is a buffer overflow - someone HAD to have coded it this way.

3. Was it maliciously put there? Hard to say - possibly or possibly not. There are clearly legitimate uses for this "feature" of meta-files.

4. Was Microsoft careless? Yes! While there are naturally perfectly good reasons for having such code, Microsoft has not/did not take due care to ensure that this code could only be used for its intended purpose. I do a lot of coding in various languages, and I always make sure that my code can only be used for what it's supposed to - be copious error trapping, and scrutiny to inputs to functions. This code was rushed.

5. Should we go beserk at Microsoft? No! At the time this code was originally developed, I doubt anyone even conceived this as a potential attack vector - nevertheless, whoever coded this was sloppy.

6. Why sloppy? If the "malicious" side of this problem can be triggered using an impossible value of an input parameter - in this case, 1 - whoever coded this should have trapped for that input - and thrown up an error that the input is wrong - not drop into arbitrary code.

1/19/2006 6:15:00 PM by Michael Wyres

# re: Inside the WMF Backdoor

No body knows what Microsoft's, Mark's or Steve's intentions are but themselves. Let not talk about intentions.

Undoubtedly Mark is a professional in anaylsis of extremely technical stuff. While Steve often alert people of potential unsafe computing. I don't know their intentions, but I *think* they are having goodwill in computing.

So let's not attack these people who spend their time investigating potential risk to alert/inform users/administrators (better cause a fuss to get attention for other investigations and get a fix than being exploited by malicious attacks, right?) This WMF vulnerability is a good example already. We've got Steve at first and then Mark to follow up. May be someone to follow up later.

Lets do something constructive in the computing industry instead.

1/19/2006 7:38:00 PM by Felix the okayman

# re: Inside the WMF Backdoor

Given the time frame where this "BUG" appeared in NT ( it apparently does not affect Win9x or Win3x ), the comment of Congressman Weldon in the September 28, 1999 Internet Caucus Panel Discussion might be relevant:

Rep. Curt Weldon: But the point is that when John Hamre briefed me, and gave me the three key points of this change, there are a lot of unanswered questions. He assured me that in discussions that he had had with people like Bill Gates and Gerstner from IBM that there would be, kind of a, I don't know whether it's a, unstated ability to get access to systems if we needed it. Now, I want to know if that is part of the policy, or is that just something that we are being assured of, that needs to be spoke. Because, if there is some kind of a tacit understanding, I would like to know what it is.

1/19/2006 9:29:00 PM by David

# re: Inside the WMF Backdoor

Mark,

While I applaud your efforts to explain the *details* of this vulnerability (and nicely done too) and why it may have been allowed to exist, there's one point Gibson brought up you didn't cover: Why, if as you claim that this was seen as a 'feature' in days so long ago (Win 3.x) that code inside a .wmf file could rely upon 'hard-coded addresses when patches didn't exist,' did Microsoft make sure embedded-code-execution couldn't happen under Windows 9x (in fact adding extra code to keep it from ever doing so!) yet still allow it (or more correctly added it to?) their Windows NT series? Therefore, it seems at least one person in the 'NT development' dept. (who could have checked how Windows 9x handled .WMF files) chose to allow for arbitrary code execution instead. It's not a coding error: The 'mistake' was for Microsoft during many code reviews to allow it to continue that way in Win 2000, XP and beyond until an exploit finally made use of it!

(Michael: Gibson recently admitted that he made an error in assuming there was only 1 specific way to trigger the exploits as Mark pointed out to us.)

Though Gibson may be overly flamboyant in ways that market his product, hasn't he helped many more Net users by calling attention to 'security flaws,' telling us how to protect our systems, by being the person he is? Woldn't there have been many more people on the Internet with 'unprotected boxes' full of worms/trojans if he never spoke up?

1/19/2006 9:38:00 PM by The Starman

# re: Inside the WMF Backdoor

Great point about Dave Cutler. I'd really be willing to give Microsoft the benefit of the doubt, but when they come out with statements like the security landscape has changed, that's a bit ignorant, and you really start to wonder about the rest of their statements.

Maybe from Microsoft's standpoint, the landscape has changed - they weren't focused on security then, they are more focused now.

Cutler worked on VMS at DEC, he was probably familiar with the Morris Worm, otherwise known as the "Great Worm". That was 1988. In the movie WarGames ('84?), Mathew Broderick uses a backdoor to hack into a military system. So script kiddies "landscape has changed" if you haven't seen the movie, dust off your VHS player and rent it.

http://en.wikipedia.org/wiki/Morris_worm

Couple other points:

This is a technicality, but my understanding of the WINE vulnerability is that it is a similar issue, but not the same, i.e. the replicated the full functionality of Windows in order to be compatible, but the mechanism of the "bug/feature" is somewhat different. Obviously the code is different. But yeah, if the WINE folks ported this over without thinking about it, (even if it is different) I buy that argument much better than Microsoft's "well it's all in assembly code who reads that stuff anymore" waffling. Don't tell that to folks like Ilfak Guilfanov or Steve Gibson - assembly code wizards.

Finally, and this is the whole Microsoft confusion that started Gibson on the track of figuring out what exactly was broken (I'm sure they are kicking themselves now), what is the deal with Win9x? Microsoft claims the vulnerability is there, but there's this extra step, and thus it's not a "critical vulnerability"? Huh? Talk about waffling. As Gibson points out, if this wasn't intentional, why in the world did they take it out in the later OSes? Cuz seriously, if you write code like this, or if you're at all familiar with buffer overruns and the like, a smart programmer (as detailed in Steve Macquire's excellent book about coding at Microsoft 'Writing Solid Code', would've added a check for the context or something like that)

As to whether this is a backdoor or not, put yourself in the shoes of a lowly MSFT programmer, smart hacker type, but under deadline pressure to get the next great feature out the door. Might this feature somehow help you with testing your code? I recall a web programmer adding a nifty feature to a web page - type in some sql in the url, and it would hit the table. Great for testing. Somehow this got to production, and they basically shut their site down for three days, or ran it in a restricted mode, while they fixed this.

Finally I think the folks who criticize Gibson about his end of the world scenarios are bit misled and naive. (He was right about raw sockets, think SP2).

This stuff is a big deal. Read up on China's Titan Rain hackers. The landscape hasn't changed (NT/Unix/Linux), security is still an issue, exploits are similar, but the stakes, the impact, is vastly different.

1/19/2006 10:57:00 PM by Anonymous

# re: Inside the WMF Backdoor

"On the other hand,
Q: When was this backdoor coded?
A: About 1992.
Q: How old was VMS at that time?
A: 15 years.
Q: Who directed the development of Windows NT?
A: Dave Cutler.
Q: What's Cutler's background.
A: Directed VMS at DEC.
Q: On who's watch was this security lapse ported into the
Windows NT stream.
A: Presumably Cutler's."

My understanding was that this vulnerability goes back to Windows 3.0, which was released in 1990. Part of the problem in this excerpt it that is seems to equate NT 3.1 with Windows 3.x, which is not the case. Also, pointing the finger at Cutler seems a bit misleading, since it seems unreasonable to believe that he was responsible for the design of the WMF format.

Given the nature of the factors required for the exploitation of this, I really don't see why Steve jumps to the conclusion that it's in there on purpose as some sort of backdoor. Part of the problem is that, if Microsoft reviewed this issue during the security code review (as he claims), it's a bit far-fetched to think that they would not address it, knowing that if found out, it could be a huge, huge blow to the company.

1/19/2006 11:45:00 PM by Anonymous

# re: Inside the WMF Backdoor

I am perfectly willing to believe in Microsoft’s incompetence but it that really an acceptable excuse?
Even if the intention was not malicious why did they unblock this functionality after Windows 3.x, enabling it to automatically run code at a time when they should have already been well aware of the security dangers of the landscape?
Why wasn’t this corrected during the recent security code review MS claims to have completed? Were they so incompetent they didn’t realise this could be dangerous or did they just not check properly?

All of us must accept censure when our work is erroneous or flawed especially if we are arrogant enough to believe that opening our work to independent scrutiny is unnecessary.
Why should Microsoft be given a free pass?

1/20/2006 12:44:00 AM by Don't blame me - I'm just imcompetent

# re: Inside the WMF Backdoor

Obviously the WINE release would have the same issue, despite source code being available, as it is a compatibility layer implementation of the Windows API. But can you compare windows meta files' prevalence, when used with the WINE environment under Linux, to their prominence within the MS Windows package, and the fact that most Windows users are running in Admin mode?

I just don't see open source coders spending much time looking at a port of a propritary API with a view to fixing bugs, so that they can then, what? Presumably get in touch with MS and say, here we fixed this problem of yours for free.

The open source dicta, that with enough eyes on the code, all bugs are trivial, can only really operate when the 'eyes' feel they have a shared interest in the end product. How many feel that way about Windows? When I used to use Windows it felt more like they owned my puter, than I owned a part of Windows.

1/20/2006 7:25:00 AM by ruy_lopez

# re: Inside the WMF Backdoor

The "deal with Win9X" is pretty simple.

The vulnerability is there, however there are no default viewers for WMF files. The result is that rather than a drive-by-download attack the user would have to save the .wmf to disk, launch an application that can view wmf files, open the file in that application. MS argument is that this makes it non-critical on those platforms.

Later versions of windows added picture viewer, thumbnails in explorer, etc. and also slightly changed rendering for .wmf formats (non-placable vs. placeable - can't remember which). This introduced the possibilty of remote wmf exploits requiring no user interaction.

The most likely explanation is that when adding the new viewers they wanted to support as many formats as possible, even legacy ones (especially if the render code is already in the OS and probably only needed a line of code to call it). They probably assumed they could trust OS code that had been around for years, whilst the original wmf folks probably assumed their code wouldn't be loading untrusted wmfs from the net.

Combination of incorrect assumptions + long time delay (original coders long gone, etc.) + probably lax documentation = hole appears. All perfectly likely & normal - no need to add conspiracy to get to the result.

1/20/2006 7:26:00 AM by Anonymous

# re: Inside the WMF Backdoor

Part of the problem is that, if Microsoft reviewed this issue during the security code review (as he claims), it's a bit far-fetched to think that they would not address it, knowing that if found out, it could be a huge, huge blow to the company

Calculated Risk + Plausible Deniability (+ short-term memory problems for most people). We'll never know what MS may have gained from this, aside from generally favourable treatment from the anti-trust folks.

1/20/2006 7:41:00 AM by Anonymous

# re: Inside the WMF Backdoor

Mark,

I respect your opinion. But you have not answered my question - when this call changed from design flaw into security bug.

I wish to know dates (or Windows OS versions at least) then there were changes in this functionality.

If it's same code that was used in Windows 3.11 - this is one case, but if it was changed in Windows NT - then it's different.

1/20/2006 7:42:00 AM by Anonymous

# re: Inside the WMF Backdoor

I m not securty expert.

Just one question. Is that same VMS that have backdoor internally ?

Which was exploitted by german hackers in 1980 s ?

1/20/2006 7:43:00 AM by Anonymous

# re: Inside the WMF Backdoor

The security landscape has definitely changed since the early 90s and the days of Windows for Workgroups. It's almost as if today's computers are somehow "inter-networked" across the globe, and physical access is no longer necessary.. ...

1/20/2006 8:31:00 AM by Anonymous

# re: Inside the WMF Backdoor

I really can't understand why putting Cutler into the equation is significant. While it is likely that Cutler would have spotted this problem if given a chance, do you think that his job as NT architect was to go over all the existing Windows code and look for vulnerabilities? Especially mundane stuff like low-level GDI calls?

1/20/2006 8:36:00 AM by Flavio

# re: Inside the WMF Backdoor

Face it, you really can't trust Gibson to be objective when it comes to anything having to do with Windows. He does a podcast with Leo Laporte for chrissakes, who is nothing more than an obviously biased unpaid (?) Apple PR hack.

Was this put in on purpose? Sure, but to basicly say that MS would do this for some nefarious reason is beyond irresponsible. I listened to the podcast, and you can hear it for yourself. Hell even Laporte sounded nervous after Gibson's gradiouse statement, knowing full well it would be well within MS's right to haul these two into court.
People need to go to truly unbiased sources for their security concerns than to listen to podcasts by two people with obvious biases and products to push.

1/20/2006 9:10:00 AM by Anonymous

# re: Inside the WMF Backdoor

There is a clear reason why Microsoft might want to create a backdoor in its operating system. Microsoft was a proponent of UCITA, including its provision allowing "self help", i.e., under certain legal conditions, and in the case of a contract dispute, a licensor could break into a licensee's machine and disable the licensor's software. (The term "self help" is adapted from the legal terminology related to automobile repossession.) UCITA was enacted by two states and the enactment effort, while relatively dormant, is not dead.

If the licensed software is an application program, it is difficult or impossible to break in without being allowed to do so by the operating system. This means that Microsoft would have to be involved in some way in any "self help" effort by a licensor for an application residing on a Microsoft platform. That gives Microsoft reason to create a backdoor, preferably in some operating system function that is likely to be available for entry when the "self help" effort is attempted.

1/20/2006 9:18:00 AM by Anonymous

# re: Inside the WMF Backdoor

I'm going to agree with Mark, but for simpler reasons.

At the time this thing was introduced, nobody was downloading WMF files over the Internet. If a particular malicious employee at Microsoft wanted a backdoor (and even if this had happened, Microsoft as a whole certainly wouldn't be to blame -- it's happened to other companies as well), it wouldn't have been all that exciting to stuff it into a WMF file.

I'd like to add that I think that this is the new frontier of vulnerabilities -- file formats. Up until recently, focus was on securing server code and local permission problems. Today, however, files fly freely around the Internet attached to emails, and are exchanged on file servers. All it takes is *one* bug in a parser or in code that deals with data in a file -- if a corrupt file can cause a program to crash, and I'm sure that we've all seen files that can do this, then there's risk that a security problem exists. Take Word files, for example. They have a very complicated format -- how much do you want to bet that there are zero bugs in the file code? If someone can write a "Word virus" based on a hole like this, then all the macro disablers in the world can't stop such code from spreading around intranet fileservers and travelling with emailed documents. And it's not Microsoft alone at fault here -- Nullsoft (which we all love) has had exploitable in their ID3 implementation in WinAmp for MP3s, and the widespread libjpeg has had exploitable bugs. Libjpeg is open source and has been heavily reviewed and used. If a bug can slip into it, it can slip into an awful lot of file I/O code in programs.

1/20/2006 9:21:00 AM by Anonymous

# re: Inside the WMF Backdoor

Code review vs. Design Review.
Detecting this flaw would be more likely in a security design review. It sounds like (based upon the analysis of the behavior and/or code) that the "feature" is coded as designed.
"Security must be designed in at the beginning" (This is a common statement from every secure coding book or paper you will find.) An insecure design cannot be made secure later on by patching. A secure environment must be designed that way first, implemented that way second, and operated that way third. Take away any of the 3 and you weaken or remove the security.

1/20/2006 9:24:00 AM by Rich

# re: Inside the WMF Backdoor

Has anyone found a .wmf from Microsoft that exploits the hole?

1/20/2006 9:24:00 AM by Anonymous

# re: Inside the WMF Backdoor

After reading and doing more of that i can only but repeat my first question that came to mind ...

How many people in the whole of the world would be able to produce, and especially produce, such an exploit out of the (almost) blue or even grasp the information available to write one and use it accordingly ?

1/20/2006 9:40:00 AM by Joris

# re: Inside the WMF Backdoor

The fact that a vulnerability is so bad that it's mistaken for a backdoor is very telling about the quality of the code coming from Microsoft anyway...

1/20/2006 9:52:00 AM by Anonymous

# re: Inside the WMF Backdoor

Well done Mark.

I hadn't looked into it myself but I suspected that a professional analysis would have revealed as much.

One thing to bear in mind, though is this:
If you were the owner of the biggest software monopoly in the world would you run the risk of leaving evidence of a purposeful backdoor?

P.S. I am lamie. The blogger won't let me identify myself.

Probably not! And I don't think Billy boy would have been that stupid either.

The best backdoors are always those that are designed to look like a perfectly normal programming flaw. And so we will never really know if Billy boy has purposefully introduced backdoors into his system.

Most of us programmers would like to believe he has and we all know why we believe that...

1/20/2006 10:16:00 AM by Anonymous

# re: Inside the WMF Backdoor

quote: ""While anything's possible, it's hard to imagine how a security lapse
of this magnitude (trusting user-written code) could have made its
way into VMS code. The point is that Stephen Toulouse's "the security landscape in the early
1990’s was very different than today" is, well, self-serving. Only in MS's
myoptic view is this the case."" (end quote)

Non sequiteur. VMS was (and is) not even vaguely in the same category as Windows 3.1. VMS was intended from its inception for use on multi-user network-connected systems -- multiple users at the same time, not just at different times like Windows 9x or, for the most part, even Windows XP. DEC systems had been expected normally to have multiple terminals and multiple simultaneous users at _least_ since TOPS-10 and had been commonly networked together with other DEC systems at other sites at least since TOPS-20. This is entirely a different security landscape from DOS, which was expressly not intended to be networked or have multiple simultaneous users. Indeed, it didn't even have multiple simultaneous *processes* in the same sense that VMS and Unix did, and there was no real distinction between kernel-land and user-land at the process level (except as concerns re-entrancy), and any code that could run was in fact permitted to install its own bits and pieces into the ISRs (the equivalent of what we today would call the API). All code, if it was run at all, was totally trusted. Windows, being at that time just a graphical shell, inherited its security environment from DOS. Just because Cusler had worked on VMS formerly does not imply he would think of DOS as a network operating system or Windows as a multi-user environment. It wasn't.

The scary thing is that code and APIs from that era are implemented in XP and, apparently, Vista.

1/20/2006 10:30:00 AM by Jonadab

# re: Inside the WMF Backdoor

Hundreds of thousands of cars and trucks get recalled every year due to design flaws.

Are they all intentional?

No.

They're just design flaws, people.

Get over it and move along please.

Great analysis by you, Mark.

RD

1/20/2006 10:43:00 AM by Anonymous

# re: Inside the WMF Backdoor

Mark,

I agree with your analysis - it seems to just be an exploitable bug, not something intensional.

But I have a question for you - how would you design an intentional back door in Windows? What would distinguish a backdoor from an exploitable bug? Especially because a good backdoor would look exactly like a bug so whoever did it would have plausible deniability.

1/20/2006 10:49:00 AM by Anonymous

# re: Inside the WMF Backdoor

Disappointed. No new information was provided. Only new 'guesses' from a different angel.

I was expecting something from an 'security expert'. Duh! :(

1/20/2006 10:50:00 AM by Anonymous

# re: Inside the WMF Backdoor

Microsoft can produce/reproduce that kind of .wmf file. There is a reason people think this is a backdoor.

1/20/2006 10:52:00 AM by Anonymous

# re: Inside the WMF Backdoor

VMS was not hacked in 1984. It was the BTX system (an application) that was hacked through the standard buffer overflow exploit.

http://www.textfiles.com/news/boh-20f8.txt

I am not aware of any VMS system ever being "0wn3d" without the help of social engineering such as that performed by Kevin Mitnick. Obviously, when the human variables are figured in, any system is vulnerable.

1/20/2006 10:53:00 AM by Stephen Eickhoff

# re: Inside the WMF Backdoor

Another thing. People, if this was such a glaring security hole, why didn't the rest of you guys find it?

You fault Microsoft for not finding it earlier, but I didn't see any of you shouting about it from the rooftops earlier than this.

It's very easy to be a Monday morning quarterback and point fingers at how you would have done things better.

RD

1/20/2006 11:29:00 AM by Anonymous

# re: Inside the WMF Backdoor

Great information. Agreed, I don't think this was intentional and I think much of your analysis proves that.

1/20/2006 11:36:00 AM by hagrin

# re: Inside the WMF Backdoor

My comment is too long to copy here. Here is a link to it on Slashdot: Why no check of user code? Sociology.

1/20/2006 11:39:00 AM by Michael Jennings

# re: Inside the WMF Backdoor

I applaud your analysis of the WMF "problem" and your analysis of Steve's analysis. That said...

Does everyone who thinks Steve is crazy really believe that there aren't any backdoors in Windows XP (or others?)

I don't know about you, but frankly, I assume there's a backdoor in there somewhere. That's closed-source for you. If it isn't this, then it is something else.

Why do you suppose the Chinese (and other governments and militaries) don't want to be beholden to Microsoft and Windows? They fear a backdoor that someone could trigger at an inopportune time, like, say, when the nukes are flying.

The US has a long and glorious history of sabotaging technologies that find their way into foreign landscapes. Remember that Soviet gas pipeline explosion that Norad initially thought was a launch? It was the largest non-nuclear explosion ever detected. It was caused by sabotaged turbine-pump-control software that the US modified to go crazy after a few years of service.

So here's the question. Do you really think Windows doesn't have any backdoors?

1/20/2006 12:19:00 PM by Anonymous

# re: Inside the WMF Backdoor

"Why do you suppose the Chinese (and other governments and militaries) don't want to be beholden to Microsoft and Windows? They fear a backdoor that someone could trigger at an inopportune time, like, say, when the nukes are flying."

Actually, Microsoft has a source-code access program specifically for foreign governments concerned with that and China is one of the participants.

1/20/2006 12:34:00 PM by Anonymous

# re: Inside the WMF Backdoor

The important thing to remember here is that the WMF code was written when windows was a 16 bit cooperative multitasking system. Thus, if I asked a WMF file to be played by opening it, but wanted to present the user with a dialog box with a CANCEL button, there would be no way to process the windows messages (mousedown, mouseup, which then send a WM_COMMAND with IDCANCEL) without some kind of mechanism to periodically process these messages. If a WMF file playing code does not do this internally, then they must provide a way for the calling app to do this (which makes more sense since the caller would want to control the GUI).

The way to fix this as a security issue would have been to check that the address of the callback was not inside the file itself.

BUT...in 16 bit mode this was not necessary, since code and data were in seperate segments.

So, it just a hold-over from 16 bit thinking.

So you are wrong this time Steve.

But SpinRite is still an excellent product.

Jeff Miller, FCDG

1/20/2006 12:37:00 PM by Anonymous

# re: Inside the WMF Backdoor

"Actually, Microsoft has a source-code access program specifically for foreign governments concerned with that and China is one of the participants."

And China is also well aware of the PROMIS software which the US DoJ stole from its creators, the INSLAW company, enhanced by the NSA and has peddled to various agencies here and abroad.

China will never buy into Windows fully because they simply cannot trust a company that has suuch close ties to the US government. How many people associated with Jack Abramoff used to work at Preston Gates, the law firm of Bill's father?

As for this vulnerability, I suspect Steve was indeed jumping the gun to proclaim it a deliberate backdoor based on his one test that required an invalid value to trigger it. Bad data vetting is obviously a more likely explanation for that behavior on the part of the code.

1/20/2006 12:59:00 PM by Anonymous

# re: Inside the WMF Backdoor

Conspiracy or not, what does this say about Microsoft's highly publicized review of all of their code?

Usually it would be a red flag if I saw code which moves the instruction pointer to a memory location inside of a users supplied file's data. Anytime you see PROC in a keyword, such as SetAbortProc, it indicates that the value you are passing in is inside executable code. Its kind of like a big marquee saying "Where did this value come from? Check me for security!"

And when you're reading some bit of code that is interpretting a file, much like a script, this makes it even more disconcerting if you don't think "Hey, I'm switching off a bytecode that is telling me to set a callback...and that callback is coming from the meta file?!?!!?"

I'm with Steve on this one still, even if some of his assumptions turned out to be wrong. I don't see how something so obvious as this would be missed on such a thorough code review.

This is exactly how you would code a backdoor if the NSA asked you to. And that is the only reason I can imagine a file format bug like this being missed in a supposed thorough line by line security review done by a large group of programmers.

1/20/2006 1:22:00 PM by Anonymous

# re: Inside the WMF Backdoor

"Actually, Microsoft has a source-code access program specifically for foreign governments concerned with that and China is one of the participants."

Ah, so they get a makefile and just build their own windows? Every single component? They get a new source update every tuesday when a security patch is released?

I'm really interested in how this program works. I knew there was a program that gave developers access to Windows source, but I was pretty certain that it didn't include all source, and that it wasn't something you could go build a working distribution of all kernel components and DLL's from.

And this is just a guess, but I'd assume they'd restrict access such that you only have it within a Microsoft controlled facility.

Unfortunately, we just don't know. So the statement that they have a program is kind of empty in this context since the details of whether it would prove you are actually running the code you are looking at are missing.

1/20/2006 1:35:00 PM by Anonymous

# re: Inside the WMF Backdoor

The c-word is being used a lot. Like all good conspiracies, we'll never know for sure. We *should* be left guessing. What it all comes down to is trust; that is, would you trust Microsoft - or any other OS - with your private information? In this day and age, the stakes are just too high to take this question lightly.

With cars, you can open the hood and look inside. Software isn't that easy. How much of our infastructure can we afford to relegate to closed-source solutions?

To think that businesses - or governments - aren't interested in what we're doing in private is dangerously naive. They are and they always will be.

1/20/2006 1:38:00 PM by Anonymous

# re: Inside the WMF Backdoor

The flaw Steve Gibson found in Windows was NOT IN WINE. Gibson found( incorrectly ) that an invalid WMF data structure could also activate the WMF vulnerability of executing code found in the WMF file. So Windows source code had two flaws:

1) they allowed execution of code inside a WMF file using the SetAbortProc APIs

2) they allowed an invalid header size value( Steve thought len==1 was the only one ) to also trigger the execution of code inside the WMF file.

WINE coders coded to the Microsoft spec for how WMF files were handled, BUT, they did not handle invalid WMF files like Microsoft did. Go ahead and check for yourself. Download Knoppix and then try running Steve Gibsons test application. Once you set WINE up so the test app is launched with WINE faking to be Windows 2000, the test app will run and say the flaw is NOT THERE.

So even after 15 years of Microsoft being able to see it's own source code and moving this code to each new version of their operating system, they kept moving this obvious coding flaw into each OS. Seems like Bill Gates just gave his people 3 months off when he said they spent that time combing the system for security flaws.

So, Microsoft security reviews don't seem to be working and have not worked for the last 5 years and it could be said they haven't worked for the last 15 years. And WINE coders are better at coding than Microsoft.. :-/

1/20/2006 1:43:00 PM by Anonymous

# re: Inside the WMF Backdoor

Mark,

There may be another explanation for why the developer expected an on-disk copy of the WMF to contain the code.

In today's world of computers with lots of memory we expect our computers to not write to disk very often. However, if you were running Windows 3.1 on a machine with only 1MB of memory, it might have made sense to take a big chunk of one of these "GDI macros", schlepp it out to disk to free up the ram and then load it back in when needed.

So, forget about the long-term storage and reuse of these files where you would need to worry about changing patch-levels or different load locations or sizes for libraries (something the OS should perhaps do randomly at startup anyway to prevent such problems)-- the developer may very well have thought that such a storage scenario would be completely temporary.

For example, Word. You have a document with Clipart in it. You have to render it to screen or to the printer. If the user is scrolling through a part of the document that contains the image you load it up from disk and call the function to render it to screen. If the user continues to scroll down so that the clipart now leaves the page, you may have wanted to abort the rendering since it is no longer needed. So on the next call to your SetAbortProc method you kill the render and write the ClipArt image to a temp file on disk so that you can free up valuable memory space for the next screen-worth of data that you need to render.

It actually sounds like a half-way decent design to me. The only problem is that they needed to make sure that the code was under a different trust-level--a concept not even present in Windows 3.1...

1/20/2006 1:44:00 PM by Sam Wilson

# re: Inside the WMF Backdoor

"In 1992, this vulnerability would simply not have caused the fuss it does today. Of course it would still have been a vulnerability, and had it been pointed out it would have been fixed -- but people would not be up in arms about it."

In 1992, viruses WERE around, and very well COULD have used this vulnerability to exploit their code contained in a WMF file. Perhaps the Internet hadn't been adopted by a wide audience yet, but email certainly was in full swing with those that had PCs (CompuServe, Delphi, GENIE, Prodigy, etc. were very popular). It wouldn't matter if someone received the WMF file as an attachment, or given to someone on diskette, it would have still created a "fuss", believe me.

Therefore, stop making excuses for Microsoft and hold them to it, whether through stupidity, or misdeed, they were, as they still are, lapse in their Q&A department.

1/20/2006 2:26:00 PM by Anonymous

# re: Inside the WMF Backdoor

"Actually, Microsoft has a source-code access program specifically for foreign governments concerned with that and China is one of the participants."

But AFAIK this code is only available read-only using a special browser. You cannot compile it yourself, so you cannot be sure this is the exact code your systems are running.

1/20/2006 2:29:00 PM by Anonymous

# re: Inside the WMF Backdoor

"Actually, Microsoft has a source-code access program specifically for foreign governments concerned with that and China is one of the participants."

But (AFAIK) this code is only available read-only using a special browser. You cannot compile it yourself, so you cannot be sure this is the exact code your systems are running.

1/20/2006 2:29:00 PM by Anonymous

# re: Inside the WMF Backdoor

If they do have a back door, it would be buried a lot deeper than in WMF code.

And so what if they did? If it were exploited for nefarious purposes, it would soon be discovered and we would all soon know about it and then it would be gone. Well, that one anyways. :D

Doesn't matter anyways, since a new OS comes out every few years that will supply all you conspiracy advocates with plenty of fuel for your fertile imaginations. :-P

RD

1/20/2006 2:48:00 PM by Anonymous

# re: Inside the WMF Backdoor

Actually, Microsoft has a source-code access program specifically for foreign governments concerned with that and China is one of the participants.
What I do not understand is how they can be sure, that binary provided by MS match source code? Are they going to build themself? Entire Windows with all tools and drivers? It can't work.

1/20/2006 3:02:00 PM by Anonymous

# re: Inside the WMF Backdoor

How many people in the whole of the world would be able to produce, and especially produce, such an exploit out of the (almost) blue or even grasp the information available to write one and use it accordingly ?

How people knew about it and had a need/desire to use it.

To answer your question you'd have to know the answer to mine.

It wouldn't shock me to find there was close to a 1:1 ratio, unless there are better wide open doors not yet found being used.

And if you know there a good likelihood your enemy will be using a product of yours, you're not going to rely on just one safeguard are you?

Hence the invention of security swiss cheese, brought to you by Microsoft.

You can color it true blue patriotic even in the right distorted light. But in the mean time it's just a good gravy train, enabling a whole hole plugging product economy.

1/20/2006 3:48:00 PM by Anonymous

# re: Inside the WMF Backdoor

"How many people in the whole of the world would be able to produce, and especially produce, such an exploit out of the (almost) blue or even grasp the information available to write one and use it accordingly ?"

How many people knew about it and had a need/desire to use it.

To answer your question you'd have to know the answer to mine.

It wouldn't shock me to find there was close to a 1:1 relationship, unless there are better wide open doors not yet found being used.

And if you know there's a good likelihood your enemy will be using a product of yours, you're not going to rely on just one safeguard are you?

Hence the invention of security swiss cheese, brought to you by Microsoft.

You can color it true blue patriotic even in the right distorted light. But in the mean time it's just a good gravy train, enabling a whole hole plugging product economy.

The context you look at this within shapes the conclusions totally. Look wide eyed at how we act, and pressure, and assure our position at home and abroad. It's more incongruous to think these *aren't* intentional than to think they are.

1/20/2006 3:56:00 PM by Anonymous

# re: Inside the WMF Backdoor

Why is there bashing of Steve Gibson here? If some of you people would READ both Steve's and Mark's analysis, you'll come to find that they both agree! Both conclusions state that this WMF exploit was intentional.

Sheesh. Some people are using Mark's post to discredit and pwn Steve. These guys are on the same side! So stop the bashing and keep to the f*ckin facts.

Great work Mark! ^_^

1/20/2006 4:19:00 PM by Anonymous

# re: Inside the WMF Backdoor

"Why is there bashing of Steve Gibson here? If some of you people would READ both Steve's and Mark's analysis, you'll come to find that they both agree! Both conclusions state that this WMF exploit was intentional."

There is a difference between "intending to provide fully-featured handling of WMF files (so that they as closely as possible match "real" GDI function calls)" and "intending to provide a secret mechanism by which code can be injected into and executed on unsuspecting users' computers".

Gibson claims that it is the latter. It is absolutely clear that the situation is in fact the former. This is why, for example, we see that WINE, in its implementation of the same functions, yields exactly the same behaviour. A point which Gibson consistently fails to understand.

This is an unintended consequence of correctly implementing the functionality; the aim was not to provide a "back door"; it was to provide feature parity between making GDI function calls directly, and streaming them from a WMF file. That is, after all, what WMF files are for; they are a serialization of GDI function calls (very much equivalent to the role PostScript played in NeXTstep and PDF plays in OS X; the difference being that in those cases the display layer was built around the file format, whereas in WMF, the file format is built around the display layer).

Apart from anything else, it can hardly be considered a "back door" when the behaviour is fully documented! A careful reading of the GDI and WMF documentation will state unequivocally that WMF works this way. WMF files can contain a META_ESCAPE record, and META_ESCAPE records can specify abortprocs. MSDN also explains exactly when abortprocs are called (as per the article Mark linked). What kind of a "back door" is documented in such a way?

1/20/2006 4:52:00 PM by DrPizza

# re: Inside the WMF Backdoor

Someone asked "how many people could have found this and done it". Well, everyone who has ever worked here at my little consulting company, for starters -- if you're neither that good or that knowledgable, I'd not hire you, this is easy stuff. Anyone who read the MS dox with malicious intent and was an average or above average c/c++/mfc coder.

Thing is, we were paid to make things work, not break them! And this is exactly MS's original thinking -- why would the owner put malicious code into their machine and break it? They just didn't understand this internet thingie...and still don't.

Example, after hearing about Word's "undocumented" file format, we looked and found it was an "ole storage" which is well documented in the MFC devstudio dox, and wrote a browser for it in about half a day. We wound up using the ole storage thing ourself in some award winning software. It's a neat way to do some things, but yup, I bet some of the "features" are going to wind up as vulnerabilities when someone looks at it with evil intent.

This sort of thing is something MS can't fix without breaking some things, and backward compatability has always been paramount to them. Either they will have to change, and really mean it, or we're in for more -- I now count several "features" that are vulnerabilites that cannot be fixed without breaking MS's and a lot of other people's apps. The pain of change will of course drive more people to OSS, which is where my company has gone already.

Doug Coulter, owner
C-Lab

1/20/2006 5:14:00 PM by Anonymous

# re: Inside the WMF Backdoor

Regardless of the technical arguments, this shows the one thing we all know MS is guilty of:

SLOPPY CODING

1/20/2006 6:32:00 PM by Anonymous

# re: Inside the WMF Backdoor

This Slashdot comment is exactly how I remember the issue: Deliberate Manipulation. Microsoft has a long history of manipulating its code for sneaky purposes, in my opinion.

Also, remember that the U.S. government openly stated its intention to have access to all computers, so that it could supplement its other surveillance methods.

In fact, that intention was achieved through Windows security vulnerabilities. It seems possible, but cannot be proven, that one of the purposes of sloppy Microsoft management of software development is to provide government access to computers.

Here is a link to a comment of mine that develops that point: Why no check of user code? Sociology.

See the quote from United States House of Representatives member Curt Weldon toward the end of the comment.

1/20/2006 6:41:00 PM by Michael Jennings

# re: Inside the WMF Backdoor

Mark, I don't claim to be the expert that either you or Steve Gibson are. I am fans of both and have been for many years.

But there is one flaw in your argument that even I can spot. You stated, about the ability to run code inline with the SetAbortProc:

The actual reason is lost with the original developer of the API, but my guess is that he or she was being as flexible as possible.

That defines a back door. Code put in place by a developer that is not documented in the requirements or specifications!

This may not be a back door intentionally placed by Microsoft, but it smells awfully much like a backdoor put in intentionally by someone at Microsoft.

1/20/2006 7:43:00 PM by Dale Preston

# re: Inside the WMF Backdoor

Dale - the key thing here is that this exploit is in ancient code (3.1 timeframe). Ancient. We're talking pre-winsock - at an era when Windows barely had networking support.

Sure, it looks malicious nearly 15 years later, in an Internet connected world. But when 3.1 came out?

Never attribute to malice what can be explained by stupidity. Or in this case a lack of foresite (or the ability to predict an interconnected future for Windows and what this bad design would mean).

It isn't a backdoor if it's an accident. A backdoor infers malice. This, if anything, was a very poorly designed wall that has now rotted through.

1/20/2006 8:43:00 PM by Anonymous

# re: Inside the WMF Backdoor

To me what's telling is that WINE, which I guess would have re-implemented the API from the WMF documentation, rather than Microsft source code, has a similar vulerability in it. That must mean that this "feature" is not a back door but a design flaw in the WMF specification. Unless the WINE team reverse engineeered and essentially copied the rendering routines from original Windows code this "backdoor" would not exist within WINE.

1/20/2006 10:18:00 PM by nz web host

# re: Inside the WMF Backdoor

This isn't the first time that Steve Gibson has been off his rocker:

http://www.theregister.co.uk/2001/06/25/steve_gibson_really_is_off/

The problem with all software is no matter what you can do you can not catch all the bugs. Software would never get released if you kept looking for bugs and security risks.

You eventually need to release your software to the masses and let them find the bugs. In a perfect world that wouldn't happen.

Windows XP's source code is estimated at 45 million lines of code. How long does it take to check 45 million lines of code? I believe there were at least 1000 developers working on Windows 2000's source code submitting code everyday for 3 years.

1/20/2006 10:21:00 PM by Adam Leinss

# re: Inside the WMF Backdoor

Mark,

I think you need to turn on comment moderation in your posts. This is turning out to be another slashdot-type forum. Most of the comments are "me too" posts with people having no idea what they are talking about.

1/20/2006 10:47:00 PM by Anonymous

# re: Inside the WMF Backdoor

Yeah, I agree.

1/21/2006 1:01:00 AM by Anonymous

# re: Inside the WMF Backdoor

The words storm and teacup fit somewhere I am sure ;)

I love conspiracy theories. Particularly when they are within the realms of possibility. There will always be question marks over bugs like this in closed source software.

If you think about the age of the original flaw (15+ years), and you use the security mindset MS had back then, it should not surprise. Yes, someone should have picked up the bug when the particular code was brought into the new tree. But if MS really wanted to drop a backdoor in, then surely the windowsupdate feature would be a much better place to start.

That does not excuse MS for this bug, but there was no 0 day sky is falling worm that infected half the world before a patch could be released.

The million dollar question (probably several billion dollars actually) is that if MS did open source windows, would the security landscape improve or deteriorate?

Adam

1/21/2006 4:45:00 AM by Anonymous

# re: Inside the WMF Backdoor

Thank you for that informative response DP. What I've been hearing was that there was no documentation on the handling of this "specific" action, and that this was added after Windows ME; thus giving the speculation that the previous o/s before 2k are not seriously vunerable; except of Nt if it has a wmf handler display program assigned to it.

1/21/2006 7:18:00 AM by Anonymous

# re: Inside the WMF Backdoor

Nice article, thanks!

You list 4 items as to why Steve asserted this was a deliberate backdoor, but in fact Steve was only basing this assertion on ietm 3; items 1 and 2 fit MS's "by design" and while item 4 creates a back door exploit opportunity by design, this in itself doesn't prove perfidity rather than stupidity.

If I were Steve, I'd have disassembled the handler to look for evidence that item 3 was due to deliberate parsing for that "hook" value. Without that smoking gun, I'd not have made those accusations. Your explanation accounts for 3, and so I agree this was probably stupidity rather than perfidity.

The "security landscape" of 1995 should have made the risks of silently running raw code in "data files" manifestly obvious. Win95 was the first MS OS with built-in Internet connectivity; viruses were already rife, and Concept demonstrated the folly of auto-running macros in "data files" in the same year.

Perhaps that's why Win95's WMF is harder to exploit than NT, given that NT peeled off DOS before 1995?

Actually, we are still waiting for MS to catch up with the "security landscape" of 1995. We still have no visible and trustable distinction between "data" and "code" files, and even Vista still hides file name extensions and trusts hidden info within the file to decide how it should be "opened" even when this is at odds with the file name extension.

As it is, Concept should have prompted a security review that should have killed off auto-running macros, extension spoofing opportunities, raw code in WMF "data" files etc. by Win95 SP1.

Instead, we had documentation that called Concept a "prank macro" rather than a virus, and a tool that specifically killed Concept, as if no other macro malware would ever be written.

And then IE4/Win98 went on to leverage HTML as a system-wide generic "rich text" medium, complete with auto-running scripts, ActiveX, Java, etc.

I can understand how some folks can't fit this level of implication blindness and decades of OS development experience into the same box, without fears that these safety failures are a deliberate mechanism to maintain user exploitability.

1/21/2006 8:17:00 AM by Chris Quirke

# re: Inside the WMF Backdoor

This discussion mentions government-level access to source code as a means to exclude the presence of backdoors, etc.

That would be meaningful if this were the source code one was actually running. After a single monthly update, this is no longer the case - unless these governments get source code of every patch as it comes out?

1/21/2006 8:20:00 AM by Chris Quirke

# re: Inside the WMF Backdoor

Having the kernel trust user-written code in an enterprise-class o/s,
be it VMS or Windows NT or Unix or whatever is an accident just waiting
to happen. It matters not what vector is used to compromise the machine
be that a terminal or a network connection, the base problem is the
existence of that trusting code. Were I the SE who introduced this code
into the source stream, I would want to crawl into the nearest hole.
One thing that could add to the embarrassment would be to have spin
doctor blowing smoke about "the changing security landscape".

Gibson is now claiming that the actual defect (EXECUTION of user code)
was INTRODUCED into the WinNT stream
(http://www.grc.com/sn/SN-023.txt)
and that Win9x users have nothing to fear.

1/21/2006 11:04:00 AM by tc

# re: Inside the WMF Backdoor

Putting code in graphic files? That's totally and utterly stupid and unnecessary - so it must be something Microsoft thought was a good idea.

1/21/2006 11:16:00 AM by Per

# re: Inside the WMF Backdoor

Steve Gibson is self-proclaimed FUD-er, and no "security expert" all. You can view a list of his FUDs here:

http://grcsucks.com/

1/21/2006 11:46:00 AM by Anonymous

# re: Inside the WMF Backdoor

Puhleez, quit with the grc-sux pandering. A few lame e-mails from disgruntled folks, and some links to ... Microsoft? That does not make for a very good independent source. The "sux" in the title should clue you off.

In fact, Gibson _is_ well-respected in the industry, a few of the 'critics' even use his software to debug these security issues, and Guilfanov refers to Gibson's site for his indepth analysis. If he gets the respect of his colleagues in the industry, good 'nuff for me.

Yeah, he's a bit wacky sometimes, but he's doing it for your own good, Slashdot kiddies. Seems like this issue, either you're a Microsoft apologist-fanboy saying - "Poor Microsoft! Get off their case! They are the epitomy of brilliance at security! We are safe!" vs. Gibson and the rest of the security world "Landscape changed? Assembly code too complicated? The meaning of the word 'critical' vulnerability? Intentional, but not a backdoor?" and say "Huh?"

1/21/2006 11:21:00 PM by Anonymous

# re: Inside the WMF Backdoor

Nice article, you addressed well the first three Gibson's observation, but I think as well that you didn't put the definitive word on the fourth issue, "Windows executes code embedded within the SetAbortProc record rather than expect the record to reference a procedure within the application executing the WMF file".
Gibson somehow, and stuttering and slurring his speech :-), finally admitted in this week's blog that on most things he was wrong or at least too hasty, but the 4th argument still stands there.
Sure, Microsoft position is now less tricky, but the fact remains that about the unresolved issues the interpretation is still open and is absolutely justified to range between Gibson's perhaps excessive malevolence about Microsoft's aims and your perhaps excessive benevolence.

1/22/2006 4:49:00 AM by Anonymous

# re: Inside the WMF Backdoor

Aren't we all a "holier than thou" bunch. Might be an idea for a lot of people here to have a look at code they wrote 10-15 years ago and and then ask the question "would I do it that way again ?" (I have done this and even asked myself why the hell I did that). Times change, knowledge changes, environment changes. There will always be someone to take advantage of this

1/22/2006 8:18:00 PM by Anonymous

# re: Inside the WMF Backdoor

The original design means of writing data into a Windows metafile is the execution of graphics commands within a device context to which it is attached; this will output to the metafile data identifying the graphics commands in question.

Will a SetAbortProc() call to a device context that's attached to a metafile produce a SetAbortProc() record? If so, how will Windows decide what code to put there? And if not, why is Windows decoding a record that should not exist?

Based upon my understanding of SetAbortProc() it would seem like it would be bound to the application doing the drawing much more than to the material being drawn. For example, if a metafile is being printed, the abortproc() would check to see if the print job had been canceled; if it's being shown in a clipboard viewer, the abortproc() might check to see if (among other things) the window has been resized. The same metafile should thus have a different abortproc() depending upon what's being done with it. So what was the design purpose of embedding SetAbortProc() anyway?

1/23/2006 1:20:00 AM by supercat

# re: Inside the WMF Backdoor

Quote" Gibson somehow, and stuttering and slurring his speech :-)"

I bet Gibson's programming skill is a lot better than you can do.

I'm not for or against anyone, but will you please look at the issues? I'm glad that someone (some nutbag like Gibson) pointed out there *is* a potential security problem than knowing nothing about it and then get attacked by those malicious people. Mark is another expert to clarify out of something that he's good at. So they both are doing something good.

So, please shut your mouth if not being constructive in the computing industry. You're not worth it.

1/23/2006 11:01:00 AM by Anonymous

# re: Inside the WMF Backdoor

I thank Mark for investigating this issue professionally instead of taking the Microsoft-bashing approach that Steve Gibson seems to do consistantly these days.

Microsoft may not be benevolent, but these days its important to differentiate logically between intentional-backdoors and remnants of days gone by where things worked differently.

WMF is one of the few technologies that has been stagnating around for a long time, and its clear from Mark's analysis that the it's close ties to the GDI are the root of this exploit, and nothing more.

It seems pretty clear to me that there is a big difference between this oversight, and something intentionally unleashed on the public such as the Sony Rootkit.

Steve's final 15-seconds of fame are up. I guess Microsoft's DotNet approach to the future really gets Steve's hackles up; After all, everything he develops is written in "100% pure assembler" which is clearly superior to some interpreted java-like abomination.

Steve's credibility has been waning with every outburst he's made since the (very informative at the time) paper on browser spyware, and his bleeding-edge spyware detector and remover. Great spyware products have since evolved from that.

I lost a lot of respect for him after the whole winsock TCP socket witchhunt where he proclaimed that the world would become full of DDoS clients as a result of this functionality being included in Windows XP and Windows 2003. I'm still wating for the "big one" that takes out the whole internet.

I can definitely tell from the comments posted here that there still are a few die hard Steve Gibson fans who see conspiracy whereever Steve points his finger. I hope those individuals eventually see the light.

1/23/2006 12:16:00 PM by Anonymous

# re: Inside the WMF Backdoor

Quote:

"I bet Gibson's programming skill
is a lot better than you can do."
You are certanly right about this, but I think you didn't understand what I wrote.

Quote:
"I'm not for or against anyone, but
will you please look at the issues?
I'm glad that someone (some nutbag
like Gibson) pointed out there *is*
a potential security problem than
knowing nothing about it and then
get attacked by those malicious
people. Mark is another expert to
clarify out of something that he's
good at. So they both are doing
something good."
I never denied the merits of Gibson and Mark, just pointing out that Gibson checked some of his previous observations and findings and fairly corrected some conclusions, but it should be fair to admit that Gibson's fourth issue (as listed by Mark, I don't remember whether Gibson lists them in the same way) is still valid.
Gibson has done a wonderful job analyzing and quickly writing the vulnerability check utility, the only thing arguable could be the conclusions about the intentionality of the backdoor or whatever it is.
And about this the issue is still open, IMHO, because some very important observation of Gibson are not been proven wrong and about them we can't really say whether Gibson or Russinovich is right or wrong or if there has been some other reason that's neither the backdoor nor a plain error.
But all this reasoning doesn't deny in any way the objective benefit that Gibson's, Russinovich's and others' researches do for our security, I was writing only about the issue of the motives behind the suspected backdoor.
By the way, Mark has been much more earnest in his answer to Gibson than MS, as he tried to confront the strongest point in favour of Gibson's thesis, while MS quite avoided it.

Quote:
"So, please shut your mouth if not
being constructive in the computing
industry. You're not worth it."
Well, I really don't think I wasn't constructive.
And I won't shut my mouth whatever you say, you can bet.

1/23/2006 7:45:00 PM by Anonymous

# re: Inside the WMF Backdoor

"The scary thing is that code and APIs from that era are implemented in XP and, apparently, Vista.".....

That is one of the best points I've seen written here about this issue. Microsoft stated "the landscape has changed". So - why is ancient code from the 16-bit, pre-WWW era still a part of current (and soon-to-be-released) operating Systems? The code might not be 16-bit anymore, but as it's been ported into each new O/S, the original function/feature set was apparently never scrutinized for all possible uses/abuses as the landscape was changing. How many other remnants from out-dated landscape days are there slated to be ported unscrutinized and unchange (from a function and security persective) into Vista? From a security perspective, the landscape and dramatically changed. Sure it would take a while, but isn't about time MS designs and codes an O/S from the ground up - with heavy consideration toward security? I'd really like to see that, but I'm not holding my breath! You would think MS would get a little tired of constantly being one or two steps behind zero-day exploits ravaging them and their customer base.

1/24/2006 4:24:00 AM by Anonymous

# re: Inside the WMF Backdoor

"
I lost a lot of respect for him after the whole winsock TCP socket witchhunt where he proclaimed that the world would become full of DDoS clients as a result of this functionality being included in Windows XP and Windows 2003. I'm still wating for the "big one" that takes out the whole internet."

Have you noticed that the world is full of DDOS clients!

davcefai AT keyworld DOT net

1/25/2006 6:22:00 AM by Anonymous

# re: Inside the WMF Backdoor

How can people even read Steve Gibson. Steve Gibson is a JOKER. A self claimed security expert with NO KNOWLEDGE. He is not even ashamed of being a porpagandist. I mean hello, RAW SOCKET is a big security threat, blah blah. What he should have said was, Don't make all users Admin on Windows XP Home. Instead he kept giving stupid examples of how closing RAW sockets will close security hole of XP Home. I mean, even if you close RAW socket, i can use ndisuio to do user mode network IO using ReadFile/WriteFile and send spoofed ethernet packets.

I sincerely wish people in industry put Steve Gibson on permanent ignore. He is such a FUDist and he is not even ashamed of himself. Sometime read his resume and you will know what i am talking about. And i bet, he will never come to places like bugtraq or conferences like black hat, because those people will not even like to talk to this moron charlan.

1/25/2006 11:33:00 AM by Anonymous

# re: Inside the WMF Backdoor

To "holier than thou"

If Microsoft has programmers that code like I did 10-15 years ago, they better have someone who codes like I do today checking over all their code.

The main difference between your code of 10-15 years ago and Microsoft's, is Microsoft's already ran on the vast majority of PC's, and should be expected to have undergone a more rigorous review process than what you could be expected to perform.

1/26/2006 8:58:00 AM by Anonymous

# re: Inside the WMF Backdoor

1. Gibson is a pathetic overblown hack. Everyone who is anyone in the scene knows that. Anyone who actually goes to security conferences and actually codes/reverse engineers/hacks for a living knows that. Mark Russinovich undoubtedly knows that (he just can't very well come out and call him an idiot in public, now can he? how professional would that be?). Just read the clueless way in which he analyses the whole thing from the beginning, for christ's sake! Unprofessional, unknowledgeable yet knows enough to be dangerous. You just don't publish something saying "Microsoft implemented an intentional backdoor" (even if it might perfectly well be true) without at least looking at the goddamn code disassembly, people! You don't make such a claim without something to back it up, certainly not with only a "well I tried putting a 1 here with a hexeditor and it borked omgwtf!!oneone".

2. Regardless of Gibson's idiocy, the issue at hand is very grave indeed. First of all, to those saying "oh poor little Microsoft, no one knew better 15 years ago", EVEN if that were true (please... don't judge the world by MS), we are not in 1990 anymore. Sorry, "this is a 15 year old bug" doesn't fly when it's present in every single OS after NT 4, and including the all-new blowhorn Vista crap.

3. Funny how the supposed old bug isn't present in Win9x, then it's present in Win2000 again.

4. To the idiot who said "it's easy to criticise now, none of you found this bug in the past 10 years and now you criticise MS" Maybe because Windows is closed source, idiot. Maybe because MS has access to its own source code (duh), and hardly anyone else does. And even then, it took someone other than MS to find the problem, who incidentally was able to do so whithout the benefit of having Windows source code.

5. To the other idiot who said "how many people can do this" - go google up on metasploit+framework. It's here, now. It's on the wild, and it's been ever since it was publicized. See this video if you don't believe me: http://www.websensesecuritylabs.com/images/alerts/wmf-movie.wmv (the video itself is safe, you're not infected if you look at it, it's a WMV file, not a WMF one). It's a video of a computer getting infected by simply going to a site.

6. Mark is a real security professional. Ilfak is a real security professional. Gibson is not. I cannot stress this enough. Gibson is to Russinovich as that kid in school that likes to make all the other kids believe he's "teh uber leet haxor omgomgomg" would be to M3DU54 (google him up, THAT's a real knowledgeable guy).

7. Gibson managed to supposedly "invent" what had been invented years before by the Linux community (the whole "SYN cookies" thing). Even then, he got it wrong: his design is flawed and does not address all the problems that the Linux design does.

8. Better not say anything more about Gibson, I'm afraid he will launch his 147% hand-made assembly nanoprobes at me, penetrate the phased neutrino shields in my computer, and subatomically transform it into a toaster set to reprogram my DNA.

Please...

1/26/2006 8:27:00 PM by Anonymous

# re: Inside the WMF Backdoor

all this talk about a back-door/conspiracy is a total waste of good oxygen since it will always be in the realm of plausible deniability. USING a back-door is the real issue.

i myself doubt it very seriously since truth is an absolute reality and human beings are NOT very good at holding a lie together, what with not being able to change or control reality.

thus, using a back door is a HUGE risk on the part of microsoft. if they were ever caught, microsoft, as big as it is, would fall as hard and as fast as the world trade center.

what would you do if there was irrefutable evidence that msoft used a back door?

i myself would become an INSTANT linux/mac convert.

trust is a REAL and PRECIOUS commodity in the business world. so i vote with Napolean - it's a screwup.

2/2/2006 10:44:00 AM by Anonymous

# re: Inside the WMF Backdoor

Perhaps a stupid question, if every application dealing with WMF files can set AbortProc() and if you say save WMF using one application and then display it and print it with another, which AbortProc() gets executed?

2/2/2006 10:52:00 PM by Igor

# re: Inside the WMF Backdoor

RAW Sockets was taken out of Windows, not to annoy Grandma looking at photos that Little Johnny emailed to her on her 75th birthday...so the "just don't run as admin or equivalent" is a pointless argument...

...it was taken out because of the "hackers" WOULD run as an admin, so they can exploit RAW Sockets...

Wake up and realise that 90% of the computers on this planet run Microsoft Windows, whether we like it or not.

The average script kiddie using this exploit won't be running Linux, because "mummy" or "daddy" won't let them blow windows off the family computer, and run linux.

Not everyone is a geek like us, and has more than one computer.

Steve Gibson sticks up for the average Joe Schmo computer user - I doubt he even expects or thinks that us "tech savvy" people would be dumb enough...

2/2/2006 11:04:00 PM by Michael Wyres

# re: Inside the WMF Backdoor

I thought Vista was supposed to use DirectX completely rather than any GDI graphics stuff?

Why was this GDI-related exploit in Vista, and why was it fixed in the 9x line and then later broken?

Does MS really prevent programmers moving around that much, or did they just fire the knowledgible ones that fixed in the 9x line?

2/2/2006 11:32:00 PM by Anonymous

# re: Inside the WMF Backdoor

Ok, I understand the explanation that Win98 is not vulnerable because in Win98 this is an Application vulnerability, and that WinXP by default includes the extra features as OS functionality.
But I see that IE is not vulnerable because this class of hack is deliberatly disabled.
At what point did they decide that this class of WMF records is too dangerous for IE? Why didn't some bells go off when that decision was made? (david)

2/3/2006 4:11:00 PM by Anonymous

# re: Inside the WMF Backdoor

Guys and Gals think for a second here. When we as normal end users of any OS made the decision to use that OS we decided to accept, either willingly or unwilliningly, any bugs, coding errors, mistakes, etc that are present at the time of our implementing them.

MS products are always full of such problems when they are released. Example, Here we are with SP2 not that old, the security review MS did having been acted on, and a "new" security issue is unvailed.

this will be standard practice as long as the reason for MS to produce their products is economic instead of altruistic. They aren't in this for our best interest, but the best interest of the stock holders. We drive this mentality, you know. We want the next "best ever" product from them yesterday. So, in order to line thier pockets with our own hard earned cash they rush out a product that is less than perfect. We do this tho them based on our "need" to have the experience that computing gives us.

People like Steve and Mark are also not completely altruistic themselves. Their presence is also based on their need for financial flow, one way or another. So get off the conspiracy theories, the poor is me attitudes, and the shame on them mentalities. As long as money is the object of programers, software companies, hardware manufacturers, web designers, and commercial websites such as this one, we will have flawed code, at risk machines, incomplete or buggy OS's, etc, etc etc.

2/3/2006 7:37:00 PM by Anonymous

# re: Inside the WMF Backdoor

Michael Wyres - Wow another one of so called Gibson fan. No wonder people like Gibson are there because people like Michael exist. People who trust Gibson without using their mind or understanding the technical aspects of a problem.

Read again in my post, RAW socket doesn't pose a security thread because on Windows Home machine, everyone is an admin. So once the machine gets infected, you don't need RAW socket access to do spoofing, you can simply use NDISUIO to do spoofing using ReadFile/WriteFile from user mode. So it doesn't matter to a hacker whether Raw socket exist or not.

If you are an admin on an OS, you can do WHATEVER you want. So get over this crap. Don't be stupid and don't let dumbasses like Gibson fool you anymore.

Gibson is a hack, a self proclaimed security expert with knowledge less than a script kiddie.

Read more about gibson at grcsucks.com, it is a good laugh because Charlatan like Gibson needs to be exposed. They are cancer to our society.

2/5/2006 3:11:00 AM by Anonymous

# re: Inside the WMF Backdoor

Raw sockets still exist in windows and will exist because they are not a security threat. Steve Gibson is a crazy old fart. I hope his kids are not in software or they will be ashamed of him.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/tcp_ip_raw_sockets_2.asp

2/5/2006 3:13:00 AM by Anonymous

# re: Inside the WMF Backdoor

Mr Wyres, so you call yourself a geek?

Are you really? You sound the opposite from your last post, if you think the only threat from a hacker running as admin is raw sockets when there are 100s of different methods beside raw sockets to do the same thing if you are an admin.

Search for the following online and you will find ways to do sniffing and spoofing if you are an admin without using raw sockets,
WinPcap,
RawEther,
RawNetIo

So please next time don't insult geeks by calling one yourself. I feel you are Steve Gibson in disguise:p

2/5/2006 3:23:00 AM by Rays of Light

# re: Inside the WMF Backdoor

Bit of luck windows still does have the facility to access raw sockets via winsock... we use that facility in our ecommerce web design solutions.
mind you, that said, we have 40 linux and unix servers and ...er... two windows servers... both of which are behind LINUX firewalls!!

3/12/2006 2:01:00 PM by Anonymous

# re: Inside the WMF Backdoor

Gibson (aka Unknowledgeable Media Whore) is still getting wordage ? I thought we'd all agreed to lock him in his site and not let him out unsupervised.

Seriously. This man is a running joke. He started out with zero credibility and went rapidly downhill with his talk of 'hand assembled nanoprobes' and 'OMG Teh raw packets are gonna get us'

With every sentence he utters the world gets a little dumber.

Okay, now it seems he's actually read some books, had them explained to him, and is starting to write with a *little* bit more sense.

But the truth is, he's got no more credibility in the security scene than my grandma's cat.

Now, can we PLEASE put Steve Gibson back in his cage ? PLEASE ?

--
Anon

4/22/2006 6:15:00 AM by Anonymous

# re: Inside the WMF Backdoor

People by there nature tend to be greedy, corupt and untrustworthy.
All that read this will cry general unpatriotic unfounded comment by me-
Gary Looney(I put My Name) and I add intuitively with response that most also want to believe in the best.
So is it all inocent, I have no idea
but will say power and importants does
not equate to honesty.

7/19/2006 6:44:00 AM by Anonymous

Mark Russinovich’s Blog

Hunting Down and Killing Ransomware

The Case of the Unexplained FTP Connections

Windows Azure Host Updates: Why, When, and How

The Case of the Veeerrry Slow Logons

Inside the WMF Backdoor