Derek Soeder posted a description of how the patch works to the Patch Management mailing list. It does some pretty cool stuff. Maybe we should develop a temporary patch installer standard, as it seems Microsoft may force this habit more often.

Begin Quote:

We've had some questions about how the patch works, so here's an
overview. PM is a smart crowd and some of y'all might need this info or
might just be curious.

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.

I hope this helps you all better understand our patch and determine if
it's right for your systems. Please e-mail alerts@eeye.com if you have
any questions. Be safe...

-- Derek