Knowing When To Run: Cutting Loose From The Little Blue E

Microsoft surprised us all this week (or maybe not) by releasing a patch for a vulnerability in Font Installation that is, once again, exploitable courtesy of Internet Explorer. In this post, I explore the problematic lack of efficiency in Microsoft’s handling of Internet Explorer issues, and how that inefficiency has helped contribute to the insecurity of the browser.

Read More

The Big Bad Empire: Putting Old Code to Bed

Even more shocking to me than all of the recent FUD and misinformation about the WMF bug, and the seemingly-reputable sources it came from (who should’ve known better), is the level of Microsoft-bashing still going on. This time, it’s apparently convenient to nip at Microsoft’s heels because it’s not providing patches for free for users of its six-year-old and eight-year-old extended-lifecycle OSes.

Read More

Digital Mind-Reading: How NOT To Handle Reduced-Privilege Environments

Current approaches to reducing privilege in the desktop world take the technically wrong-headed approach of creating user accounts with huge levels of privilege, and then simultaneously using these accounts to run tasks with limited privilege. The line isn’t at all clear. This effectively forces your computer to become a mind-reader everytime you log on. Suffice it to say, the accuracy is none too impressive…

Read More

Interview: Ilfak Guilfanov

Seeking to put some of the confusion about the recent Windows Metafile vulnerability to rest, I interviewed one of the most reliable sources of information on the bug: Ilfak Guilfanov. In addition to discussing the temporary patch he authored, Ilfak offers valuable guidance and accurate information on a more general level for those dealing with this vulnerability.

Read More

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.