Two Unofficial IE Patches Block Attacks
Pentrex writes "eWeek reports that two well-respected Internet security companies (eEye and Determina) have released unofficial patches to correct the vulnerability being exploited to load spyware, bots and Trojan downloaders on Windows machines. Microsoft isn't sanctioning the third-party patches, which include source code for review. As always, the advice is to weigh the risks before opting for an unofficial hotfix."
I don't even understand how they manage to *write* third-party patches. I mean, it must be hard as hell to do without the IE source code. I think they write a separate DLL which acts as an intermediary to the flawed insecure library or something, but it sounds like an enormous pain-in-the-ass process. Or do these companies have access to MS code through Shared Source program or something?
Yep, the more I watch the ills that befall the Microsoft-bound, the more I'm happy with my decision to go Linux-only a few years back.
My bicyles
In an old interview Bill Gates said, and I paraphrase, "people don't pay for bug fixes." This explains a lot.
A Government Is a Body of People, Usually Notably Ungoverned
It would be interesting to see microsfts official patch when it becomes availible and attempt to see how close it is to these unofficial patches.
Maybe the code would be completley different but would it achieve its goal by going about the same ways as the unofficial patch? Or would it be patched on a level deeper then we could access. I guess the most interesting part would be that a third party without access to the source code could actualy come together with a solution before microsoft. What would be more interesting is seeing how close those solutions match match each other. Sort of a test to how these third party programers can predict the neccesity or orders of different code they only have limited access to.
Then how do you expect debugging to work? Pretty much all OS's offer an API to let the debugger read/write bytes from program memory. A similar hack could be done on Linux by writing into /proc.
Then how do you expect debugging to work? Pretty much all OS's offer an API to let the debugger read/write bytes from program memory. A similar hack could be done on Linux by writing into /proc. - debugging could be done in read only mode, but if necessary it could be done in a simulated (virtual machine) environment without such security restrictions. You cannot insist that this 'feature' is a good thing for application security.
You can't handle the truth.
No, applying patches is not free. But you are missing the point. If patching was a fairly rare occurrence, then it would not be nearly the problem that it is. release a million little patches as soon as that individual patch is done - you probably thought that was an overstatement; it is not. Microsoft just patches far too much to make updating their products anything but a continual hassle.
From descriptions of the fix elsewhere here, it is a stupid mistake that never should have made it through any kind of testing that I routinely run my code through. So why the hell did it make it through Microsoft's superior testing that they have guaranteed since making security "job one" [just a hint of sarcasm there].
Perhaps the problem is really one of testing and verifying the code before it sold to a trusting customer base in the first place! That's right, you heard me; I too am blaming the customer: they fscked up! they trusted Microsoft to actually do something about making their code more secure!
Not in a pinch, but regularly. You can't monitor a WSUS server without it.
Of course, IE on that particular network has a proxy server of 127.0.0.1 pushed out via group policy, with an exemption for the intranet. You could sneak around that by installing a proxy server on the machine you're using, but most of my users aren't that sharp. I've got Firefox 1.5.whatever running on everything now, so I can let my users off the leash a little.
The only thing I miss about IE is the ability to push settings to the browser via group policy. It's nice to be able to centrally manage an application like that. I haven't found a way to do that for firefox (HINT HINT).
There are some people that if they don't know, you can't tell 'em.
This 'patch' isn't accessing or modifying the memory of 'another application'. What these vendors have created is a DLL that can be loaded by an application to patch the mshtml dll instance in memory for the application in which it is loaded.
:P
Next they use the AppInit_DLL registry key, which essentially forces the Operating System to load this DLL into all applications that link against user32.dll (I think), hence no hackery is going across address space boundaries, there is nothing wrong with self modifying code.
Next you will be asking why this little DLL injection key exists, well it's useful, for making unofficial application patches for one thing, and it has other legitimate uses as well although I believe the key is now depreciated in favour of cleaner methods