.ANI Vulnerability Patch Breaks Applications
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. "
My archiving application of choice, Tugzip is also affected by this update and the mentioned fix took care of the problem.
Microsoft breaks something when patching something else? I'm surprised. Really. I am. No, really. I am.
Patch Tuesday is the second Tuesday of each month. This was an out of cycle patch released.
They released a patch yesterday, discovered problems with it since yesterday then fixed it today. Yet you've been hearing about these problems for weeks?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I just wanted to make a quick post before I see all the standard lame M$ bashing gets out of hands from a ton of idiots that are most likely using Windows while posting.
This is exactly why it takes Microsoft so long to put out patches sometimes. Unlikely all these free and open source packages, Microsoft Windows is actually used by tons of users at home and in the business world. People need their machines to do their daily activities and jobs. This is why so much testing is needed before something can just be shoved out there. This is why you tend to see this sort of thing from patches released out of cycle. It obviously has not and could not have been tested as much (and yes sometimes problems occur with patch Tuesday patches).
You might not see as many issues with *nix based systems. Why? Well, there just are as many users. This might sound like a cliche but it is a fact. Look at when official Redhat patches and other updated packages actually come out. They come out days, weeks, and months later. Sure there is some patch that some random guy hatched together -- the power of open source!! However, if you were to apply that untested P.O.S. across the world in tons of real environments, you'd probably have a shitton of problems.
This does not excuse problems with patches, but at least it came quicker. Remember, M$ has to release stuff that fortune 1000, government, home users, and everyone else can live with. Pushing some patch 30 minutes later for an OSS package that 2000 rag tag home users use.. just isn't the same.
You know, it's really starting to get to me, everyone beating on MS all the time. I mean, when you're the biggest, a lot of times your flaws stand out easier. Really, so what if a bunch of geeks on their spare time can write a 3D interface which performs better, and existed much earlier than the product of ten times as many full-time professionals? So what if you can do awesome things like formatting an empty file with its own filesystem? I mean, a huge security vulnerability in animated mouse cursors, and then releasing a patch that breaks more than it fixes... that's a mistake anyone can make, right? Well... apparently except for Linux, Apple, Amgia, Palm, BSD, or... well, pretty much anyone else.
.NET is one of the best IDEs that I've ever used, etc.) but really, these are some mighty clumsy mistakes to be making considering the magnitude of some of their more powerful clients...
Sarcasm aside, how exactly did it come to pass that the guy who wrote the code for animated mouse cursors managed to open an "extremely critical" security vulnerability in the process... and then how did it become so important that fixing it breaks applications which relied on said bug?
I'm sorry, I'm not entirely 100% anti-MS (XBox Live owns, Visual Studio
Not So Random
A lot of machines have the Realtek HD Audio thing in them to provide audio - notably most of the Core/Core2 based ones (HD Audio is a standard by Intel, Realtek being one of the first to offer it).
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...
But of course it's available if you do want it.
Naturally Linux Genuine Advantage is open source, and not to be outdone by Microsoft platform hackers a hack is available to auto-certify LGA without actually contacting the LGA server.
Help stamp out iliturcy.
"their current position is this is an isolated problem"
I have a fairly new Dell XPS600 (1 year old) and the update borked my machine due to the realtek program. I got some obscure message about how rtdcpl.exe was performing an illegal access trying to move some OCX DLL.
I was able to solve the problem by Google Searching and installing the MS hotfix. The only problem now is that "hotfix" makes it so I have to wait about 1 minute longer after I log in before I can access the internet. I used to be able to pop-up IE right away and surf but now if I do that, I get the error page for site not found for about 1 minute before things start working normally.
I don't know how isolated it can be since Dell alone has sold millions of PC's with realtek audio chipsets.
That is your root cause of the problem. Stop using IE, all your problems will go away.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
The screw up is in Microsoft's release system allowing hhctrl.ocx and user32.dll to be shipped with the exact same "DLL Base Address". They both share address 0x7E410000. I'm sure Microsoft has a system to prevent this, but either someone didn't follow it, or the system has flaws.
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).
What bothers me is that it makes me feel like this "fix" may not even patch the real problem.
You see, moving where a DLL is stored in memory might break the proof of concept, but it might not actually fix the vulnerability. Sure, the code it hooked into before in order to hack the machine won't be in the same place, but it might well be possible to fix the exploit to point to the code's new location.
In short, I wonder if they're playing tricks to make it more difficult to exploit without actually fixing the underlying problem?