[pmwiki-users] WMF vulnerability in Windows systems

Tegan Dowling tmdowling at gmail.com
Sun Jan 1 22:13:08 CST 2006


>From the links in the Slashdot article a coupld of days ago, I picked up
this suggestion for protecting my individual windows machine, which I
haven't implemented because I'm concerned I might not remember to change it
back after a fix is available:

---------
A Microsoft spokesperson said the company is investigating, though no
official word from them yet. A couple of security firms, including
Verisign's iDefense, have published workarounds that appear to mitigate the
threat. According to iDefense, Windows users can disable the rendering of
WMF files using the following hack

1. Click on the Start button on the taskbar.
2. Click on Run...
3. Type "regsvr32 /u shimgvw.dll" to disable.
4. Click ok when the change dialog appears

iDefense notes that this workaround may interfere with certain thumbnail
images loading correctly, though I have used the hack on my machine and
haven't had any problems yet. The company notes that once Microsoft issues a
patch, the WMF feature may be enabled again by entering the command
"regsvr32 shimgvw.dll" in step three above.

----------------

What do others think of this?

On 1/1/06, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>
> I just wanted to alert folks to the recent Windows Metafile
> vulnerability that is spreading throughout the Internet
> (references below).
>
> Microsoft Windows Metafiles (WMF images) are image files that can
> contain vector and bitmap picture information.  However, it turns
> out that it's possible to use WMF files to execute arbitrary code
> on any version of Windows, including and up to Windows XP SP2.
> There are known viruses in the wild based on this vulnerability
> and it is spreading rapidly [1, 2].
>
> There are several *very* troubling aspects to this particular
> vulnerability.
> First, it can be triggered in Internet Explorer without warning simply
> by being embedded in a web page.  (Firefox is reported to prompt before
> opening, but since most people consider images to be 'safe' they're
> likely to open it anyway.)
>
> Second, and this is what really stinks -- the vulnerability exists
> even if the file is not named with a '.wmf' extension, as WMF files
> are recognized by a special header and not the extension.  Thus, simply
> avoiding or disabling files with .wmf extensions doesn't provide any
> safety.
>
> There are literally millions of Windows systems vulnerable to this
> exploit, and Microsoft has not yet provided a patch.  This is not
> a theoretical exploit, there a number of known infections "in the
> wild".  Worse, the virus is easy to mutate, which means it's (currently)
> easy to slip it past anti-virus software.
>
> So, why am I bringing this up here?  For PmWiki sites, it means that
> every inline image link in a page could be pointing to an infected
> image file.  And if your site enables uploading (e.g., public sites
> without an upload password), then it's possible for someone to upload
> an Windows Metafile that can infect visitors to your site.
>
> And if you're running PmWiki on a Windows server and allow uploads,
> then it's possible for someone to upload a infected file to your
> server, and if you open the folder containing the infected file,
> your server is then infected.
>
> I'm thinking of adding an option to the uploads script to block
> any uploading of Windows Metafiles.  And sites that have edit
> passwords and upload passwords in place shouldn't have any difficulties.
> (pmwiki.org should be safe because it uses url approvals.)
>
> But sites that allow unrestricted uploads or page edits could
> potentially be used by malicious authors to spread the infection.
>
> I do wish to make clear that this is a problem with Microsoft Windows
> in general, and the problem isn't unique to PmWiki.  As SANS says in
> its WMF FAQ [1], there are too many infection methods to be able to list
> them all, including email attachments, web sites, instant messages,
> P2P file sharing, etc.  But I did want to make sure that PmWiki admins
> were aware of the potential risks.
>
> As always, feel free to respond with any comments, questions, or
> suggestions.
>
> Thanks,
>
> Pm
>
> 1. http://isc.sans.org/diary.php?storyid=994
> 2. http://www.us-cert.gov/cas/techalerts/TA05-362A.html
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://host.pmichaud.com/mailman/listinfo/pmwiki-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20060101/12325ed1/attachment.html 


More information about the pmwiki-users mailing list