IMPORTANT: WMF Vulnerability Exploited

[melon]

Meh...for those worried, there's the unofficial patch. It works and is a good stop gap until the official patch. I have it installed right now.

If anything, maybe the humiliation of having an effective third-party patch well before the official patch will make Microsoft reevaluate itself. But, understandably, I have my doubts.

Melon

 

[kcnychief]

Meh...for those worried, there's the unofficial patch. It works and is a good stop gap until the official patch. I have it installed right now.

If anything, maybe the humiliation of having an effective third-party patch well before the official patch will make Microsoft reevaluate itself. But, understandably, I have my doubts.

Melon

I don't think Microsoft will re-evaluate itself. There is a reason why 3rd party patch suppliers mention to take theirs off once MS releases one, it's not tested and guarenteed to be stable. My hunch, although I can't confirm because I haven't downloaded, is that the patch is some type of script or batch file that un-registers the .dll or something. But, as I said, I really have no idea.

From a neutral standpoint, it would be interesting to see what happened if Patch Tuesday was tomorrow. I wonder if they would push the update back, or stray from their update schedule whenever it's ready, which they have done before.

 

[madmatt]

SANS / The Internet Storm Center are offering a patch to protect users from the problem. The reputable ISC are putting their backing behind it, and without any other good option, users might be wise to install their patch rather than waiting until the 10th. You can download it here (msi). Once again, the patch is un-official, and is not endorsed by Microsoft (or Neowin for that matter). However, if you trust Microsoft for security, you'll probably be ok trusting this.

Link: http://handlers.sans.org/tliston/WMFHotfix-1.1.14.msi

It has been reported that an office patch will be released next Tuesday (Jan. 10).

I don't know if this has been mentioned because I have no interest in reading the entire thread.

 

[kcnychief]

I normally don't post something so long, but I think this should really be read. I pulled this from an article at Betanews:

"When the MSRC learned of the attacks on December 27, 2005, we mobilized under what we call the Software Security Incident Response Process (SSIRP) to analyze the attack, assess its scope and determine and the appropriate guidance for customers, as well as to engage with anti-virus partners and law enforcement," explained Kevin Kean from the Microsoft Security Response Center.

"Based on that process, we have finished development of a security update to fix the vulnerability and are testing it to ensure quality and application compatibility."

However, the patch won't be available until next week's monthly Patch Tuesday release. The company says it needs time to test the fix and prepare it in 23 different languages for all affected versions of Windows.
"Our goal is to release the update on Tuesday, January 10, 2006, as part of the regular, monthly security update release cycle, although quality is the gating factor," Kean added.

Security experts from numerous companies including F-Secure, Sunbelt and Panda previously called on Microsoft to release an emergency patch as soon as possible, but Redmond officials downplayed claims of such a dire situation.

"Although the issue is serious and the attacks are being attempted, Microsoft's intelligence sources indicate that the scope of the attacks is limited," Microsoft said in a statement. "In addition, attacks exploiting the WMF vulnerability are being effectively mitigated by anti-virus companies with up-to-date signatures."

Full Betanews Article: http://www.betanews.com/article/Microsoft_to_Issue_WMF_Security_Patch/1136316090

 

[muzikool]

I found this in response to the article KC posted.

From CNet News

Ever hear the phrase: speak your mind?

That's no problem for Tom Liston of Intelguardians Network Intelligence LLC, a handler on the Interest Storm Center. In a lively posting on the Internet Storm Center, Liston takes Microsoft to task for its assessment of the security threat of the recently discovered Windows Meta file flaw.

In a posting titled "Oxy-morons," Liston compares Microsoft's security team to Oompa Loompas in the movie Willie Wonka and the Chocolate Factory, err, make that Billy Wonka.

Liston characterizes Microsoft's updated security advisory on the WMF flaw as overly optimistic, compared to the threat that exists.

The advisory notes that although serious and malicious attacks are currently being attempted to exploit the vulnerability, the software giant's "intelligence sources indicate that the scope of attacks are not widespread." Microsoft, as a result, hopes to release a fix when its next monthly patch cycle rolls around on Jan. 10.

"While all of the rest of us were sleeping, it appears that the propeller-heads working on Billy Wonka's Official Microsoft Research and Development Team have been hard at work creating a crystal ball capable of foretelling the future. The only problem: it appears that they made it from rose-colored crystal," Liston notes.

"The merry, lil' Redmond Oompa Loompas are chanting, "our patch isn't ready/ you have to wait/ so keep antivirus/ up-to-date," states Liston's lyrical jingle. "And remember, if something bad does happen to you during the next seven days, Billy Wonka and his Magic Metafiles aren't to blame. You are."

Not a shy guy, that Liston...

A bit harsh, perhaps?

 

[NetRyder]

Why wouldn't M$ at least roll out a simple patch that unregisters the dll until the official patch? Make too much sense, or maybe they just don't give a ****. Sure I can unregister/reregister the dll, but Joe Schmo isn't going to have a clue on how to do that.

You do know that unregistering the DLL breaks the system's ability to display image thumbnails and use any of the image manipulation functionality built into the Windows Picture and Fax Viewer, right? That's not a "simple fix" - it's a horrible workaround because it breaks functionality that millions of people use, and they will have no idea why it happened. Unregistering the DLL is only a stop-gap measure until a better fix is found and thoroughly tested for compatibility.

 

[melon]

I don't think Microsoft will re-evaluate itself. There is a reason why 3rd party patch suppliers mention to take theirs off once MS releases one, it's not tested and guarenteed to be stable.

And I have and have had every intention of uninstalling it when that day comes. But with some websites reporting having been hacked to place in these infected WMF files, I wasn't going to take a chance and then have to spend a long time cleaning things up.

Melon

 

[Perris Calderon]

You do know that unregistering the DLL breaks the system's ability to display image thumbnails and use any of the image manipulation functionality built into the Windows Picture and Fax Viewer, right? That's not a "simple fix" - it's a horrible workaround because it breaks functionality that millions of people use, and they will have no idea why it happened. Unregistering the DLL is only a stop-gap measure until a better fix is found and thoroughly tested for compatibility.

I'm with j79 on this one, I think the makeshift patch should have been made with a warning before it installed and and a multi layered user agreement to make sure they understood which functions would stop working, the risks of using the patch, the possible liability of not using the patch

 

[NetRyder]

I'm with j79 on this one, I think the makeshift patch should have been made with a warning before it installed and and a multi layered user agreement to make sure they understood which functions would stop working, the risks of using the patch, the possible liability of not using the patch

What about users who have automatic updates enabled? Hotfixes are downloaded and applied silently in the background with no notifications until the job has been done.

The average user sees the green shield in the system notification area indicating that a hotfix has been applied, restarts the machine, and realizes that a core feature has suddenly stopped working. That leads to one of two things. An angry customer and tech support calls. Or if the user is a little more comfortable with the system, he/she simply uninstalls the hotfix to restore functionality and starts to lose faith in the effectiveness of Automatic Update. Both very bad consequences.

The chances that a user could get infected is actually lower in comparison to the guaranteed trouble that unregistering the DLL without his/her knowledge is going to cause.

 

[Steevo]

And there is no way to put a little multi-colored shield somewhere to tell a person the patch was installed, and if they want Winders Viewer back to click here?

Mebey they need some skoolin on how to writ dat dere kode? Eh?

Sorry. It is a slough off and underestimation of danger due to the fact that they have been relying on AV and AS companies too long. Then they want to step into the AV-AS business? Scary. AV updates months after the outbreak, and instructions to stop using their AV? To be expected.

 

[Perris Calderon]

What about users who have automatic updates enabled? Hotfixes are downloaded and applied silently in the background with no notifications until the job has been done.

The average user sees the green shield in the system notification area indicating that a hotfix has been applied, restarts the machine, and realizes that a core feature has suddenly stopped working. That leads to one of two things. An angry customer and tech support calls. Or if the user is a little more comfortable with the system, he/she simply uninstalls the hotfix to restore functionality and starts to lose faith in the effectiveness of Automatic Update. Both very bad consequences.

The chances that a user could get infected is actually lower in comparison to the guaranteed trouble that unregistering the DLL without his/her knowledge is going to cause.

obviously they would write it to specifically not install untill the multi layered warning was read

jf j79 has already had to clean half a dozen mschines, it's pervasive enough to give users the option on the temporary fix

 

[j79zlr]

You do know that unregistering the DLL breaks the system's ability to display image thumbnails and use any of the image manipulation functionality built into the Windows Picture and Fax Viewer, right? That's not a "simple fix" - it's a horrible workaround because it breaks functionality that millions of people use, and they will have no idea why it happened. Unregistering the DLL is only a stop-gap measure until a better fix is found and thoroughly tested for compatibility.

I understand, but the alternative is worse, I would say the analogy would be something like, we can fix your brakes, but your radio will stop working. Well I don't want to lose my radio, but I'm pretty sure the breaks are a little more important. This is quite nasty, I don't know if you have dealt with any infected PC's, but they are not simply fixed with an AdAware/Spybot scan.

 

[melon]

I think the point is being lost.

1) They could have made an interim patch that was similar in scope to the third-party solution that did not disable any noticeable functionality for most people.

2) They could then have spent the time combing over the vulnerability to make a permanent patch according to their own timeframe.

It's not like Microsoft hasn't re-released a patch before. I remember one that slowed people's computers to a crawl a couple of years back, so they had to redo and reissue it.

Melon

 

[NetRyder]

I understand, but the alternative is worse, I would say the analogy would be something like, we can fix your brakes, but your radio will stop working. Well I don't want to lose my radio, but I'm pretty sure the breaks are a little more important. This is quite nasty, I don't know if you have dealt with any infected PC's, but they are not simply fixed with an AdAware/Spybot scan.

Yeah, it's a question of trade-offs. The thing is MSRC already has a working patch that's currently undergoing compatibility testing and localization. If the situation was that serious already, why would they hold back the patch until January 10th? They have released patches out of the regular cycle before when the situation demanded it.

From what I've been seeing and reading, there is a possibility that things could get ugly, but it's not bad enough yet that an untested patch which could cause other issues desperately needs to be released right now.

 

[madmatt]

Honestly, who cares? That's what firewalls, antivirus, anti-spyware are for.

Use common sense. I understand that a lot of users don't have any common sense and they open emails from unrecognized senders, visit web sites that shouldn't exist, and install pirated software and shareware.

I would only be concerned if I did any of the activities above or if I'm not smart enough to know better, but then I wouldn't even know about the issue.

 

[j79zlr]

Thats the point though, this is not like most other exploits, firewalls, AV and AS did not and still do not completely stop this one. A simple image on a web page can install malicious software. It doesn't even have to have a WMF extension. Pretty much every AV will stop some of these, but not all. Atleast they were quick on shutting the majority of the malicious web sites down, this is still very much in the wild.

What I don't understand is how the "anti"-spyware vendors SpyAxe and WinHound are still around, this is illegal.

 

[madmatt]

eSafe Gateway is fully protected from this exploit. I don't know about the popular home solutions.

 

[j79zlr]

There are updated snort firewall rules to block this, but it is not 100% safe, and from what I've gathered, it really eats up CPU on the firewall to implement. This should have been patched the same day, I understyand testing and what not, but this is bad. I do honestly think that the problem lies in gdi32.dll not shimgvu.dll, and gdi32.dll is a tightly integrated system library, I guess it depends on how MS patches this. The hexblog fix is more of a workaround, but, that in itslef could have been bought by MS and released as an initial patch.

 

[kcnychief]

I was working on a machine earlier tonight, had a total of 117 infected files by McAfee's findings. Total of 116 variances of the Qoolaid virus, one WMF-Exploit. Everything removed, working like a champ now

 

[X-Istence]

I don't think Microsoft will re-evaluate itself. There is a reason why 3rd party patch suppliers mention to take theirs off once MS releases one, it's not tested and guarenteed to be stable. My hunch, although I can't confirm because I haven't downloaded, is that the patch is some type of script or batch file that un-registers the .dll or something. But, as I said, I really have no idea.

From a neutral standpoint, it would be interesting to see what happened if Patch Tuesday was tomorrow. I wonder if they would push the update back, or stray from their update schedule whenever it's ready, which they have done before.

Nope, the 3rd party patch does not unregister the DLL with a batch file, what it does is what is another vulnerable part, which rootkits use, they use the fact that one can get the location of a loaded dynamically loaded object, patch the memory to point at ones own functions and intercept the function.

That is what his patch does, it intercepts it, checks if it is not the bad variable in question, if it is not, it hands it off to the real function, if it is, it just returns.

That my friends is a clever solution.

This really seems to be a problem with the fact that Microsoft is still supporting legacy code. This function and the paramater, and what it does, is there to support 16-bit/DOS programs. It has everything to do with not enough permission checking, and everything to do with the fact that this is such old code that test cases do not get written for it.

Now, just to break the entire * > Windows thing, this could have happened to any OS. It can happen when a setuid binary does not do proper checking on incoming items and executes certain programs based on user input.

As for how fast Microsoft is fixing this issue, well, it leaves things to be desired, but at least they are working on getting a fix out soon. If supporting 16-bit/DOS is still important to them, I'd suggest them to take a haircomb through the code and see what they can safely remove, rewrite, and or fix. If I were a manager on this task force fixing it, I would get it out faster, the amount of programs depending on this function, with that specific paramater should be practically 0.

I'm with j79 on this one, I think the makeshift patch should have been made with a warning before it installed and and a multi layered user agreement to make sure they understood which functions would stop working, the risks of using the patch, the possible liability of not using the patch

I feel that the makeshift patch of unregistering the DLL would be unsatisfactory, if instead they would contact the 3rd party patch creator, they could use that as a quick fix, as users around the net have reported, nothing breaks. If things do, a quick uninstall would do, warn users ahead of time of what you are doing and why, and there should ne be much problem.

There are updated snort firewall rules to block this, but it is not 100% safe, and from what I've gathered, it really eats up CPU on the firewall to implement. This should have been patched the same day, I understyand testing and what not, but this is bad. I do honestly think that the problem lies in gdi32.dll not shimgvu.dll, and gdi32.dll is a tightly integrated system library, I guess it depends on how MS patches this. The hexblog fix is more of a workaround, but, that in itslef could have been bought by MS and released as an initial patch.

Snort is nice, but indeed, it is really cpu intensive for this one, as on purpose all the images are bigger than the MTU of the network interface, so it needs to queue at least 2 packets to read the contents before being able to discard it.

gdi32.dll is what is going to be patched, it is what the 3rd party patch dynamically patches with the method I described above. The reason they want shimgvu.dll to be unloaded is because the picture viewer in Windows uses this to open the image, and call the function in question. Unloading it causes that function in gdi32.dll to never be available to apps that want to display images, unfortunatly there are a few apps out there, that bypass shimgvu.dll, and instead call other functions to display (IE, Picasso, Google Desktop, ACDsee, and more).