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 iatechconsulting.com) for this issue.]
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 (isc.sans.org) 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.