The Lesson of WMF

[As a quick heads-up, I'd like to point out that Ilfak Guilfanov, Windows internals expert and one of the developers of IDA Pro, has released an unofficial patch (mirrored at for this issue.]

[UPDATE 01/05: Microsoft has released its update for the WMF vulnerability:]

As a researcher, I’m almost always security-conscious. I keep my standard defense measures up-to-date, and I pay attention when new vulnerability reports appear. One of those new vulnerability reports surfaced at the end of December: the now-infamous Windows Metafile vulnerability.

Reading about the vulnerability, what concerned me most was the lack of realistic workarounds. Indeed, it wasn’t until I had delved deep into the specifics of Windows Metafiles, spent a few minutes writing out a regular expression filter, deployed filters to the endpoint IDS on my PCs, and tested them against as many variants of the WMF exploit as I could find or produce that I was confident in my defensive measures. And all of that had to be done… to avoid the catastrophes that lay in wait if I had so much as viewed the wrong image.

To call the frustration I felt a Windows problem, though, is a mistake. Indeed, the vulnerability was a Windows bug… this time around. I could blame Microsoft for its error. Indeed, I could take advantage of this opportunity to tear at the flesh of Microsoft’s developers for what was essentially an overlooked easter egg in a legacy graphics renderer. I won’t, though, because to do so would be overlooking the far-broader implications of this issue, and it would be a mistake.

Indeed, similar vulnerabilities have affected other applications, both on Windows and on other platforms. Graphics rendering is a complicated task by most standards, and software to do that task has had and will have serious bugs. Gone are the days when avoiding code execution meant not opening suspicious application files. The reality is that most any software is, to some degree, an attack vector. And more likely than not, if your software finds wide deployment, those vectors of attack will eventually be exploited.

However, it is obvious from attempting to deal with this week’s vulnerability that this reality was not what drove the development of quite a few popular software applications. Microsoft’s scramble (and ultimate failure) to find wholly-effective workarounds for the WMF issue is a symptom of a development methodology that stretches far beyond the city limits of Redmond, Washington.

Developers are still holding onto the old clutch of treating graphics, audio, and other “pure” multimedia content formats as “safe”. Since it is still widely held by developers that images are “safe” content, many are baffled by the idea that users would possibly want to disable functionality that is so integral to the experience of the web, and even to some operating systems as a whole.

There are a few exceptions. Mozilla Firefox, in particular, has the all-encompassing “Load Images” option. Outlook and co. now have “Remote Image Blocking” and other privacy features. However, these features (simple add-on changes in some cases) weren’t designed with security in mind at all. In spite of the fact that I was using an e-mail reader which blocked image loading, a recent mailing list post from Larry Seltzer, conveniently enough, rendered an image just fine in my mighty image-busting (non-Microsoft) mail reader.

Had that image been hostile, I would more than likely have been successfully exploited. Granted, I run as a limited user, and I have other mitigators, but the success of it was still disturbing. Needless to say, my mail client now renders its e-mail messages in plain text as opposed to the prior “simple HTML” mode.

Admins during the WMF incident are making similar choices. Risk leaving yourself open to an exploit or force your users back to the internet equivalent of the stone age. The simple workaround of disabling access to metafile images was not so simple. Were workarounds easier to implement in terms of functional breakage, the rate of adoption would be far better. Developers everywhere could learn something from that. The absence of such simple workarounds has admins turning to third-party patches (like the one provided by Windows expert Ilfak Guilfanov [binary mirror]) while Microsoft’s official investigation works to quash the hole.

More emphasis should be placed on allowing users to flip the switch on dangerous functionality (or “safe” functionality that turns out to be dangerous). Not only that, but applications should follow those settings to-the-letter, because doing so will greatly reduce the impact of unforeseen threats. Having the option to temporarily cripple flawed code in absence of a patch prevents users from choosing between the stone age and the repair shop. Most users will risk the latter before they choose the former. I, on the other hand, am waiting to put my tablets away until Microsoft issues its patch.

[UPDATED 1/3: I'd like to take the time to add three fantastic points of reference that have emerged as this issue has unfolded.]

  • The ISC Handler’s Diary ( is full of details. It’s a very informative read if you’re looking to keep track of events related to the vulnerability (new exploits, sites to watch for, etc.)
  • Ilfak Guilfanov’s interim fix which has, thus far, proven exceptionally solid and effective in defusing this issue.
  • Last, might be a surprising reference for me to suggest, but I’m going to suggest it anyway. Microsoft has recently updated its advisory on the issue to include a very detailed summary of its current information and ongoing action regarding this incident. As well as demonstrating that the company understands the urgency of the situation, it makes for very interesting reading, and also details some simple, common-sense steps that average users can take. I, for one, am holding out hope that informative, insightful incident management like this will be a new trend for Microsoft. That would indeed be very positive for most everyone.
  • Blandest

    Try this temporary fix, it worked for me:

  • Blandest
  • Matthew Murphy

    Thanks. I suppose I should list Ilfak’s fix… will do that.

    I suppose it really makes my point that someone ultimately had to resort to hacking DLLs in order to secure this mess.

  • Saint Aardvark

    “demonstrating that [Microsoft] understands the urgency of the situation”…ha.

    I’m with Tom Lston of the ISC on this: MS is downplaying the situation. I got more, and better, information from the ISC and from F-Secure’s blog than I did from MS. The bulletin is a good and necessary step, but it was needed much earlier. I realize I am completely unfamiliar with the Q&A necessary for something like Windows, but as Liston points out:

    somehow, as if by magic, all of this work will wind down at precisely the right moment so that the WMF patch doesn’t have to be released “out of cycle.” How convenient! Especially if you’re wanting to avoid all of that nasty “Microsoft Releases Emergency Patch” publicity.

    I’m already suspicious of MS intentions and motivations; this does nothing to make me trust them. The fact that, as you rightly point out, the problem is in lax attitudes toward “safe” data rather than MS practices does not excuse their slack response to this.

    Sorry…that ended up being a lot more about MS than your post. I appreciate the light you’ve thrown on the subject, and I hope I haven’t added enough heat to obscure that. :-)

  • Pingback: Dinis Cruz @ Owasp .Net Project

  • nodialtone

    I am also hosting this patch until Ilfak Guilfanov can get his site back up.


    Browse to News


  • Matthew Murphy


    Thanks. I’ll post the new link asap to help people out.

    @Saint Aardvark:

    I once agreed with Tom Liston’s sentiment, and I wholly understand it. However, three points:

    1) January 10th is exactly two weeks from the original report

    It’s probable that MSFT has (and is working on ratcheting up) a fixed timeline in the SSIRP for devel/test of fixes in an emergency situation (which this is, even if the media don’t say so). It would be entirely reasonable for that timeline to be at exactly two weeks, which would correspond exactly with Microsoft’s receipt of the issue on December 27th (14 days before the 1/10 release).

    2) January 10th *is* out-of-cycle

    Though the media won’t report it that way, most MS patches are done on a two-month test cycle. MS is (obviously) scrapping the great majority of that to release this on 1/10.

    Yes, I know it’s convenient of them to release on a second-Tuesday, but that *DOES* have some tangible benefit for admins in that the patch will more than likely be applied by a greater number of users.

    If the media reported on the truth of the scenario, they’d report any issue that was being actively exploited was an “Emergency Patch” as Liston puts it. The fact that what is most convenient for MS’ larger customers also causes media downplay is the fault of the media, not MS.

    While MS could be more clear on that publicly, understanding that (from talking with members of MSRC) gives one a more clear view of the situation.

    2) Too Little, Too Late

    I agree. You’ll see that I made absolutely no mention of the advisory until it was updated, at which point I also updated my blog. :-)

    I agree that it’s late, but my attitude is, better late than never. Microsoft used to have *no policy what-so-ever* of acknowledging vulnerability reports pre-patch. Indeed, its advisories of late have still looked like SGI’s “we acknowledge seeing this report” messages. As if to say “Yeah, okay, we heard…”

    This is, IMO, a first-step away from that. Even though it’s not enough to totally satisfy me and it’s a little too late for me to really like it, I’d be pleased to see more advisories like this over the boilerplate statements of most previous ones.

    I don’t know that it makes me “trust” them (I don’t trust anyone who has my money), but it helps me to know that a) they’re taking action, and b) when I can expect the patch. That helps me a lot, too, in terms of gauging the necessity of interim workarounds (i.e., are they patching tomorrow or in a month and a half?)

    Remember, MSFT used to take two months or so to handle things like this. Now it’s down to two weeks. It’s still an improvement, even though we’d all like to see it in two days (or less).

  • Saint Aardvark

    Fair points, all of them. As I said, I’m suspicious of MS, and that colours my perceptions — sometimes unfairly. Thanks again for the light you’ve shed on all of this.

  • Pingback: Procrastination, delivered! » Microsoft WMF Vulnerability - Patch Conundrum