More options on protecting against recent IE vulnerabilities on a domain

re: More options on protecting against recent IE vulnerabilities on a domain

jesper — Wed, 27 Sep 2006 22:11:36 GMT

Not being able to enforce the policies was the wrong way to say it. The difference is that settings outside of the policies nodes are "preferences." They are tattooed into the registry and cannot be easily undone. They can be enforced strictly speaking.

re: More options on protecting against recent IE vulnerabilities on a domain

Romeo — Wed, 27 Sep 2006 16:44:56 GMT

1. Sorry for the lousy layout of the script. will post it again with tags hope that works in this blog: 2. what do you mean about "can't be enforced". when connected to the domain at least every 2 hours the computer policy is applied. Your setup is enforced with a reboot and must also have contact to the domain to get the script from the policy. When forcing a reboot the adm gets applied as well as your script. Or am I missing something? 3. when putting a minus before a key in a reg file it gets removed. so put
[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D7A7D7C3-D47F-11D0-89D3-00A0C90833E6}]
in your enable part.
CLASS MACHINE CATEGORY "Microsoft\Advisory\Workaround" POLICY "925444" KEYNAME "SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D7A7D7C3-D47F-11D0-89D3-00A0C90833E6}" EXPLAIN !!help VALUENAME "Compatibility Flags" VALUEON NUMERIC 1024 VALUEOFF DELETE END POLICY END CATEGORY [strings] help="Sets the kill bit on the Daxctle.ocx suggested by microsoft as a workaround in their advisory. see:\nhttp://www.microsoft.com/technet/security/advisory/925444.mspx\nfor details.\n\nCaution:\nTo revert the workaround once a patch is avaible don't delete the policy, but just set it to disable"

re: More options on protecting against recent IE vulnerabilities on a domain

Jonathan Starr — Wed, 27 Sep 2006 15:46:11 GMT
I have had an issue with the workaround, people using Sage Line 50 Manufacturing/Financial Controller may find that it corrupts its company file at startup after applying the update (approx 30% of my machines had problems). This is easily fixed by re-installing the last hotfix, Sage had no idea why this happens and the hotfix doesn't touch/adjust permissions for the VML DLL or the DAXCTL killbit...... I have now modified the script to only do the killbit, and to reregister the DLL, and the official VML patch has been installed with zero issues. Thanks for the script!

re: More options on protecting against recent IE vulnerabilities on a domain

jesper — Wed, 27 Sep 2006 13:45:25 GMT

Torgeir, that's the trick. I had forgotten about the ~d and ~p parameters on the argv[0] variable. Not sure how I could have forgotten those, but I did. Pitiful really...

Romeo, that script rocks! I was initially going down this route, but since it can't be enforced I stopped working on it. Very nice though. The nice part about using ADM templates is you can delete the value, which is more of a true reversal than setting it to null.

re: More options on protecting against recent IE vulnerabilities on a domain

Romeo — Wed, 27 Sep 2006 13:10:45 GMT
I've written an adm so that the kill bit for the Daxctle.ocx can be set using the computer policy. As the registry is modified in part not suggested to be touched by policies you have todo the following to see the policy in the editor: "View"->"Filtering..." an then uncheck the last checkbox ("Only show policy settings that can be fully managed") ---------------------------------------------- CLASS MACHINE CATEGORY "Microsoft\Advisory\Workaround" POLICY "925444" KEYNAME "SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{D7A7D7C3-D47F-11D0-89D3-00A0C90833E6}" EXPLAIN !!help VALUENAME "Compatibility Flags" VALUEON NUMERIC 1024 VALUEOFF DELETE END POLICY END CATEGORY [strings] help="Sets the kill bit on the Daxctle.ocx suggested by microsoft as a workaround in their advisory. see:\nhttp://www.microsoft.com/technet/security/advisory/925444.mspx\nfor details.\n\nCaution:\nTo revert the workaround once a patch is avaiable don't delete the policy, but just set it to disable" -----------------------------------------------------

re: More options on protecting against recent IE vulnerabilities on a domain

Torgeir Bakken (MS MVP) — Wed, 27 Sep 2006 09:43:34 GMT
Hi Jesper, It might be an issue then using %0\.. in startup scripts then, or maybe with UNC paths. Parsing %0 instead should always work I think: set LaunchPath=%~d0%~p0 echo %LaunchPath% From running "for /?": %~dI - expands %I to a drive letter only %~pI - expands %I to a path only

re: More options on protecting against recent IE vulnerabilities on a domain

jesper — Tue, 26 Sep 2006 20:13:25 GMT

Earl, yes, the user running this would have to have administrative rights. That is why I recommend running the script as a startup script instead of a logon script.

Steve, I think the support lifecycle for IE 7 would be the same as for IE 6? It was supported with the usual n-1 support policy where they supported it for five years. I have no evidence to support or refute that expectation, but that seems logical.

re: More options on protecting against recent IE vulnerabilities on a domain

Earl — Tue, 26 Sep 2006 19:55:45 GMT
Inorder for this batch file to run in a logon script, wouldn't the person have to administrative rights to register or unregister a dll.

re: More options on protecting against recent IE vulnerabilities on a domain

Steve — Tue, 26 Sep 2006 16:58:36 GMT
Jesper, It is interesting that neither of these are vulnerabilities in IE7. It does tell me that there are more than graphical changes between the two browsers even before the IE7/Vista combination. I wonder what the support lifecycle policy will be for a free browser? Will it be as long as the 12/24 month timeframe? Logically you would want Microsoft to spend their efforts in hardening one code base rather than two. It just would be nice if a Microsoft person reading this blog would start to think about how long IE6 will be supported so that corporate developers need to know when they need to support IE7 as an option and need to remove IE6 as it will no longer be patched. P.S. Today was the first day that I noticed that CVS.com allowed IE7 browsers to view their site. Besides that, and a warning from Google calendar, I have only seen minor graphical errors in public WebPages.

re: More options on protecting against recent IE vulnerabilities on a domain

jesper — Mon, 25 Sep 2006 14:10:52 GMT

Torgeir, I tried that, but it does not seem to work for me. The %0 resolves to the full path name of the script, so let's say that is

\\domain.local\sysvol\domain.local\policies\<someguid>\machine\scripts\foo.bat

When you append \..\ to it you get something entirely wrong:

\\domain.local\sysvol\domain.local\policies\<someguid>\machine\scripts\foo.bat\..\bar.reg

The regedit tool will parse that command and try to add foo.bat to the registry, not the bar.reg file that I want.

re: More options on protecting against recent IE vulnerabilities on a domain

Torgeir Bakken (MS MVP) — Mon, 25 Sep 2006 10:12:27 GMT
Hi Jesper, To access a registry file from a bat/cmd based startup file, you can use the %0\..\ trick (as long as the reg file is placed in the same folder as the bat/cmd). In a bat file, %0 contains the path (inclusive the file name) to the bat file itself. So this should work (using .. to get rid of the bat file name from the path string): regedit /s %0\..\DAXCTL.reg

re: More options on protecting against recent IE vulnerabilities on a domain

Shadow — Sat, 23 Sep 2006 08:57:23 GMT
The unregister dll command is useless, but it seems some see a different problem than I. Mines a total crash, useless could well be an overstatement since the most recent crash is much better apparent coding by the oponent, as usual, unless such unregistering of the dll and the other advice for the other recent 0-day is the cause of such intensified crash not seen since originally had to shove the data down microsofts throats in order to get the page http://www.microsoft.com/technet/security/Bulletin/MS04-028.mspx written up way back when. Then wasn't their a long delay before XP, if not then XP sp2, was included in the microsft security bull. Perhaps if I played with what your seeing because I visit no such websites you claim as the only cause.