Marc Maiffret, co-founder and CHO of eEye Digital Security, released the following statement on the FD mailing list tonight.
-------------------------------------
eEye Digital Security has created a temporary work around for the current Internet Explorer zero day vulnerability within the IE createTextRange functionality.
This workaround has been created because currently there is no solution from Microsoft other than the workaround to disable Active Scripting. We have personally had requests from various customers and the community to help provide a free solution in the case that companies and users are not able to disable Active Scripting. The workaround we have created, like ones before it, is experimental in a sense and should only be installed if you are not able to use the safer mitigation of disabling Active Scripting.
The workaround is obviously free, and we do not require any registration information to download it from the eEye website.
Should you encounter any problems with the workaround or bugs please send email to alerts@eeye.com with detailed information on the problem you experienced and we will work to fix any bugs in a timely fashion. We will post updates to the website with version numbers and bug fixes should they arise.
Obviously these things are experimental in nature but considering the options of being vulnerable or at least having a fighting chance... Well I think you get the point. Again this is just another mitigation option until Microsoft releases their patch, which last was scheduled for April 11th or 16 days from now.
For more information on the vulnerability and a link to download the workaround please visit: http://www.eeye.com/html/research/alerts/AL20060324.html
-------------------------------------
Very cool stuff.
eEye is gone out of their way to release this test workaround. Since Microsoft doesn't see this as a big enough threat to release their patch...someone has to do something.
Microsoft doesn't want to release the patch "out of cycle" because that will throw corporations for a loop, but it isn't the corporations that are at the highest risk, so what is the deal? It is home users that are getting rootkit’d and botnet’d...where is their patch? Corporations have firewall, 24 hour security employees, up-to-date firewalls...what does Microsoft expect my parents to do??
Why does Microsoft keep forcing people to suggest a move to Firefox?? Umm, and they wonder why Firefox keeps gaining ground on them…
For all u security professional or general geeks, here is how the patch works.
Post to the PM list today by Derek Soeder of eEye Security
-------------------------------------
Once you start installing the patch, the first thing that happens is that the installer copies the JSCRIPT.DLL already existing on the system to "%SystemRoot%\system32\jscript-eeye-patch20.dll". Next, it locates and patches the vulnerable code inside jscript-eeye-patch20.dll, using a generic technique that finds the vulnerability on every system we've tested (a LOT). This allows the patch to be applied on all affected OSes, Service Packs, IE versions, and languages.
So, to emphasize, the original JSCRIPT.DLL is never modified. But how do we get Windows to use our patched version instead?
There are three places in the registry where JSCRIPT.DLL is registered as a COM server -- the following three class IDs under HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID":
{f414c260-6ac0-11cf-b6d1-00aa00bbbb58}
{f414c261-6ac0-11cf-b6d1-00aa00bbbb58}
{f414c262-6ac0-11cf-b6d1-00aa00bbbb58}
Once jscript-eeye-patch20.dll has been successfully created and patched, the installer modifies the default value of the "InprocServer32" subkey under each of these CLSIDs to refer to the patched DLL instead of JSCRIPT.DLL. This change won't affect any already-open Internet Explorer windows, or any other process with JSCRIPT.DLL already loaded, so they're still vulnerable while running, but will cause new processes to use jscript-eeye-patch20.dll and therefore be immune.
Of course, the installer preserves the old values, and will replace them when the patch is uninstalled. But as long as these registry values are set, jscript-eeye-patch20.dll will basically eclipse the Microsoft JSCRIPT.DLL on the system, so once that hotfix finally comes out, any changes it makes to JSCRIPT.DLL will be ineffective as long as the eEye patch remains installed. This is important because history strongly suggests that the MS hotfix will silently fix other unrelated vulnerabilities as well as the createTextRange bug.
To remedy this, the installer places an "eEye JScript Patch Checker" in All Users' Startup folder, that checks the file dates on MSHTML.DLL and JSCRIPT.DLL to see if they're replaced by more modern versions. Part of the problem with the official patch not being available yet (besides the obvious) is that we don't know for certain which files Microsoft will update, or what their dates or versions will be. Unfortunately, this part involves a bit of guesswork, so we use the date that the first IE zero-day appeared (March 16th) as the cutoff -- if either DLL we inspect has a date later than that, then the checker will begin asking the user if he'd/she'd like to uninstall the patch.
Here's the message box text:
"This system appears to have the official Microsoft hotfix for the Internet Explorer createTextRange() vulnerability installed. If the hotfix is not installed, or if you are uncertain, please select No and ask your system administrator or computer support staff for
assistance. "Would you like to uninstall the eEye Digital Security JScript patch now?"
Rather than relying on the checker, though, to detect the presence of the Microsoft hotfix, please uninstall the eEye patch *before* installing the hotfix! That's the only way to ensure that you don't experience any conflicts like a new MSHTML.DLL trying to talk to the older-model jscript-eeye-patch20.dll. Hopefully there will be no such conflicts, but until the hotfix is released it's impossible to say for sure.
-------------------------------------
Check out the source as well.
No comments:
Post a Comment