.ANI Vulnerability Patch Breaks Applications 164
Jud writes "Microsoft's fix for the .ANI vulnerability was part of Patch Tuesday yesterday. However, all is not well with the update. Reportedly, installing the patch will break applications such as Realtek HD Audio Control Panel and CD-Tag, which mentions they are affected by the problem on their main page. A hotfix is currently available from Microsoft, however their current position is this is an isolated problem and the fix is not planned to be pushed out through Microsoft Update. "
Other affected programs: Tugzip... (Score:5, Informative)
This was not patch Tuesday (Score:5, Informative)
Realtek HD Audio exists on a lot of PCs... (Score:4, Informative)
Seems like this isn't really an "isolated" problem, but a fairly common one if you own a desktop made in the last year or a recent laptop...
Re:Hehe (Score:4, Informative)
Re:This looks like something vendors could fix. (Score:1, Informative)
Re:Realtek HD Audio exists on a lot of PCs... (Score:3, Informative)
Re:Point of Order: (Score:3, Informative)
http://www.w3.org/TR/CSS21/ui.html#propdef-cursor [w3.org]
In other words, *something* has to be able to load and process the mouse cursor. And if the thing that loads and processes the mouse cursor falls prey to a buffer overflow, then you've got yourself a vulnerability. Since it's the OS that handles and draws the mouse (so it's not an IE thing; FF will fall prey to this too), it's the OS that handles the mouse cursor, so a buffer overflow there means that it's the OS that gets compromised--the very same thing could happen in any other OS if there was a similar mistake. So they forgot a length check. Shit happens.
In actual fact (Score:3, Informative)
Yeah, WGA sucks, but software updates will come either way.
Also, to say Linux is completely independently modular isn't entirely accurate either (although, in fairness it's not like I completely disagree). Upgrading kernels (due to 'serious' security vulns) will break more things than I'd like for instance - my (yes I know, proprietary) NVidia drivers will be the first victims.
Finally, you think MS don't feel your patch-pain? Just by working for them in one form or other you've subscribed your machine to every patch, patch-for-the-patch, and patch-for-the-hacked-patched-service-pack that gets tested; all before releasing to a unsuspecting public, almost every day, just so you get as little bother staying secure with as little hassle as possible. It's not a pretty sight sometimes.
MS build/release system? (Score:4, Informative)
Normally clashes of base addresses happen all the time. For most DLLs the base address is sort of a suggested location, the OS load the DLL to this area if it can, but will "relocate" DLLs to free memory area if that space is taken. User32.dll isn't allowed to be relocated for some reason (a very good reason, I'm sure). If it's space is already taken (by HHctrl) the program using it cannot load. HHCtrl.ocx has no problem being relocated, but this will only happen if it's loaded after user32.
I'm surprised that anyone could manage to make an application that would load these DLLs in this bad order - but that's not the point I guess. Usually you'd HAVE to call a function in User32.dll long before loading anything COM - esp an HTML help control (which is what hhctrl is).
Re:A big ha-ha to vendors using animated cursors (Score:2, Informative)
This isn't Microsoft's fault (Score:3, Informative)
The change that broke these applications was changing the base address of user32.dll (from 77D40000 to 7ED10000 I believe). The programs that broke were using the 7ED10000 range. When user32.dll can't load at its desired address, it will fail to start the process. DLLs hard-linked by an EXE will be loaded before user32 or kernel32 if they are the first in the import table. Once loaded, user32.dll can't load at its desired address and will get relocated. user32.dll doesn't like this and aborts starting the process. This happens even if the bad DLL is relocatable, because preferred addresses are first-come, first-serve.
The entire 60000000-7FFFFFFF address range is reserved for Microsoft DLLs and special memory. Don't stick your own DLLs in there! (This address range is true of Win64 as well: just add 8 zeros to the front.)
As for why user32.dll and kernel32.dll don't relocate like other DLLs: so many badly-coded programs that do DLL injection assume that the addresses of LoadLibraryW, etc. in other processes are the same as the ones in their own processes. Almost all DLL injection code snippets assume this, and it's just wrong. The proper way is to use either EnumProcessModules or CreateToolhelp32Snapshot to list all the DLLs in the target to find the one you want. The correct address to use is then remote_function = local_function - local_dll + remote_dll. The types HMODULE, HINSTANCE, and IMAGE_DOS_HEADER * are equivalent, so just cast to a DWORD_PTR.