Windows Metafile vulnerability was a Engineering and technology good articles nominee, but did not meet the good article criteria at the time. There may be suggestions below for improving the article. Once these issues have been addressed, the article can be renominated. Editors may also seek a reassessment of the decision if they believe there was a mistake.
Article milestones Date Process Result June 9, 2006 Good article nominee Not listed

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computer Security: Computing This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer SecurityWikipedia:WikiProject Computer SecurityTemplate:WikiProject Computer SecurityComputer Security articles ??? This article has not yet received a rating on the project's importance scale. This article is supported by WikiProject Computing. Things you can help WikiProject Computer Security with: Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information... Review importance and quality of existing articles Identify categories related to Computer Security Tag related articles Identify articles for creation (see also: Article requests) Identify articles for improvement Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc. Find editors who have shown interest in this subject and ask them to take a look here. Computing Mid‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Mid This article has been rated as Mid-importance on the project's importance scale. Microsoft Windows: Computing High‑importance This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles High This article has been rated as High-importance on the project's importance scale. This article is supported by WikiProject Computing.

"Use a safer web browser, such as Mozilla Firefox, which does not allow files to be downloaded and executed without the user's approval."

That was posted by 139.55.9.115 and quickly reverted by User:Violetriga. What was the reason for the reversion? Isn't that a possible solution? --Anthony5429 16:22, 2 January 2006 (UTC)[reply]

No, it is not. There isn't any known solution at this time. See the CERT & WMF FAQ links in the external links section. --That Guy, From That Show! 16:27, 2 January 2006 (UTC)[reply]

• As per the software forums on Something Awful, Firefox is not necessarily immune to this particular hack: "the exploit affects Firefox, Internet Explorer, and any other browser that displayes or downloads the file into the cache on the local machine". Which is a real proctalgia. DS 16:31, 2 January 2006 (UTC)[reply]

While Firefox might not be completely immune, it IS much safer. When you visit an infected page, it will use its own graphics engine to display the pictures, rather than sending the data to the windows default, so it will not automatically run the bad files. It does still download them to your cache however, so if you explore your cache folders with the pictures visible, or if you have a vulnerable indexing service running, you could still get infected, but the browser will not automatically infect you if you view a bad page.JeffStickney 01:27, 3 January 2006 (UTC)[reply]

That's not entirely correct. The newer version of FF is safer because by default, it will not display the image and prompt you whether you want to download it. Nothing to do with graphics engine. See new comment below about why even an alternative graphics engine / image viewer would not be safe. -- KTC 02:48, 4 January 2006 (UTC)[reply]

Ah - okay. Thanks. Just making sure the edit had not been incorrectly reverted. --Anthony5429 16:37, 2 January 2006 (UTC)[reply]

While the massive advantages of Firefox over Internet Explorer hardly need repeating, this is not a browser problem but an operating system one. What on earth are people still doing using Windows?! I feel quite secure in the knowledge that I sit here typing this on my computer which runs Linux, and have nothing to fear from Microsoft's shoddy piece of work. -- —Preceding unsigned comment added by 86.142.52.87 (talk • contribs)

While I have to admit I'm running Linux at the moment as well. Let's be fair, since this time it's not a bug from bad coding or bad design. Rather, it's a design that was right for the time it was designed in, and not the computer world we live in now. Much like TCP/IP doesn't consider much about security in its protocol, because at the time it was designed, it wasn't necessary. -- KTC 01:42, 3 January 2006 (UTC)[reply]

I'm sorry, just the idea of switching to Linux - which I have tried at least four different times - still scares me. The reason people still use Microsoft's "shoddy piece of work" is because I have tried four different Linux distros on three different computers, and it never completely worked. And you know the scary thing? I know what I'm doing. Eightball 04:54, 3 January 2006 (UTC)[reply]

I'm not certain if there is a precedent for having articles about system vulnerabilities. I think this case deserves an article of its own because of the 6% infected figure from McAfee (sourced online to [1]). If accurate and representative of the wider internet using population, this gives the issue a huge impact.--Fangz 22:06, 1 January 2006 (UTC)[reply]

This exploit is notable for involving a security hole that probably goes back to Windows 3.0. (it's proven to hit Windows 98) If true, that covers every version of Windows that was more than a seldom-used curiosity. Windows 3.0 was the first Windows that had any 32-bit support. That's 15 years ago. 24.110.60.225 04:13, 2 January 2006 (UTC)[reply]

<-{Please cite source of this claim} —Preceding unsigned comment added by 65.93.91.82 (talk • contribs) 21:28, 8 January 2006 65.93.91.82

Please start comment on a new line, and indented according to where about in the discussion it appears. And please sign your comment using ~~~~ at the end of your comment. -- KTC 00:09, 9 January 2006 (UTC)[reply]

http://news.google.co.uk/news?hl=en&ned=uk&q=WMF+Windows+3.0+OR+3.x&btnG=Search+News - Take your pick.

(More technical answer) The vulnerability is in one of the "escape" record that WMF allow. This escape (SETABORTPROC) was added in Win 3.x (and since been deprecated from Win95). That's why it goes back to Win 3.0 (or at least one of the 3.x series). -- KTC 00:15, 9 January 2006 (UTC)[reply]

This exploit is notable for involving an unusual exploit mechanism. It is not a buffer overflow of any kind, and certainly not related to HTML or VBscript confusion. The OS very deliberately makes use of a callback function defined in the WMF. In other words, WMF files were designed as a type of executable. This was only mildly foolish back in 1990. People forgot. Through code reuse, this joke of a file format ended up being supported on Internet-connected modern systems. 24.110.60.225 04:13, 2 January 2006 (UTC)[reply]

What are you on about? I have seen WMF files used like this at least two years ago, but as far I we knew back then the only thing you could run was a .bat file.

What about Code Red and Code Red II? We have articles on them. - Ta bu shi da yu 11:32, 2 January 2006 (UTC)[reply]

I have asked a question at the village pump re: wikipedia and this problem. Tristanb 04:50, 2 January 2006 (UTC)[reply]

There were a couple of exploits right at the end of 2005. The second one was made public only a few days before 2006.

I'm sure the media will coin a name for this problem, i'm not sure calling it 2005 wmf vulnerability is appropriate considering it's main effect will be in 2006. But for now, I suppose it will do. Tristanb 05:00, 2 January 2006 (UTC)[reply]

Yeah, there's a tendency with 'current events' to put a time (year, month, etc) in the title, but in this case it doesn't seem neccesary. Why not just WMF vulnerability or something? Brendanfox 12:14, 2 January 2006 (UTC)[reply]

Inveterate future-proofing - "what happens if there's another WMF vulnerability?" I couldn't say whether it's necessary or not, but that's the reason. PeteVerdon 21:16, 2 January 2006 (UTC)[reply]

Seems unlikely that there would be, given all the attention the format will now see. Not only that, but what's wrong with having WMF vulnerability as the article that would discuss all the vulnerabilities? It's just one way to get around - what was raised above - which is that this is really taking place in 2006, although it originated in 2005. --Brendanfox 23:37, 2 January 2006 (UTC)[reply]

I've renamed it as WMF vulnerability. If anyone can add details about WMF vulnerabilities other than the current alert then that would make for a better, broader article (see the section below). As is, this title is less confusing and more appropriate. violet/riga (t) 23:43, 2 January 2006 (UTC)[reply]

Wouldn't Windows Metafile vulnerability be a better name? --cesarb 23:45, 2 January 2006 (UTC)[reply]

You're right. violet/riga (t) 23:52, 2 January 2006 (UTC)[reply]

I can't work out why this was created as a seperate article in the first place. The article on Windows Metafile is quite short and seems like the obvious place to add all this information.

The hexblog link says that the source of the file is included, but when I hover over the link all I see is an executable. Do they really expect us to trust that the source is contained in a self-unpacking archive? Can anyone here independently verify that the patch from hexblog is the real deal? -Kasreyn 11:25, 2 January 2006 (UTC)[reply]

I trust them because ics@sans.org signed it with their new pgp key. It matched the key I already had. If we can't trust them...

Yes, the source is included. It'll be put in /Program Files/WindowsMetafileFix/

-- That Guy, From That Show! 14:03, 2 January 2006 (UTC)[reply]

This raises an interesting technical point. If a person does not want to trust a self-extracting zip-type package, is there a utility to inspect/unpack such from the outside?

Otherwise, one would have to unpack in some sort of temporary sandbox. Do self-extracting files work on a DOS box from a simple command line? -kd

Is that the only browser that exploit the vulnerability? Irfanfaiz 12:52, 2 January 2006 (UTC)[reply]

For all non-IE based user interaction and permission is necessary.

• All browses are effected because it's a MS Windows problem (sigh) again. See fire fox chat pages for latest[[2]]. This needs info to be added to news story but I'm tied up.

Also the is no mention of this yet on Wikinews.--Aspro 14:26, 2 January 2006 (UTC)[reply]

older versions of firefox (pre 1.0?) and opera are said to be completely vulnerable. current versions of firefox and opera will give the user a popup asking if they want to open the file. so said a few of the few dozen sites i've been scouring for info. --Quiddity 00:35, 3 January 2006 (UTC)[reply]

I don't know if this has any place in the article or not, but back in the mid-nineties I would read speculation in computer magazines that basically said, "Well, hypothetically, you COULD get a virus from a JPG because it can have embedded (if that's the word) code but the user would have to go out of his or her way to execute it, so therefore you are essentially safe with images." Wow--what a development. Breaky McWind 13:06, 2 January 2006 (UTC)[reply]

This is much worse than jpg handling loopholes, like a buffer overflow. The wmf format explicitly allows code execution. The Windows GRE blindly does so. It's basically a built-in payload. What's worse, you can easily hide a wmf file to look like other files, transmit it through any number of programs and code streams, but the GRE will still unwrap the payload for you. --Vector4F 17:28, 2 January 2006 (UTC)[reply]

I that case, it's a miracle this hasn't happened before. Thanks for the clarification. Breaky McWind 13:35, 4 January 2006 (UTC)[reply]

This has happened before, I think think there was some vulnerability in some versions of Adobe Acrobat Reader in regards to scripting found in some PDFs. IIRC not quite as earth-shattering as this thing though, as it only affected certain versions and the entire system was designed to use sandbox of some sort with very limited code execution capabilities (ie, they knew running code on client end was risky, so they limited the extent of damage it could do by implementing a sandbox), while WMF vulnerability was kind of like "display an image and boom, it runs any code with full user priviledges on just about any existant version of Windows". --wwwwolf (barks/growls) 10:36, 12 April 2006 (UTC)[reply]

The "solution" section of this article is one of the more biased I've seen on Wikipedia. This is an encyclopedia, not an internet security organization.

I can't say that I agree with having it there really, but it's not a POV dispute. violet/riga (t) 13:46, 2 January 2006 (UTC)[reply]

In that we're not an internet security organization, we shouldn't be telling people what they "should" be doing or else we appear biased to be in favor of those working to fix the vulnerability. igarvey 2 January 2006 (UTC)

That's the silliest thing I've ever heard. You might as well say that the article on artificial respiration is biased in favour of people not dying. - Montréalais 15:20, 2 January 2006 (UTC)[reply]

One could argue that merely existing and being conscious gives us a slant; there fore we are biased in favour of, say, staying alive. But that's veering off into metaphilosophy, a tricky subject at the best of times. I think we should keep some advice in the article, since this is a dangerous exploit and people will need/want information on how to minimise damage. --Sam Pointon 15:30, 2 January 2006 (UTC)[reply]

Something to keep in mind about what is approprate for an encyclopedia or not, is what sorts of information does the typical user come looking for when they look up a specific topic. THe details of how to mitigate a problem are infact true as provided in the article. Changing the section title to workaround instead of solution might releave anyone worried that we are appearing biased against virus writers of all things. I think that is silly myself but workaround is a better/more accurate section heading anyway. Dalf | Talk 18:30, 2 January 2006 (UTC)[reply]

Personally, I come here for ALL my information. In the same way the exploit's use is explained, how to stop its use should be explained also. 01:04, 3 January 2006 (UTC)

What does this even mean? Oh, it got fixed... fruitofwisdom 16:14, 2 January 2006 (UTC)[reply]

Anyone know if this affects Wine? Kanthoney 17:55, 2 January 2006 (UTC)[reply]

No, it does not. --That Guy, From That Show! 18:01, 2 January 2006 (UTC)[reply]

Sorry, but looking at the code, it looks like it does. Someone seems to have already started on a patch on the mailing list. --cesarb 23:23, 2 January 2006 (UTC)[reply]

(Although possibly one might need some wine after having to deal with this issue... :P Her Pegship 05:08, 4 January 2006 (UTC))[reply]

I have been wondering about this all day. I just found a report from a google cache of hexblog.com (the account has been suspended, unsuprisingly) that the test program ran fine on a Suse 9.3 system running wine and that the test reported "not vulnerable." http://www.google.com/search?q=cache:ZUeLeai0cNcJ:www.hexblog.com/2006/01/wmf_vulnerability_checker.html+wmf+vulnerability+wine&hl=en&client=firefox

Though I do not know the veracity of the test or what might happen with a more complicated attack, it does make me breathe easier (as I am installing wine/codeweavers on a machine for others).

I run Ubuntu Linux and just installed the latest version of Wine for it (0.9.4-winehq-1) as per their instructions; I then downloaded Ilfak Guilfanov's WMF vulnerability test program from Gibson Research Corporation [3]. It reports:

No vulnerability has been detected

You [sic] system seems to be invulnerable to the WMF exploit.

Please note that this program tries only one WMF exploit. In theory other vulnerabilities and exploits are possible, so stay vigilant and update your systems frequently!

That of course is for the plain vanilla install; I have no idea what *might* be possible if you install other stuff on top of it :) -- Limulus 07:53, 4 January 2006 (UTC)[reply]

That's just one case. It might not always be that way - particularly if Wine DLLs are replaced by actual Windows ones.

From what I can glean from the main article, so long as you don't use the MS gdi32.dll, then you shouldn't have a problem... -- Limulus 14:21, 4 January 2006 (UTC)[reply]

That seems likely - but the fact that there are possibly many Wine users with the MS gdi32.dll installed already means that we can't say Wine is safe in the article. WMarsh 14:28, 4 January 2006 (UTC)[reply]

Is it even possible to run a native gdi on Wine? I think it's one of the few core DLLs which must always use the "builtin" version. --cesarb 15:17, 4 January 2006 (UTC)[reply]

See the list on [4]. Native GDI is not supported, so there's no risk of someone using Wine with the Windows version of the GDI dll. --cesarb 15:18, 4 January 2006 (UTC)[reply]

Ah, good.WMarsh 15:23, 4 January 2006 (UTC)[reply]

According to ZDNet it *is* potentially exploitable in Wine, but for a curious reason: while they created their own GDI, they did it pretty much perfectly to the MS specs... and code execution is a *feature* of GDI (it would be like someone designing a new car based on the blueprints for a Ford Pinto and then having problem with the new car exploding in crashes just like the Pinto did 8-) I'll tidy up the entry in a sec to incorporate this new info -- Limulus 12:06, 6 January 2006 (UTC)[reply]

According to a Slashdot post (where you can get accurate info ;) ) This has been fixed in the Wine CVS tree http://it.slashdot.org/article.pl?sid=06/01/06/2043203&tid=172&tid=125&tid=106 Of course, that would still leave earlier versions possibly vulnerable.

I use a message rule that sends anything containing an attachment to a folder labelled "suspicious", and leave the preview pane off. If it contains an attached picture file, I won't open it by accident.JeffStickney 18:55, 2 January 2006 (UTC)[reply]

That isn't so much a workaround as much as it is a security precaution, of the "Don't take candy from strangers" type. --Scottie theNerd 19:41, 2 January 2006 (UTC)[reply]

I'm just not sure that including "Block all WMF files at your network perimeter" is worthwhile in the list of ways to handle the problem... it's pretty well-established that there's no way to identify infected files, since they can come into a network in about 1,000 different ways. Sure, they can be .WMF files... but they can also be .JPG (or .*) files served with the right MIME type, or they can be WMF files embedded in Word documents, etc. Jason t c 19:22, 2 January 2006 (UTC)[reply]

Metasploit's code already circumvents any reasonable attempt to block all WMF files. So, yes, its a poor security measure. To my knowledge, there are only two workable measures, install the unofficial patch, or switch to a browser, email, and IM programs which allow you to disable autoloading of images. JeffBurdges 20:56, 2 January 2006 (UTC)[reply]

Switching software doesn't help if it's already on your computer since merely selecting the image (or even just opening the directory containing it according to some source) can trigger vulnerable dll's to parse the file and thus infection. -- KTC 21:23, 2 January 2006 (UTC)[reply]

Probably worth removing the recommendation of changing the WMF file handler, too -- since it doesn't matter what the WMF file handler is if the malware comes in as a .JPG file. Yes? Jason t c 22:29, 2 January 2006 (UTC)[reply]

I've reverted the deletion after reading the US-CERT Vulnerability Note (what half the workaround list is base on). Filtering by .wmf (or whatever) does not work, but it meant filtering by checking file header as it comes through the network, which does go some way.

Not sure about the bit about changing handler, need to read & think some more before I can comment on it. -- KTC 22:52, 2 January 2006 (UTC)[reply]

The only problem is that it still doesn't really patch the hole -- for example, WMF files embedded in Word documents still get through that without problem. But since this is about how to apply as many patches as possible to deal with the issue, it might just be worthwhile letting it stand... Jason t c 01:32, 3 January 2006 (UTC)[reply]

Does anyone have a link that works? -- Миборовский ^{U|T|C|E|Chugoku Banzai!} 20:03, 2 January 2006 (UTC)[reply]

• He's Belgian, not Russian, and his link is working fine, just a bit overloaded... Jason t c 20:20, 2 January 2006 (UTC)[reply]
  • he seems to be russian, but lives in belgium now: [5] —Preceding unsigned comment added by 84.178.79.85 (talk • contribs)

are the symptoms of this infection? —Preceding unsigned comment added by 66.138.18.219 (talk • contribs)

You're right, this isn't ever explained on the main page. Anyone up for explaining it? My brief version (I don't have time right now to make it perfect) is that the flaw everyone's reporting is the VECTOR for an infection. That is to say, there's a problem in the WMF file format that allows code to be included in a WMF file which should be executed on a failure to render the image properly. Malware writers can take advantage of this by creating a malformed WMF file, and then putting into the image file as payload any malicious program they wish. So 1,000 different malware authors can create 1,000 different viruses/trojans/bad things. What this means is that there is no one symptom of infection, since you could get infected with any of an infinite number of things via this one vector, the WMF file format vector. Jason t c 22:33, 2 January 2006 (UTC)[reply]

One of the external links here has a couple of screen capture videos that show systems getting infected. Check those out. -- Миборовский ^{U|T|C|E|Chugoku Banzai!} 01:19, 3 January 2006 (UTC)[reply]

I'm guessing the newspapers will start calling it "Computer HIV". Deltabeignet 20:57, 3 January 2006 (UTC)[reply]

I've found two mentions of previous vulnerabilities:

• http://www.symantec.com/avcenter/security/Content/10120.html
• http://securityresponse.symantec.com/avcenter/security/Content/15352.html

violet/riga (t) 23:58, 2 January 2006 (UTC)[reply]

"Computers running Apple Mac OS X or Linux are affected."

Can we have further details of this, and a source? - Ta bu shi da yu 01:19, 3 January 2006 (UTC)[reply]

That was simple vandalism. -- KTC 01:25, 3 January 2006 (UTC)[reply]

Actually, I think it was a mistake. The anon who did it actually has a fantastic edit history! - Ta bu shi da yu 01:31, 3 January 2006 (UTC)[reply]

I hadn't check at the time, but I think you're right. Apology for anon for false unfounded accusation. -- KTC 01:37, 3 January 2006 (UTC)[reply]

What can we say? Having a non-malicious anon is a rare pleasure! Pity they got collateral damage on new pages, semi protected pages and general low opinion of Wikipedians :( - Ta bu shi da yu 01:39, 3 January 2006 (UTC)[reply]

Said mistake may be based upon some internet forums who were forced to disable img tags saying sorry to the Mac & Linux users. JeffBurdges 03:28, 3 January 2006 (UTC)[reply]

No, it was because I attempted to rephrase the sentence (for some reason) and assumed the negation element preceeded the DO, which it didn't. Anyway, it's been cleared up. 68.39.174.238 05:07, 3 January 2006 (UTC)[reply]

Why has the statement "Computers running Apple Mac OS X or Linux are not affected" disappeared from the article? The current statement "Computers which do not run Windows operating systems are not affected, however operating systems with third-party programs or libraries designed to view WMF files on non-Windows systems are potentially vulnerable [1]." doesn't seem to be supported by the reference, and there should be a clear statement of whether OS X or Linux users are at risk. (I suspect they are not, but we should nail this down.) - Nunh-huh 07:51, 4 January 2006 (UTC)[reply]

See libwmf comment below. libwmf is probably not vulnerable. Wine is also believed to not be vulnerable, but wine is often run with some real Windows DLLs, possibly creating the vulnerability. Virtual PC, other emulators which run a real copy of Windows "in a box", will all be vulnerable. JeffBurdges 15:09, 4 January 2006 (UTC)[reply]

We don't "nail" certain other OS down because there's more OS than just OS X and Linux. To cover every operating systems in use (including not just PCs and macs, but servers, mainframe, game console, etc.) would take an article in itself. And why focus so much attention on other OS when this is a Windows vulnerability, so a Windows problem, and doesn't affect other OS (with exceptions mention by Jeff above), and stated as such. -- KTC 17:53, 4 January 2006 (UTC)[reply]

If we don't know that OS X and Linux aren't affected, that's a good reason not to say so. But if we know OS X and Linux aren't affected, we should say so. I gather from the response that this is strictly a WIndows liability, so I'll emend our sentence to make that clear. - Nunh-huh 04:07, 5 January 2006 (UTC)[reply]

We're not here to advertise any particular alternative OS. There's more OS than just OS X and Linux, what about various Unix, BSD, MS-DOS, various mainframe / embedded OS, OS/2, "Classics" Mac OS, OpenVMS, RISC OS, AmigaOS, ReactOS, GNU/Hurd, SkyOS, ...... ? The list goes on. This article is not the place to list all the OS that one might use / exist that are not vulnerable. The article merely need to state that this is a Windows problem, and non-Windows OS are not affected (with exception bah bah bah). -- KTC 04:54, 5 January 2006 (UTC)[reply]

Stating exactly which OS's are involved is not advertising. The previous formulation didn't state this is a Windows problem only. We're here to provide information, not obscure it. - Nunh-huh 04:58, 5 January 2006 (UTC)[reply]

So by your logic, the article should say "non-windows operating system (various Unix, BSD, MS-DOS, various mainframe / embedded OS, OS/2, "Classics" Mac OS, OpenVMS, RISC OS, AmigaOS, ReactOS, GNU/Hurd, SkyOS, ......)? THAT would be what I call spelling it out. -- KTC 05:11, 5 January 2006 (UTC) arguing against inclusion of 2 specific OS, while running one of them....[reply]

Also, how is saying only Windows system is vulnerable not stating this is a Windows problem only? -- KTC 05:13, 5 January 2006 (UTC)[reply]

Have you been reading what the article said? Up until the recent edits, it did not say "the only affected operating system is Windows", and it still "hedges" that by claiming that non-Windows OS's "may" be affected if running certain other software. - Nunh-huh 05:21, 5 January 2006 (UTC)[reply]

Of course I've read it. Most of my recent edits have been related to this article. How recent are you talking about? This article have only existed since 21:57, 1 January 2006. Let us take this time one day ago:

Computers that are not running the Windows operating system are not affected; however, it is unknown whether Windows emulators and compatibility layers (such as Wine) are vulnerable.

It does not say only Windows is and will be affected, because no one (and certainly not us) can guarantee that. It says if you run other OS and this and this is true, then you may be affected. Well, that's because that IS the case. Until the day someone have tested all possible emulators and compatibility layers for Windows, on all possible operating systems, and show none of them are affected by this vulnerability, we cannot say only Windows are affected with no exception. -- KTC 05:35, 5 January 2006 (UTC)[reply]

So you want to leave open the possibility that OS X, which has no "gdi32.dll", could be affected? Why do you want to do that? And how would that work? - Nunh-huh 06:06, 5 January 2006 (UTC)[reply]

And are you guaranteeing no Windows emulators or compatability layer on Macs ever invented follow the WMF spec. which would then make them vulnerable? And whatever happened to all the other OS apart from OS X.... -- KTC 03:36, 7 January 2006 (UTC) with nothing more to say on this issue[reply]

No, I'm saying you shouldn't suggest such things exist if you have no knowledge that they do. If you know of any such vulnerabilities, that would indeed make a valuable addition to the article. And as far as I know, no one has removed information about other operating systems from the article. - Nunh-huh 03:44, 7 January 2006 (UTC)[reply]

No, if you check my contributions, you'd see I've never suggested such a thing exist. And if you check all of article history, then you'd also see there has indeed been people other than me who removed any specific OS being mentioned when at various time it's been placed in. I've stop doing so as it's just not worth having an edit war over. Much of the article changes (and indeed should) as time goes on anyway. I'm at the moment actually planning on a complete rewrite (when this has settled down) which incluces mention of the Nov. 05 discovery of buffer overflow vulnerability which relates to WMF and hopefully written in a way that would date better. Care to help? :-) -- KTC 04:02, 7 January 2006 (UTC)[reply]

I'm really unconcerned about what you in particular have written: I'm concerned that the article has, at various times, seemed to suggest that a Mac OS running (unspecified) software might be vulnerable. What I'm interested in nailing down is whether this (unspecified) software is hypothetical, or something that actually exists, and having it named if it indeed exists. - Nunh-huh 04:13, 7 January 2006 (UTC)[reply]

For what it counts, I concur with KTC here... jnothman ^talk 06:06, 5 January 2006 (UTC)[reply]

Is switching Operating Systems a valid alternative? I think it is, if worded correctly. For example, saying something like "By switching to a more secure operating system" is a point of view. Opinions?

Certainly, not using Windows will save you from the vulnerability! That's just a fact. 86.142.52.87 02:47, 3 January 2006 (UTC)[reply]

I think the way it is worded in the version I just saw is just flamebait. The article already says that non-MS operating systems are not affected. I think just linking to OS X, Linux, etc. at that point is fine. Massysett 03:18, 3 January 2006 (UTC)[reply]

A bit of a correction here. You cannot run OSX on an x86 (Intel) box without emulation. Sure, you can try to run the bootleg OSX that was out there on the torrent sites, but in reality there is no WAY to run Mac OSX on a non-Mac machine. I'd rather move to OSX than directly, say, to Redhat. --Stoneman

Not legally, and not until Apple come out with an official version, yes. -- KTC 03:52, 3 January 2006 (UTC)[reply]

I think tech savvy people know that switching to Linux is always an option, as the idea crosses their mind every time a bad virus comes out. I'd focus on explaining just how dangerous this exploit is. Here is a senerio: I want to know how much a competitor bids, so I forward a slightly modified IRC bot delivering IM worm to my competitor, or even create an email version; instant back door for industrial espionage. Very very dangerous. JeffBurdges 03:42, 3 January 2006 (UTC)[reply]

By saying more (or less) secure is definitely a POV. Who's judging, MS? RH? Which study are you going to refer to? Seeing how being stats and business politics, there's a million of them, and they don't exactly all agree with each other.

Anyhow, back to the orginial point. While it's definitely an alternative, it's not a workaround. So there's no place for it in that section of the article. And in the other section, yes, it does already say non-Windows OS system are not affected (unless ...). -- KTC 03:52, 3 January 2006 (UTC) writing from a laptop running Linux...[reply]

I removed that part without second thought. The entire idea is, like said, flamebait, especially in the wording, and it was already mentioned on what operating systems the exploit is vulnerable on. Eightball 05:10, 3 January 2006 (UTC)[reply]

I have removed mention of alternative operating systems from the list of "steps that users should consider taking". As others have stated, it's already at the top of the article, and is unnecessary further down. Having it in "steps that users should consider taking" is akin to giving "move to another country" as preparation advice for those in the path of a natural disaster. Severisth 09:27, 3 January 2006 (UTC)[reply]

On second thought, Linux and Mac OS X actually should be mentioned in the workaround section. It would be best to use a Linux or Mac OS X machine for high risk activities, like filtering spam or browsing online forums that permit <img> tags or avatars. I'll add a sentence, change it if you don't like it. JeffBurdges 06:12, 3 January 2006 (UTC)[reply]

I agree, that is probably warranted; I did change the sentence to make it more broad, and also to add additional information and caution regarding Wine. Eightball 06:46, 3 January 2006 (UTC)[reply]

I'm not going to revert it at the moment, but I'm not sure yours fits in the list of workarounds, it just implies a workaround. My attempt actually was a workaround itself: If you have Linux, use it for the most dangerous stuff. I made no value judgement or said that you should have Linux. But I did try to specify what was most dangerous. To date, this includes browsing some forums and MSN's IM, although that could be fleshed out into a bigger list. Anyway, I think your current sentence is more like a final sentence to the introduction, i.e. other operating systems should be safe. JeffBurdges 07:09, 3 January 2006 (UTC)[reply]

On second thought I removed my sentence, and added the bit about Windows emulators to the sentence about non-Windows OS's not being vulnerable. Personally I think that simply mentioning that only Windows is vulnerable is enough of a notice, and there is really no way to word it right in the workaround. Also, using a different OS is less of a workaround and more of a complete solution, or prevention. Eightball 19:27, 3 January 2006 (UTC)[reply]

I agree with JeffBurdges. I consider it a "workaround" if I use my OS X laptop, instead of my work deasktop, to read fark's photoshop threads or livejournal, both of which JeffBurdges claims are vulnerable. 69.61.125.42 19:39, 3 January 2006 (UTC) I believe you meant to post this comment here. Eightball 20:08, 3 January 2006 (UTC)[reply]

Workaround - "A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed." Formating and switching OS is not a temporary fix for someone that's waiting for MS patch on 10 Jan. If someone can word it to that effect of above by 69.61.125.42 (using a comp running a diff. OS that you already have access to), then it's fine. But suggesting merely switching OS implies reformating and installing a new OS, which is not a workaround. -- KTC 22:57, 3 January 2006 (UTC)[reply]

I agree with you, but I think the idea of using a different operating system is easily inferred through the many times it is mentioned that it is only exploitable on Windows. Eightball 02:37, 4 January 2006 (UTC)[reply]

KTC, How about now? It could just say avoid high risk sites, or use an alternative operating system. I have to admit, I hadn't specifically thought about Photoshop Friday on fark as a vector, should be interesting. JeffBurdges 11:25, 4 January 2006 (UTC)[reply]

Well worded, JeffBurdges. Severisth 14:42, 4 January 2006 (UTC)[reply]

Yeah, that look good to me. :-) -- KTC 17:57, 4 January 2006 (UTC)[reply]

I have to say I don't like the wording. Most people are going to see that someone considers web browser and AIM as high-risk activities and are going to shrug it off. It should be worded in a way that just says you can use other OS's for viewing images. Which is so broad and oft-mentioned, it's an unneeded sentence altogether. Eightball 03:48, 5 January 2006 (UTC)[reply]

Umm, that IM worm sounds like seriously bad news, like industrial espionage bad. But I think it spreads using MSN, not AIM, might be good to clarify. JeffBurdges 22:45, 5 January 2006 (UTC)[reply]

It would be useful if the article explained how to do this. What are you supposed to click, ect...? For instance, I have a Windows 98, what should I do? 207.6.31.119 04:03, 3 January 2006 (UTC)[reply]

regsvr32.exe /u shimgvw.dll is how you do it. - Ta bu shi da yu 04:27, 3 January 2006 (UTC)[reply]

Not sure whether that works for Win9x. Anyhow, the full detail is in referenced Microsoft Advisory [6]. -- KTC 04:33, 3 January 2006 (UTC)[reply]

This code is NOT what Microsoft recommends on its web site, which is to run "regsvr32 -u %windir%\system32\shimgvw.dll" -- I ran what is suggested here on a friend's cumputer and now it's not working properly ... anybody know how I can undo it? David94114 18:36, 4 January 2006 (UTC)David94114[reply]

The line regsvr32.exe /u shimgvw.dll & regsvr32 -u %windir%\system32\shimgvw.dll have the same effect (with exception on computer with modified system paths order). To quote Microsoft:

Impact of Workaround: The Windows Picture and Fax Viewer will no longer be started when users click on a link to an image type that is associated with the Windows Picture and Fax Viewer.

To undo this change, re-register Shimgvw.dll by following the above steps. Replace the text in Step 1 with “regsvr32 %windir%\system32\shimgvw.dll” (without the quotation marks).

-- KTC 18:50, 4 January 2006 (UTC)[reply]

That really is too vague to go on "now my friend's computer...[is] not working properly". What exactly does that mean?!? - Ta bu shi da yu 12:07, 15 February 2006 (UTC)[reply]

There's been editors changing back and forth the word Utilize / Utilise. To stop this from becoming a WP:LAME entry, I've reworded the sentence to avoid using the word altogether. -- KTC 04:37, 3 January 2006 (UTC)[reply]

If I edited that, I apologize, I think I may have without thinking; I try to keep spelling variations the same ever the since the whole Iranian plane crash thing. Eightball 05:04, 3 January 2006 (UTC)[reply]

I'm an Aussie who uses English spelling. I think that as MS are primarily a U.S. corporation we should use American spelling. - Ta bu shi da yu 06:38, 3 January 2006 (UTC)[reply]

You could interpret the Manual of Style to support that, however, since the scope of the vulnerability goes far beyond just America that point would be rather moot; from there it's up to the spelling of the first major edit, which I do not know about. Of course you could just use what KTC has done, and what I find to be the best solution, and just rephrase the sentence or use a synonym that is the same across all variations. Eightball 06:42, 3 January 2006 (UTC)[reply]

Nearly all sentences utilizing utilise or utilising utilize need to be taken out and shot dead anyway. Ugh. We should ban the word(s) from wikipedia. Plain old use is much nicer. (and don't get be started on passed away, flatulated...) 24.110.60.225 07:38, 4 January 2006 (UTC)[reply]

The last sentence of the intro is factually incorrect. libwmf merely converts the image contents of the WMF file. How is it going to run the Escape record on a system without a shred of MS's API? libwmf doesn't use Wine, AFAIK. I instead recommend "It remains unclear which Windows emulators are vulnerable, but those emplying full copies of Microsoft Windows are probably at risk." JeffBurdges 06:08, 3 January 2006 (UTC)[reply]

Good edit. Ian 2k3k 02:34, 4 January 2006 (UTC)[reply]

Should we mention this too? http://www.nist.org/nist_plugins/content/content.php?content.25 -- —Preceding unsigned comment added by 151.46.1.176 (talk • contribs) 13:37, 3 January 2006

As noted on <http://www.microsoft.com/technet/security/advisory/912840.mspx> a patch has been developed and slated for release by Jan 10th. I blockquoted the technet article on the wiki article.
Kether83 15:16, 3 January 2006 (UTC)[reply]

That's a long bloody time, what the hell are they playing at? - Ferret 16:20, 3 January 2006 (UTC)[reply]

They're releasing it on their monthly patch release date. In the mean time, giving themselves a week to test & localised it for all their language versions. -- KTC 16:24, 3 January 2006 (UTC)[reply]

If we explain exactly how to take advantage of this problem people are more likely to take advantage of it. Wouldn't it be smarter to just allude to how the problem is taken advantage of? Tev 17:59, 3 January 2006 (UTC)[reply]

I don't think any "hacker" who has to learn how to exploit this from Wikipedia is much of a threat to the world.--81.179.192.191 18:12, 3 January 2006 (UTC)[reply]

WP:BEANS! Always wanted an excuse to say that. --Sam Pointon 18:25, 3 January 2006 (UTC)[reply]

Wikipedia contains spoilers and content you may find objectionable. Security through obscurity doesn't work. We don't actually have details of how to expolit it anyway (the technical details of actual coding), mearly what general method malware have already been employing. -- KTC 18:53, 3 January 2006 (UTC)[reply]

I'm thinking the only real problem is the group that published code for the 2nd-gen exploit. Eightball 19:29, 3 January 2006 (UTC)[reply]

Gem if you haven't already read this! :-) Oxy-morons, SANS ISC. Extra commentary available at http://www.node707.com/archives/006553.shtml . -- KTC 00:26, 4 January 2006 (UTC)[reply]

Check out this article: http://www DOT irongeek DOT com/i.php?page=security/counterwmf (Counter WMF Exploit with the WMF Exploit) 140.168.69.166 23:36, 3 January 2006 (UTC)[reply]

Fixed the link in the comment above. --cesarb 23:55, 3 January 2006 (UTC)[reply]

Warning: the link above contains code which exploits this vulnerability for the stated purpose of running the regsrv32.exe -u command. --cesarb 00:44, 4 January 2006 (UTC)[reply]

Before anyone say "it doesn't work!". I've already rewrote the article and provided a link to ISC's site where they have a copy of the patch for download (along with md5 & pgp signature so you're sure it's unmodified). -- KTC 00:21, 4 January 2006 (UTC)[reply]

Would an alternate viewer, like Nero Photosnap be a safer image viewer, or does this still hand off critical functions to windows?JeffStickney 01:17, 4 January 2006 (UTC)[reply]

No, because even if you use a viewer that's safe (even if there is one, I have no idea), it would not protect you against exploits that deliever its payload by just having the directory containing the files open, nevermind previewing the image using Windows Image Viewer, nevermind just selecting the image in Explorer, nevermind file being index by OS, nevermind ..... -- KTC 02:27, 4 January 2006 (UTC)[reply]

Further to the above, the vulnerability is in gdi32.dll, along with the fact WMF is proprietary MS image format. This means if the viewer understand WMF, it's cause it's calling gdi32.dll. So an alternate viewer would still be vulnerable. This is really a Windows OS vulnerability. -- KTC 02:44, 4 January 2006 (UTC)[reply]

From the MS Security advisory:

Mitigating Factors:

• In a Web-based attack scenario, an attacker would have to host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker would have no way to force users to visit a malicious Web site. Instead, an attacker would have to persuade users to visit the Web site, typically by getting them to click a link in an e-mail or Instant Messenger request that takes users to the attacker's Web site.

• •In an e-mail based attack involving the current exploit, customers would have to click on a link in a malicious e-mail or open an attachment that exploits the vulnerability. It is important to remember that this malicious attachment may not be a .wmf. It could also be a .jpg, .gif, or other format. At this point, no attachment has been identified in which a user can be attacked simply by reading mail.

• An attacker who successfully exploited this vulnerability could only gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

• By default, Internet Explorer on Windows Server 2003, on Windows Server 2003 Service Pack 1, on Windows Server 2003 with Service Pack 1 for Itanium-based Systems, and on Windows Server 2003 x64 Edition runs in a restricted mode that is known as Enhanced Security Configuration This mode mitigates this vulnerability where the e-mail vector is concerned although clicking on a link would still put users at risk. In Windows Server 2003, Microsoft Outlook Express uses plain text for reading and sending messages by default. When replying to an e-mail message that is sent in another format, the response is formatted in plain text. See the FAQ section of this vulnerability for more information about Internet Explorer Enhanced Security Configuration

Can we incorporate this into the article? It's not NPOV if we don't. - Ta bu shi da yu 06:28, 4 January 2006 (UTC)[reply]

My take on that information (not a flame, my POV on it)

• MS was already completely incorrect by the 14th word. A web site isn't necessary. For example thinking off of the top of my head, I could be a complete ass and start up a Counter-Strike gaming server and easily sneak an exploit in through a gaming server Message Of The Day (MOTD).

Technically they did say "in a Web-based attack", so they weren't incorrect by the 14th word, just misleading. Tempshill 04:05, 5 January 2006 (UTC)[reply]

• The second paragraph is incorrect also. Users often don't have to click anything at all.

• The third is sort of correct but misleading. Although gaining higher rights would be more difficult, the exploits dont need those rights to attack other computers or gather sensitive information.

• The fourth is a sales pitch.

-- That Guy, From That Show! 06:49, 4 January 2006 (UTC)[reply]

Well, can we at least document their mitigating factors, and then gives reasons why they are wrong? That would still be NPOV and accurate. - Ta bu shi da yu 06:56, 4 January 2006 (UTC)[reply]

I would not enumerate their factors without explaining why they are wrong. I might even explain that they are wrong, without fully enumerating the factors. Our priority should be to limit miss-information, whatever that requires. JeffBurdges 11:07, 4 January 2006 (UTC)[reply]

I think Ta bu shi da yu is correct; the article ought to state the Microsoft points and rebuttals. That won't spread any misinformation and will in fact shed more light on Microsoft's approach to this mess. Tempshill 04:05, 5 January 2006 (UTC)[reply]

Looks like they've detected the problem now already:

File:McAfee VirusScan Exploit-WMF detected.PNG

It detected and stopped it on my system. - Ta bu shi da yu 06:36, 4 January 2006 (UTC)[reply]

Yes, many of the AV companies updated detection quite quickly.

People may find this comparative list of detection tests from 12/31/05 useful. -- That Guy, From That Show! 06:59, 4 January 2006 (UTC)[reply]

McAfee is only detecting the known exploits. It would be easy to roll your own undetectable one. If your interested in industrial espionage, your going to take the extra time to make it undetectable. JeffBurdges 11:10, 4 January 2006 (UTC)[reply]

The Ilfak 3rd party hotfix you mention is reported to have a side-effect: you will not be able to print to certain GDI-based laser printers after you install the patch. The Samsung ML-1210 is mentioned. GDI-based printers are cheaper but brainless monchrome or colour laser printers, where your Windows machine does all the print rendering job, instead of on-board electronics. 195.70.32.136 11:36, 4 January 2006 (UTC)[reply]

Source, please? With a source for that information, it can be put on the article. --cesarb 15:31, 4 January 2006 (UTC)[reply]

Don't know a source, but from memory some GDI printers replay metafiles. Could be correct. Anyway, I agree: it needs a source. - Ta bu shi da yu 12:53, 5 January 2006 (UTC)[reply]

Good source: http://isc.sans.org/diary.php?storyid=1018. --cesarb 23:42, 5 January 2006 (UTC)[reply]

As a workaround [5], on 28 December 2005 Microsoft advised Windows users to unregister the dynamic-link library file shimgvw.dll (which can be done by executing the command regsvr32.exe /u shimgvw.dll from the Run menu or the command prompt) which invokes previewing of image files and is exploited by most of these attacks.

The Microsoft security bulletin pointed to by footnote [5] doesn't mention the above at all. Could someone cite the source? Tempshill 04:02, 5 January 2006 (UTC)[reply]

It's there. You just need to select "Suggested Actions" (under "General Information") and expand the sub-text before you'll see it. -- KTC 04:42, 5 January 2006 (UTC)[reply]

I can't find it either and it caused my friend's computer to crash 71.139.119.11 05:59, 6 January 2006 (UTC)David94114[reply]

I doubt that was what made your friend's PC to crash. - Ta bu shi da yu 12:05, 15 February 2006 (UTC)[reply]

Well it's not there now because MS has released their patch and all that page now says is see the security bulletin. But it was there, and you can see the same information if you search around archive of articles on places like ISC's website.

All regsvr32.exe (or regsvr32, same thing, windows assume .exe) does is register or unregister dll's on the system. The OS should not crash if you typed exactly line above. -- KTC 03:12, 7 January 2006 (UTC)[reply]

There seems to be some sort of patch available through Microsoft Update at least. Haven't got time to edit the article properly, I'm afraid; anyone?

• http://www.microsoft.com/athome/security/update/bulletins/200601_WMF.mspx
• http://www.microsoft.com/technet/security/bulletin/ms06-jan.mspx
• info from Microsoft Update (for Win2K): "Security Update for Windows 2000 (KB912919)" / "A remote code execution security issue has been identified in the Graphics Rendering Engine [...]"

-- 84.66.156.169 20:57, 5 January 2006 (UTC)[reply]

Yep, the auto update just popped up on my PC saying something about "An exploit in the graphics rendering system that allowed a user to execute malicious code blah blah". So that's the end of that fiasco. - Ferret 06:34, 6 January 2006 (UTC)[reply]

Does anyone know what exactly the Microsoft patch did? Onco_p53 11:13, 6 January 2006 (UTC)[reply]

Pretty much exactly the same thing as the unofficial patch did. Disable the relevent function in gdi32.dll from taking the function call. Difference is MS just replaced with a newer version of gdi32.dll, whereas the unofficial patch had to jump through hoops to inject into the (old) dll to block the call. (Ref: see ISC article) -- KTC 03:16, 7 January 2006 (UTC)[reply]

and iirc the ms patch targetted the problem better (and therefore didn't break as much stuff) than the unofficial patch which was forced to use a dirty trick. Plugwash 03:26, 7 January 2006 (UTC)[reply]

It's always easier to fix a problem when you have the source and can recompile. ;-) -- KTC 03:32, 7 January 2006 (UTC)[reply]

The article stated that machines with hardware DEP present weren't vulnerable, and gave a reference to an article that didn't mention this fact.

I've changed the unsupported assertion to something less strong, and added a link to an article that discusses one problem with DEP. Another is that an exploit could be devised that redirects to executable code that isn't intended to actually be executed, e.g. by choosing an offset in a function that causes it to behave differently to what was originally intended. All this means that the advice that DEP works reliably is unjustified and potentially dangerous. It's just an extra layer of protection, and we should make sure not to imply that it isn't. JulesH 12:55, 6 January 2006 (UTC)[reply]

That's because you're reading an updated version of the linked article which has since been changed after MS has released their patch. That's the problem with links in current event article. The linked to page is constantly being change and material which you're referencing might not be there by the time someone come to read it. I can assure you it wasn't an unsupported assertion.

Commenting basing on the current article, the language & linked to article is good. But the article does not say anything new the previously linked to US-CERT article already said (and since deleted for new material). Which is, hardware-enforced DEP work (as far as one know), but software-enforced DEP doesn't. -- KTC 03:26, 7 January 2006 (UTC)[reply]

Hi there. I'm wondering if it would be sensible for Firefox users to use the adblock plugin to prevent the downloading and opening of WMF files in browsers. 217.205.250.130 13:52, 6 January 2006 (UTC)[reply]

The real problem is that the files don't need the WMF extension. Windows identifies image files by content rather than by extension. That means ANY image file extension (JPG, BMP, GIF, and so on) can really be a WMF file in disguise. All the bad guy would have to do is rename whatever.wmf to whatever.jpg, and your filter would fail. Firefox itself may serve as a slight buffer as it uses a non-WMF-capable graphics engine to display, but as soon as it downloads the file and hands it off to Windows- watch out. You would have to filter out ALL image files, not just the WMF's. Your best bet is to get the patch.JeffStickney 22:39, 6 January 2006 (UTC)[reply]

It seems to me we should also include the steps to re-register the DLL after applying the patch, and I can't remember the command off-hand, having had to look it up myself a few days ago. Sherurcij ^{(talk) (Terrorist Wikiproject)} 19:52, 6 January 2006 (UTC)[reply]

It's the same command you use to unregister, only that you remove the -u or /u (which means "unregister"). The default action is to register. --cesarb 20:43, 6 January 2006 (UTC)[reply]

Further, when you unregistered it, the line you typed into the "run" box was likely saved. You don't have to look it up and retype the whole thing. Find it and edit out the "/u". JeffStickney 22:31, 6 January 2006 (UTC)[reply]

There's a silent mode - use /s if you need to use it in a script. - Ta bu shi da yu 12:04, 15 February 2006 (UTC)[reply]

Does anybody know if they would patch the vunerability in internet explorer 7 that is going to be released soon?69.22.224.249 22:16, 6 January 2006 (UTC)[reply]

The vulnerability is not a browser one, but a feature (from 15 yrs ago) of the WMF format itself. It's an issue with the format which is handled by certain operating system dll's, so once you apply the patch MS has now issued, you can go back to IE4 (or before) and you wouldn't be affected (by this vulnerability). -- KTC 03:30, 7 January 2006 (UTC)[reply]

"The official patch supposedly works" -- This bit of the text (under Official patch) bothers me. Has the patch not been tested? Has it been tested and found lacking? Is this statement just wildly NPOV, and the patch works just fine? I don't want to correct it because I don't know that the patch actually works... -- stillnotelf has a talk page 04:13, 8 January 2006 (UTC)[reply]

It works fine. I've changed it. -- KTC 10:53, 8 January 2006 (UTC)[reply]

The patch can cause problems with some display drivers, causing some computers to revert display functions to 16 colours. —Preceding unsigned comment added by 87.232.1.49 (talk • contribs) 18:59, 9 January 2006

Source please? Unless it did something else as well, the patch only disabled something that's been decaprated since Win95. If it's not a legacy system, then it deserves to malfunction! -- KTC 00:45, 10 January 2006 (UTC)[reply]

Another WMF attack vector?. --cesarb 22:49, 9 January 2006 (UTC)[reply]

Can only wait and see. -- KTC 00:47, 10 January 2006 (UTC)[reply]

Found on Slashdot: Steve Gibson alleges that the WMF vulnerability in Windows was neither a bug, nor a feature designed without security in mind, but was actually an intentionally placed backdoor.

• Slashdot article.
• The Windows MetaFile Backdoor? -- Security Now! episode #22 transcript.
• Discussion on grc.news.feedback relating to Security Now!, #22.

--Jakub Narebski 20:30, 13 January 2006 (UTC)[reply]

Oh please. Get real! Is this the same Steve Gibson that was up in arms about raw sockets in Windows and how terrible they will be for the Internet? Sheesh. - Ta bu shi da yu 12:03, 15 February 2006 (UTC)[reply]

Steve Gibson appears to have legitimate concerns about raw sockets. See raw sockets article for why the now disabled raw socket support in Windows XP was considered controversial. --Cab88 16:33, 8 December 2006 (UTC)[reply]

Check http://go.microsoft.com/fwlink/?LinkId=57064 - Ta bu shi da yu 03:11, 15 February 2006 (UTC)[reply]

This is very confusing! The article uses the term WMF. But the file it refers to is named gdi32.dll. So I assume that WMF and GDI vulnerabilities are one and the same thing. And therefore I assume that this statement:

Q: Is IrfanView affected by the MS JPEG vulnerability? A: NO. There is no GDI+ usage in IrfanView.

Here: http://www.irfanview.com/faq.htm

Are all discussing the same subject. If these are indeed separate subjects, the article needs to clearly delineate and enumerate all Windows vulnerabilities related to viewing images.

At this point, I do not understand which vulnerabilities an image viewing program such as IrfanView MIGHT be subject to, so I cannot possibly figure out which ones it IS subject to -- if any. —This unsigned comment was added by 69.87.204.60 (talk • contribs) .

Parsing of the WMF format is implemented in gdi32.dll, but there are other "GDI (classic)" functionality in gdi32.dll. "GDI+" (GDI Plus) is implemented in gdiplus.dll, and is what implements JPEG, PNG, and certain other higher-level functionality implemented on top of gdi32.dll -- Bovineone 18:21, 3 April 2006 (UTC)[reply]

I don't really like the usage of "here is" and "according to this report" style citations in this article. I thought I'd post it here before changing it - some other people might have different opinions. I did find advice on not using these sorts of links on the W3C's website, click here to get there. (click here link intentional!) — Jeremy | Talk 12:15, 9 April 2006 (UTC)[reply]

For these reasons :

• ...to the latest... should be changed as there is no time in encyclopedic articles.
• In Computers NOT susceptible..., the NOT shouldn't be capitalized.
• This is not NPOV : .but potentially susceptible to future versions or as-yet undiscovered exploits.
• All the inserted links should be added to the footnotes.
• The list that follows Infection may also result from: should be well-referenced or contain citations.
• This Other methods may also be used to propagate infection. is POV unless sources are given.
• Risk reduction techniques has a long list, it should instead be a nice prose.

Would need a bit of copyediting it was up for FA nom but for GA it is ok. Lincher 04:06, 9 June 2006 (UTC)[reply]

Hi. Over at the puny Windows Metafile page, the consensus of all two of us who cared was not to merge, but I'm no expert. Incidentally, it looks like that article could use some help from some of you metafiliacs. There's way more info about the exploit than about how the metafile is supposed to work in the first place. Ojcit 06:50, 3 October 2006 (UTC)[reply]

I agree that these articles should remain separate. Moreoever, since these merge requests have been sitting around for a while, and the consensus seems to be to leave the status quo, I am removing the notice in both pages. --Stux 18:44, 16 December 2006 (UTC)[reply]

the citation/refference thingies don't work in the 'accusations' section.

so there :-p --Dak (talk) 01:26, 20 October 2008 (UTC)[reply]

pl guide me how to push the vulnerable patch from server to clients pc and to monitor it

The article says that Microsoft released a patch in 2006, and Windows Vista was released in 2007, which would imply that Vista should not be affected, but the article says that “...versions from Windows XP onwards are more severely affected than earlier versions...” which clearly implies that Vista is affected. Bwrs (talk) 23:07, 19 January 2010 (UTC)[reply]

• Currently, all versions of windows are affected. 190.226.50.130 (talk) 17:41, 12 February 2010 (UTC)[reply]

In my humble opinion, the sentence "The original purpose of this was mainly to handle the cancellation of print jobs during spooling" in the main article is correct.
I have memories of reading documentation in Windows 3.x days describing how to use this 'feature'. As noted, you were to use SETABORTPROC so that a large WMF file could be halted by user request. There may even have been example code testing keyboard input for an abort sequence.
I had no need/did not use this feature but I am sure I read about it when programming in the 90's. —Preceding unsigned comment added by 131.107.0.81 (talk) 21:08, 15 June 2010 (UTC)[reply]

This article seems to contradict itself. (Permanent link to subject of discussion.)

The lead says:

Meanwhile the Affected systems section says:

Which is correct?

Fleet Command (talk) 12:38, 7 September 2011 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified one external link on Windows Metafile vulnerability. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20060317204854/http://blogs.zdnet.com/Ou/index.php?p=146 to http://blogs.zdnet.com/Ou/index.php?p=146

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 07:48, 17 January 2018 (UTC)[reply]