Freigeben über

Conscientious Risk Management and WMF

  • Artikel

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.

Conclusion
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

  • Anonymous
    January 01, 2003
    PingBack from http://www.hilpers.com/6452-desktop-firewall-oder-anwendungs-paketfilter/2

  • Anonymous
    January 01, 2003
    PingBack from http://www.hilpers.it/2575927-info-vulnerabilita-wmf/2

  • Anonymous
    January 01, 2003
    The VML vulnerability continues to haunt us. According to SANS the exploit is "spreading,"

  • Anonymous
    January 02, 2006
    "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? ;)

  • Anonymous
    January 02, 2006
    "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? ;)

  • Anonymous
    January 03, 2006
    The comment has been removed

  • Anonymous
    January 03, 2006
    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?

    Gruss
    Bernd

  • Anonymous
    January 03, 2006
    The comment has been removed

  • Anonymous
    January 03, 2006
    >i have a question please
    link corrected:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/prntspol_0d6b.asp

  • Anonymous
    January 03, 2006
    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.

  • Anonymous
    January 03, 2006
    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.

  • Anonymous
    January 03, 2006
    The comment has been removed

  • Anonymous
    January 03, 2006
    The comment has been removed

  • Anonymous
    January 03, 2006
    The comment has been removed

  • Anonymous
    January 04, 2006
    The comment has been removed

  • Anonymous
    January 05, 2006
    The comment has been removed

  • Anonymous
    January 05, 2006
    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.

  • Anonymous
    January 05, 2006
    The comment has been removed

  • Anonymous
    January 05, 2006
    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.

  • Anonymous
    January 06, 2006
    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.

  • Anonymous
    January 06, 2006
    The comment has been removed