Hum, in the meantime, there is more Info, and a Workaround available...:
https://portal.msrc.microsoft.com/en-us ... 7#ID0EUGAC
Workarounds
Restrict access to JScript.dll
For 32-bit systems, enter the following command at an administrative command prompt:
Code: Select all
takeown /f %windir%\system32\jscript.dll
cacls %windir%\system32\jscript.dll /E /P everyone:N
For 64-bit systems, enter the following command at an administrative command prompt:
Code: Select all
takeown /f %windir%\syswow64\jscript.dll
cacls %windir%\syswow64\jscript.dll /E /P everyone:N
takeown /f %windir%\system32\jscript.dll
cacls %windir%\system32\jscript.dll /E /P everyone:N
Impact of Workaround
Implementing these steps might result in reduced functionality for components or features that rely on jscript.dll. To be fully protected, Microsoft recommends the update be installed as soon as possible. Please revert the mitigation steps
before installing the update to return to a full state.
By default, IE11, IE10, and IE9 uses Jscript9.dll which is not impacted by this vulnerability. This vulnerability only affects certain websites that utilize jscript as the scripting engine.
How to undo the workaround
For 32-bit systems, enter the following command at an administrative command prompt:
Code: Select all
cacls %windir%\system32\jscript.dll /E /R everyone
For 64-bit systems, enter the following command at an administrative command prompt:
Code: Select all
cacls %windir%\system32\jscript.dll /E /R everyone
cacls %windir%\syswow64\jscript.dll /E /R everyone
And the following Sentence is actually maybe "double" or "triple" "Good News" for iMB Users, ah-ah...!, or maybe not...!?:
"
By default, IE11, IE10, and IE9 uses Jscript9.dll which is not impacted by this vulnerability. This vulnerability only affects certain websites that utilize jscript as the scripting engine."
- I don't know, I never installed iMB, but it could be that iMB (all Versions) only uses the "Default" 'Jscript9.dll' (which is not impacted), and doesn't even use the "faulty" 'jscript.dll'.
- If iMB uses those 2 '.DLL''s directly from IE and thus from the '%windir%\system32\' Folder, => Patching IE on a System will also patch iMB directly...!
And this could be very much the Case...! IE for the last maybe 10 years doesn't often get (Security) Updates, but iMB even less often, and never labelled as "Security" Updates, but "New Release"/"New Version", and I always "wondered" about the Security Level of iMB as a Browser...
, but hum, the Developer who created iMacros and iMB was/is pretty clever, ah-ah...!, so I wouldn't be surprised if he thought about that Security/Update Process already when he created iMacros, and implemented iMacros/iMB that it relied directly on the Security/Patch Level of the IE Version(s) installed on the System to avoid to have to release a new (Security) Version every time IE needed to be patched...
I don't know, I never "studied" and decompiled iMB, but that would sound like a plausible and clever Implementation of the Software to me...
- If iMB uses its own Copy of those 2 '.DLL''s that it copies into some '\iMacros\...' Folder (=> 'C:\Program Files (x86)\Ipswitch\iMacros\'...?, for iMB_x32), it will probably be possible to replace the "faulty" DLL (I guess they probably didn't change the Name, or a quick Check on the Size will probably indicate which one is which one...) from the '\iMacros\' Folder with a "sane" one from a patched System, without waiting for @Dev to release a new Version...
(@TechSup to confirm/test all those "Assumptions" of mine, of course...!
)
- (F)CI(M) = (Full) Config Info (Missing): iMacros + Browser + OS (+ all 3 Versions + 'Free'/'PE'/'Trial').
- FCI not mentioned: I don't even read the Qt...! (or only to catch Spam!)
- Script & URL help a lot for more "educated" Help...