XnView Software

Hello!

Currently the WMF bug is an enormous threat for Windows XP users (shimgvw.dll).

Is XnView also vulnerable by these WMF files?

I seriously doubt it, XnView should use it's own rendering engine for WMF images.

ckit wrote:I seriously doubt it, XnView should use it's own rendering engine for WMF images.

Don't know, i use windows WMF API like all others programs...

Ok, someone has made a fix for this already (Microsoft will issue their own real soon I think)

Technical details: this is a DLL which gets injected to all processes loading user32.dll. It patches the Escape() function in gdi32.dll. The result of the patch is that the SETABORT escape sequence is not accepted anymore. If for some reason the patch does not work for you, please uninstall it. It will be in the list of installed programs as "Windows WMF Metafile Vulnerability HotFix".

http://www.hexblog.com/security/files/w ... blog13.exe

In between I have unregistered and deleted shimgvw.dll and XnView still shows WMF files. So . . . that's enough security, I think.

Or might shimgvw.dll be comiled statically into XnView.exe? This would be an issue . . .

ckit wrote:Ok, someone has made a fix for this already (Microsoft will issue their own real soon I think)

I strongly advise NOT to use patch from some unknown site.
Unregister and rename the DLL if you want to be sure.

X.

The patch he's referring to has been checked and validated by most security sites (SANS, Secunia etc.) and is definitely safe. Unregistering the DLL gives almost no security, since it just prevents opening a WMF file with the standard association: opening the file with any other application relying on the Windows API (the problem lies in gdi32.dll), even just viewing a malicious WMF in the browser (not downloading it), is enough to get infected. Also, renaming a WMF to whatever you like doesn't prevent the exploit from working, so you might be browsing a page containing JPGs only and think of being safe, while really one of them is a specially crafted and renamed WMF... indeed, one of the known exploits in the wild uses one renamed as a JPG. If WMF are already registered to something else than the default Windows association unregistering the DLL should give no protection at all. Just browsing by chance to a site that contains a malicious WMF is enough, there's no complete protection also from antivirus software, nor firewalls.

Xyzzy is right, of course, generally speaking; in this case, due to the problem and the absence of an official patch, the "unknown" patch needs to be installed: "unknown" it really isn't, the source code is also provided and SANS has checked the provided compiled DLL with the source to ascertain that the executable doesn't contain something else.

You're right, the unofficial patch is necessary! I have just use the test from Heise[1] to prove the vulnerability of my system.

[1] http://www.heise.de/security/dienste/br ... /wmf.shtml

If F-secure recommends it, I trust it.
http://www.f-secure.com/weblog/

By the way. Read the "It's not a bug, it's a feature" entry from the F-secure blog...

robc wrote:The patch he's referring to has been checked and validated by most security sites (SANS, Secunia etc.)

Haven't noticed any mention of it on Secunia or CERT.
If you want to be credible, give links to well known sites.
If one wants to be sure and his firewall is worth anything, he should set detection rules for NIDS.

X.

If you try this proof of concept link:

http://sipr.net/test.wmf

(should be safe but I'd run it on a test system)

you will see that just unregistering the dll does not hack it. It still kills xnview and launches calc.exe. Be afraid, be very afraid. I am deploying the unofficial patch as I type.

Xyzzy, it's true that secunia doesn't cite the patch (I was also reading their site while I was posting, that's why I was mistaken), but SANS and Securitysoft do: surely you would trust them, won't you? Read here and see for yourself. Read also here, download the patch and check its source code... of course if you haven't yet been hit by some WMF exploit, that is GRC's Steve Gibson and F-Secure also recommend the patch, Windows IT Pro's Paul Thurrott also mentions it as do many other sources (ComputerWorld linked from Zone-h.org main page, iDefense, etc.): I'm afraid CERT and Secunia don't cite it as they would cite only official workarounds (as they do indeed in this instance also). You see, xyzzy, after 23 years in the field I did some research before running an "unknown" (which it isn't) on my machines...

BTW, I tried SNORT rules for Sunbelt/Kerio from here but they let pass a couple crafted WMFs made for testing, so I'm not that sure IDS can completely protect... or maybe it's just the rules which could be written better.

I have a unique concern. I still use Win98. By all accounts, including Microsoft's, all versions of Windows are vulnerable, but no one seems to be quite sure about Win98, since it lacks the SHIMGVW.DLL file altogether, so it can't be unregistered. The unofficial patch is not applicable. So far, various researcher's seem to be unable to infect Win98 test machines, but that's not completely comforting. People here might find thisinteresting. The writer tried an exploit on a Win98 system using IrfanView (which apparently uses the same API as XnView) and reported that "irfanView complained about a malformed header and didn’t open the file."

robc:
Yes, now I can regard the patch as tested. But I haven't installed it on my PC- for some reasons.
I think also that a LOT of people miss one point from MS advisory- using restricted user accout to mitigate threat. As exploit is executed in user context, it can't really do much harm on restricted account because of inability to infect whole system- just one account.
A LOT of people also miss the fact, that proof of concepts are just these- they are not threats. There are some AVs that detect ALL dangerous versions but not the proofs-of-concept.
Using NIDS seems to be problematic now because of exploit generation tool that appeared and which is specifically crafted to evade on-the-fly detection by NIDS.

KRH:
both XnView and IrfanView trigger infection using SETABORTPROC mechanism. Also 3rd party file managers trigger it, fe. Total Commander.

X.