Conscientious Risk Management and WMF

This past week there have been a lot of questions about the WMF vulnerability, what Microsoft is doing, and what the community should do to protect against it. For many reasons, Microsoft's response to the problem is best left to those who do this for a living. However, there is a lot of interest in the community for ways to protect against the problem until an official patch is available. Obviously, a patch is the best protection there is, but until there is one, and until we can get it applied, do we just watch our systems melt around us? I cannot speak for Microsoft and this blog post is a purely personal opinion piece, not a Microsoft statement. However, I think this is just another risk management problem.

Let's look for just a minute at the vulnerability itself. It exploits a little-known function in Windows Meta Files (WMF). Those files are used for, well, I don't know really. I think they are mostly used for clipart in Office. In any case, the exploit involves a file with special commands in it, which would be rendered by shimgvw.dll acting on behalf of the user. The exploit requires user interaction, such as surfing to a web site hosting an image that exploits the problem, viewing an e-mail with an embedded such image in an e-mail program that shows those images (Outlook 2003 does not do so automatically), or opening an image as a file attachment. Of course, the usual "security researchers" are publishing canned versions, metasploit versions, and all other manner of sample exploits to make it possible for even criminals who barely know how to use a computer to exploit this issue.

There are many different exploits of this by now. They are currently in active use to install spyware, according to SANS.

Protecting Yourself

A number of protective measures do exist. They include the usual measures as well as a few unique ones.

Surf in an unprivileged context
Simply surfing the web as a non-administrator will go a long way toward protecting yourself. The obvious way to do this is to make your user account something other than an administrator. You really should do that anyway. However, even if you cannot be a regular user (all of us can, strictly speaking, but it is inconvenient), use the Restricted Tokens functionality in Windows XP Service Pack 2 to surf unprivileged. A really simple way to do that is to use the Run As functionality. Right-click the icon you use to launch Internet Explorer (or whatever browser you use) and select Run As. When you do you get this dialog.

If you select the "Protect my computer and data from unauthorized program activity" checkbox you will get a restricted security token and the browser will basically be a regular user. The damage it can cause is therefore that of a regular user. Of course, this is nowhere near as good as running as an regular user, but at least it goes some way toward surfing with protection.

Obviously, your users will never do this on their own. You can do it for them though. Right-click the icons they use to launch their browser, and select the Advanced button on the Shortcut page. Click the "Run with different credentials" box and click OK twice. Now distribute this icon and make sure it is the easy way for them to launch the browser. They will naturally, as users tend to do, click "OK" on the first dialog pops up, which will automatically give them a restricted token. Here is how that looks:

If you want to verify that this works, use Aaron Margosis most excellent PrivBar toolbar for IE. I find it a handy measure to ensure that I am browsing in the right context. There are some things that do not work properly in this context, like the MSN toolbar, but I find that a small price to pay. Another annoyance is that none of your settings for IE work when you run restricted. Finally, it does not seem to work at all on a domain-joined system that is not connected to the domain.

How and where does this help? Using a restricted account is good security practice no matter what. It will contain the exploit to only information that the restricted user has access to and makes it a lot harder escalate the exploit to other systems. In addition, it means that it is very difficult for the attacker to rootkit the system through this type of exploit since the user does not have access to install anything. However, surfing restricted will not stop the exploit. It just makes it somewhat less bad. If the user has access to sensitive information, so do the criminals. That means that while all my users are running restricted, as do I most of the time, I do more than that to protect them.

Block the Exploit At The Gateway
The next possible preventive measure is to attempt to block the exploit. I showed last week how to block file extensions in ISA server and Susan showed how to do it on the mail server if you have SBS. If you do not have SBS, the process is a bit more complicated, but you can still do it.

Blocking the files at the gateway is a great idea. It stops the exploit somewhere where the exploit has no control. If you try to stop the exploit at the user level, the user has the ability to override the protection as long as there is a compelling enough reason to do so. As we all know, promises of huge sums of money, chocolate, or naked dancing pigs, is far more important than security to most users. Given the tradeoff between the two, security stands no chance. With extension blocking the user has no control over the protection and therefore cannot override it very easily.

Of course, there is a downside. According to Security Focus, there is now a handy exploit kit that produces exploits that do not use the WMF file extension. That means that blocking only WMF files does not stop all exploits. It only stops those we know about right now that use WMF extensions. This works because the system is written to be smart about file contents. If the file extension says it is a JPG file, but the content says it is WMF, then clearly someone must have made a mistake and they really wanted the file parsed as WMF so it will go ahead and do so. Unfortunately, we live in a file extension oriented world, but the components are written assuming that file-extensions are unreliable. Protective measures are still file extension oriented though. Therefore, blocking files based on extensions is useful, but not complete protection. To be fully protected you would need to block all the file types that can be used, which may include  EMF, GIF, JPG (and friends), Paint, PJPG, PNG, TIF, WMF, and possibly others as well. Of course, you can block all of those as well, but now we are really making web browsing painful. A better option would be to have a smart file parser at the gateway which can determine based on the contents of the file what it is. If you have a Network-Based Intrusion Detection System, this would be a really good time to get the manual out and figure out how to block WMF files based on content.

The question then is, should you use file blocking? Personally, I have blocked WMF and EMF files. I have not gone so far as to block JPG and the others yet. I probably will not do so as I believe (hope) that the sites my users go to will not be hosting the exploit. They are typically only surfing a few different sites and that limits exposure. Had my exposure been different, the value of the information I protect been higher, my legal requirements to provide protection been firmer, or my risk tolerance been lower, I probably would have blocked all of them. It really comes down to risk management, and there is no right answer here. You have to judge your risk, your requirements, and your tolerance for risk. The cure here is to block all these file extensions. The cost of actually doing so is low, but the side-effects are large. The potential risk is variable depending on the environments. You end up with a risk management formula that looks something like this:

RiskOfAttack*CostOfAttack - CostOfCure - CostOfSideEffects*RiskOfSideEffects = RiskCoefficient

Obviously, this is entirely abstract, but if the calculated risk coefficient is positive, and greater than your risk tolerance, then you would implement the protection. In my case, the risk coefficient is negative for this particular preventive measure meaning that the cost of the side effects of the cure are greater than the risk itself. In your case, that may not be the case.

De-Register the DLLinvoked
The official Microsoft work-around is to de-register the shimgvw.dll file so that it does not get invoked at all. This does stop the attack since the vulnerable component is no longer used. However, the cost of implementing the prevention is high since it requires the action to be taken on every single machine. If you have an Enterprise Management System (EMS) that would not be too difficult, but still takes some work. If you do not you have to either run to every system and run the regsvr32 /u %windir%\system32\shimgvw.dll command. Then when the crisis is over you have to run back to every system and do basically the same thing. Each operation takes a reboot.

There is one other problem with this protection. In order to unregister the DLL you have to be an administrator. I can see a lot of people that would put a logon script together that would unregister the DLL. Then I see a web page that says "in order to see the naked dancing pigs on this page you must first run this component. Please click here first..." and a link to a cmd file with regsvr32 shimgvw.dll. You see, users can undo any protective measure you put in place as the user.

The potential value of de-registering the DLL is high if the user is not an administrator. If the user is an administrator, it is negligible. The side-effect is moderate. It only stops the Windows Picture and Fax Viewer, which breaks the filmstrip mode in Windows Explorer and viewing any file type that is registered to that component, which is all of the ones listed above. You can, however, still surf the web and see pictures there. This highlights an important point, there are usually more than one way to skin any particular cat. Any component that explicitly loads shimgvw.dll is not protected. I do not know of any such components, but since the DLL is still there it is foolish to think that there is not something that loads it. Couple that with a high cost of implementation and you find that either your risk of attack or your cost of attack, or both, has to be extremely high to go this far. It is a valuable protective measure in some environments, but certainly not in all. Personally, I have used this measure on one machine where I have to be an administrator.

Up to date Anti-Malware
The old standby of keeping your anti-malware (anti-virus, anti-spyware, anti-rootkit, anti-whateverthecurrentfadistoday) up to date is of course also recommended. Doing so will block known exploits, but not unknown ones. The anti-malware crowd are working overtime on this one to keep their signatures up to date, but eventually, signatures will fail. I think of anti-malware as antibiotics. Sure, I like them, and sure, they prevent infection, but eventually the pathogens become resistant, and at that point there is no cure. It is a case of leapfrogging. We leapfrog the criminals, then the criminals leapfrog us. Then we leapfrog the criminals, and they leapfrog us. We have been doing so for 20 years or more, and we are still fighting the same battles.

Note that I am not saying not to use anti-malware. You definitely should use it. It is a nice safety net. Just do not become overly reliant on it. The time will come when an exploit is not stopped by anti-malware. Do not fall into the trap of thinking that just because you have anti-malware you can stop being vigilant.

Unofficial Patch
Finally, there is an unofficial patch. Patch really is the right terminology for this. It patches (using basic rootkit technology) a system DLL to ignore calls to the vulnerable function. The patch is an executable and has to be run on each vulnerable system, meaning cost of implementation is potentially very high. According to SANS, it does stop the current exploits. Personally, I have not tested it, and I have no intention of using an unofficial patch at this time.

Again, it is risk management. If you have extremely high security requirements, you may want to go so far as using something as drastic as an unofficial patch. However, in that situation you are probably not willing to trust a third-party packaged patch anyway. The unknown risk of issues with an unofficial patch is pretty high. The cost of implementation ranges from low in a very managed environment, to very high in an unmanaged environment. If your risk and the cost of the attack is very high then you may want to consider the unofficial patch, but I cannot in the best conscience recommend it right now.

Hopefully this will help you consider the options. There is no right solution, there is no one-size fits all approach to preventing this problem. Even in a single network there is no a single approach that always works. Some exposed machines deserve more protection than others, as do some users. My point in this post is not to solve the problem for you, but to point out some things you may not have considered yet. If you have, congratulations, you are probably ahead of the game. This, after all, is just another risk management problem.

Comments (21)
  1. Anonymous says:

    The VML vulnerability continues to haunt us. According to SANS the exploit is "spreading,"

  2. "There is one other problem with this protection. In order to unregister the DLL you have to be an administrator. I can see a lot of people that would put a logon script together that would unregister the DLL."

    What about startup scripts within a GPO? 😉

  3. "There is one other problem with this protection. In order to unregister the DLL you have to be an administrator. I can see a lot of people that would put a logon script together that would unregister the DLL."

    What about using a startup script within a GPO? 😉

  4. Matthew Murphy says:

    It might be worth noting that the shimgvw.dll is merely a vector for the vulnerable component and does not, itself, suffer from the vulnerability. The vulnerability lies in gdi32.dll. The unregistration workaround merely addresses the current in-the-wild exploits which load Picture and Fax Viewer to deliver the payload.

    I personally implemented the workaround, but I’m not relying on it, either.

    I run as a non-admin, so I briefly launched a shell as an admin, performed the unregistration and closed it. The implementation would be tighter in a managed setting, where users wouldn’t even *KNOW* an administrative password. Frankly, it’s too dangerous to run as an admin. Restricting high-risk apps is a stutter step, but it needs to be done across-the-board to be most effective.

  5. Strange enough on my disconenct Domain Laptop I can start a restricted IE, however Firefox will not start with it.

    I can however start Firefox as a different user instead of a restricted one. Do you think thats fine, as long as the alternate user has no powerfull system privs?



  6. Marc says:

    i have a question please: why microsoft didn’t anticipated this ? i think they should know the API of WMF and this big big potential hole and now real threat ( WMF SetAbortProc function…tspol_0d6b.asp ) so WHY ?

  7. Alun Jones says:

    Re: third party patches.

    I always have this to say about third-party patches:

    Let me get this straight: in an attempt to prevent unknown and untrusted third-parties from running unknown and untrusted code on your machine, you are going to trust a previously unknown third-party, and trust his unknown code enough to run it on your machine?

    Seems rather a bad bet, to me. I would consider running a third-party patch only if I felt I could trust the honesty, integrity, and ability, of the person who put it together – and even then, I’d worry that they had missed a subtlety of the original code. That can be said, of course, about the person(s) at Microsoft who will make the official patch, to some extent, but I know more about Microsoft’s process behind patching, and that gives me a better idea of what’s going to happen with that patch, and whether I’ll be able to trust it.

    For now, I’ll stick to not visiting pages with interesting graphics, and running as a non-admin.

  8. Alun Jones says:

    Re: Why didn’t Microsoft anticipate this?

    Here’s an allegory:

    I was reading a book the other night, and I stumbled over a sentence that didn’t make any sense. The typesetters had used "their" instead of "there", and as a result, I had to re-read the sentence a couple of times to get its meaning correct.

    Why didn’t the book’s editors anticipate this, or catch it before release? They know the rules of English grammar, and they know the difference between "their" and "there".

    There’s a lot of code in Windows, and it’s written by people. If it could be written by machine, it would be; if it could be analysed by machine, it has been. Sadly, the use of a machine to analyse the code for another machine is known to be an intractable problem (search for "Halting problem" for details), so not all flaws are detectable within finite time by a finite computer using finite memory. Unfortunately, the presence of a particular flaw can be detected within finite time by an interested researcher who picks the right direction to research into.

    Bugs happen. Some bugs are exploitable as security flaws (so are some poor design choices, or even some intentional and good features!), so security flaws will happen.

    Security management must always be a matter of risk management – how much effort are you willing to put in, and how much risk of susceptibility are you willing to accept? Since you can’t get the risk down to 0, you have to balance effort against risk – if you spend all your time addressing risk, you have no time to do the work you intend to do.

  9. Peter says:

    Re: Why didn’t Microsoft anticipate this?

    It is true that bugs happen, but it is also true that MS made a lot of noise about how they put everything on hold a couple of years ago to go through all those lines of code line by line and root out problems.

    Seems like something as basic as this should have been caught.

  10. Alun Jones says:

    What I posted was a simplification – the truth, as ever, is more complexificated.

    "going line by line through code" is not as effective as you might think. Many flaws are spread across hundreds of lines, and expose themselves more readily to discovery by data fuzzing and algorithm guessing attacks than by code review. [Frequently, the big benefit of code review is that you recognise a pattern of design or implementation that can be found automatically, and corrected in-place]

    Code is not static. By the time you’ve reached the end of the complete code review, another year has gone by, and you’re on a different version of the product.

    Bugs – even security bugs – shouldn’t always be fixed immediately even when they are found. A fix that requires a reboot, and whose analysis would allow an attacker to reverse-engineer the fix to discover the flaw, would be dangerous to ship – if only a few administrators installed it, but a lot of worms were written to exploit it, thanks to new information provided in the fix. The best strategy in such cases is often to wait until the next time the code is updated for other reasons, and provide the fix there, where it is not possible to reverse engineer, and where it will be installed on the most machines [after all, administrators can offer users a new feature in exchange for a reboot, rather than "it works the same as before, but you won’t be vulnerable to attacks that we weren’t seeing anyway".

    Next, of course, you have no idea how "basic" this vulnerability is. I’ve worked on adding code annotations to aid in automated discovery of buffer overflows, and I can confirm that the automatic discovery of buffer overflows is a "hard" problem. Let’s say it takes N seconds to track a buffer overflow in a non-branching section of code of a certain length. Add the ability to branch, or to call a subroutine with a buffer that might get overflowed, and the time to scan approaches 2^N. That’s with one level of branching / calling. The progression is exponential – at each level of function depth, you increase the number that you raise to the power of N. Just automatically searching for buffer overflows quickly takes longer than the lifetime of the universe, let alone the length of a product release cycle.

    Finally, engineers – even those that work at Microsoft – are human, and miss even the obvious from time to time. That’s why the process of security review is cyclic.

  11. Weese says:

    A problem I encountered when running IE with the check box ticked for "Protect my computer and data from unauthorised program activity" is that I cannot view https sites. i.e

    Running on WXP SP2 with all updates till Dec 2005.

  12. Tzim says:

    And what about DEP (Data Execution Prevention) ? I heard it could stop the exploits of this particular flaws among others… or is it only for Hardware DEP ?

    I personaly use DEP on optout mode. Isn’t this what everyone should use ? And why the setting isn’t part of the security center ?

  13. Jordan says:

    For those doubting the reliability and security of the third-party patch, I’d like to reiterate the comments made by the SANS folks. The patch is not only simple and transparent in its design, but it’s possible to verify it by looking at the source, or even recompiling if so desired — it’s included in the patch installer. The author is a known entity, trusted by many, and the install and uninstall method appears to be safe.

    I agree that the issue is indeed a risk management issue. As the senior security engineer for a large (60k+ seats on the network) educational institution, I recommended departments and individuals apply the patch. The reason being? The risks of remaining unpatched against a vulnerability with so many attack vectors seriously outweigh the threat of a patch that is as verifiable as it is. I fully expect to spend the next 6 months cleaning up after students as a direct result of this vulnerability (ok, ok, who am I kidding, I’m always cleaning up after them, I’ll have more this time). They’re the prime target for such email/web/IM borne malware given their propensity to click on anything and everything. That’s compounded by the number of brand new laptop christmas presents they’re toting onto campus just in time to turn on and email all their buddies and check all their favorite illicit websites just before the official patch is released and while they’re still likely vulnerable.

    Of course I’d prefer the official microsoft patch. I assume it will be very well tested, and the authoritative response is almost always the best choice. (Though I have to say, if rumors of a leaked ‘official’ patch causing BSOD’s are true, then Ilfak may have done better with his first try)

    A lot of us in the trenches are getting hit with this right now, doing cleanup and multiply rebuilding up-to-date machines. If the only patch is unofficial, well, I’ll take it.

  14. Andy McKnight says:

    Unless something changes significantly in the next few days, I’ll be waiting on the official MS patch rather than applying the unofficial one.

    There’s been plenty of chatter on this subject, plenty of talk on potential attack vectors and new variants but there’s been little report of *actual* impact from the trenches. Even the ISC’s (who have been arguably the biggest supporters of the unofficial patch) current poll of nearly 4000 respondants has 76% saying they’ve seen no impact yet.

    If this mutates into something more ugly before the MS patch then I’ll review it again but in the meantime the benefit doesn’t outweigh the risk for me. That’s a decision for each organisation to make themselves though.

  15. Derek Stevens says:

    I question the assessment of the scope of the problem in the Microsoft Security Advisory (912840):

    "Microsoft has been carefully monitoring the attempted exploitation of the WMF vulnerability since it became public last week, through its own forensic capabilities and through partnerships within the industry and law enforcement. Although the issue is serious and malicious attacks are being attempted, Microsoft’s intelligence sources indicate that the attacks are limited in scope and are not widespread."

    I disagree with this assessment. Since Dec 31st I’ve had 5 PCs (out of 13 I look after) which have had virus/spyware, which, as far as I could tell, were as a result of the WMF vulnerability. One happened right in front of my eyes – a popup window opened a wmf file, a few seconds late the PC had locked up and I ended up re-installing Windows. For comparison I generally have about 1 problem per year of this nature over the 13 PCs, so 5 problems in 6 days is about 60 times the norm.

  16. DF says:

    I installed the unofficial patch and my Wifi PC Card stopped working. Uninstalling the patch did not fix this, nor did reinstalling the driver / controller. I’m still looking for a fix.

  17. John Flakh says:

    Well, now that the official patch has come out, it appears that (a) Microsoft has changed its assessment of the risk and decided to release the patch out-of-cycle, and (b) Microsoft’s solution, which is to remove support for the SETABORTPROC function, is not fundamentally different from Ilfak Guilfanov’s unofficial patch.

  18. Alun Jones says:

    Sure it’s different. Even if the code was exactly the same (which it isn’t – Guilfanov’s was a hot-patch, Microsoft’s is a source-code alteration), the official patch is backed with all the support you could possibly want.

    Consider this – what if the patch you apply causes a LOB application to fail? If you have run Guilfanov’s patch, all you can do is hope that his uninstall is good; if you have run Microsoft’s patch, you can call 1-866-PCSAFETY or your regular support number, and get free assistance with the issue until it is resolved.

Comments are closed.

Skip to main content