kcnychief said:
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.
perris said:
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.
j79zlr said:
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).