Desktop Search and the WMF vulnerability

I just read Jesper’s post about the recent WMF vulnerability found in Windows. If you haven’t heard about it, you can see the official Microsoft security advisory here.

Earlier today Scoble asked, “Where are the Microsoft bloggers?”and reports that Channel 9 users are asking why more bloggers at Microsoft aren’t talking about the issue.

So here I am doing my part. The original F-Secure bulletin mentioned that Google’s Desktop Search product could trigger this exploit when it indexes a file. That’s probably because Google Desktop, like countless other Windows applications, is using the standard Shell APIs to retrieve information about image files – which means loading the affected DLL and triggering the exploit. As a Windows Desktop Search user, you might be wondering if the same is true with WDS. To find out, we asked a member of my team to investigate whether indexing a malicious WMF file could cause infection. He used a virtual machine with WDS installed in a typical configuration and tested various use scenarios with an example WMF file containing malicious code. He reported the following results:

1. Putting the sample WMF file on the file system in an indexed location, the exploit was triggered.
2. Receiving the sample WMF file as an e-mail attachment in Outlook with indexing of attachments enabled, the exploit was not triggered.

You might be wondering how that could be, since the file was indexed in both cases. Well, if you ever watch TaskManager while WDS is indexing, you’ll notice one or more instances of a process called “WindowsSearchFilter.exe” – which loads the appropriate IFilter and retrieves metadata and contents from the file to be indexed. If you index Outlook attachments, you’ll also notice a process called “WindowsSearchSafeFilter.exe” which is a special filter daemon just for e-mail attachments. Before today, you might have wondered why we’d have this special case. However, given the results I mentioned above, I hope it begins to make sense.

In my personal opinion, this means that WDS has relatively little impact on the WMF vulnerability. Why would I say that, if indexing a WMF on the filesystem can cause infection? Well, for one, there’s significant action on the part of the user in downloading and saving that file. Second, simply browsing to the directory that contains the malicious file appears to cause infection as well (because of Explorer loading properties and thumbnails). In fact, if you have an infected WMF file on your hard drive, the damage has probably been done.

However, if you receive an e-mail with a malicious attachment – there is no user interaction at all. In fact, if it made it to your inbox, that attachment would probably be indexed long before you read the e-mail. Fortunately, it appears that our proactive decision to be extra careful when handling e-mail attachments has paid off.

If you want to prevent indexing of WMF files altogether, you can do so by right-clicking on the WDS tray icon, clicking “Desktop Search Options”, clicking the “Advanced” item on the left, and adding “.wmf” to the list of file extensions in the “Do not index these file types” box. However, as Jesper points out, a file can take advantage of this exploit without having a WMF extension. In fact, it could have a JPG or PNG extension but contain malicious WMF data and still trigger this exploit.

Still, since most people don’t care about WMF files, adding it to that list might be a worthy precaution. If you deploy WDS in a corporate environment, you can add WMF to the list of file types not to index via Group Policy.

However that is just my personal suggestion. For Microsoft’s suggested workarounds, including unregistering the affected DLL, check out the Microsoft advisory.

As usual, no warranties or other guarantees will be offered as to the quality of the opinions or anything else offered here.