Updated: February 15, 2020
Like many a techie, I've read the recent flurry of advisories on a new critical vulnerability in the Internet Explorer legacy scripting engine (jscript.dll), and how it's being actively exploited. On its own, this can happen, right. But what annoyed me was the portend of gloom and doom around the Web. Mostly panic, with very little focus on trying to analyze this problem, and see if it can be mitigated in an elegant way.
In fact, Microsoft has listed a workaround - you can deny access to the affected library. But this also causes side effects. You may see problems with printing, access to the group policy editor, and a few other issues. So I sat down and thought, is there a way to reduce the impact of the vulnerability, without actually making the system go all wonky?
The scope of the problem
The vulnerability exists in the (Internet Explorer) scripting engine. This means that any program that calls on this engine could potentially trigger the memory corruption, and potentially lead to an arbitrary execution of code. Prevalently, this means Internet Explorer, possibly Microsoft Office, and maybe some odd legacy applications, which are not likely to be found in the typical home environment.
The solution is to not run Internet Explorer - and avoid opening strange files or links in other programs. Now, this is always true, regardless. The problem is, what if you "accidentally" open Internet Explorer against a page that could trigger this vulnerability?
Don't run Internet Explorer
Windows has had the option to disallow certain applications for a long time. This can be implemented through the registry or the group policy editor (for pro version users), and will prevent listed programs from running. Specifically, launch gpedit.msc, go to User Configuration > System, and then open the policy that reads: Don't run specified Windows applications.
Enable the policy. And then, under Options:, click on Show and add iexplore.exe to the list of disallowed applications.
Now, this works as advertised - but only if you use Windows Explorer or the Start menu to launch the program. It will not block access by other means, nor does it stop applications from using the jscript.dll library. Don't worry, we will get there. I am progressing slowly, linearly.
Similarly, the registry path to add applications is:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies
Image File Execution Options (IFEO)
We have talked about this super-useful and powerful feature in the GWX context. You can use it to change how any which program on your system behaves. Basically, we will use the Debugger functionality, and thus change the execution of iexplore.exe from its default behavior to running an empty cmd shell. Basically, a dummy run that does nothing and invokes no Javascript libraries.
What this will do is let you "run" Internet Explorer, but the entire run will just be a spawning of the command prompt shell that simply exits. This means that no matter how you invoke Internet Explorer, it will not really run, reducing the risk of the jscript.dll library being loaded into memory.
Now, please note, this only affects Internet Explorer, and does not prevent other programs from using the library, like say Microsoft Word showing a document with a malformed embedded object that references the jscript.dll functions. But it reduces the risk of the library being used, especially by a network-capable program like Internet Explorer. Other tools on your system may still require this library, but if they don't necessarily connect to external network resources, then the risks are reduced.
The cool part about IFEO is that it does not require anything beyond setting the registry key. If you want to revert back, just delete the Debugger string, and you will have the old functionality back.
Lastly, if you use anti-malware software, some may see this as a potential IFEO Hijack. Be aware of this fact, and then move on, and perhaps even embrace a smarter way of doing computer security. But that's a topic for another time.
Let's talk about jscript.dll
Now, my work above does not fix the problem. It works around it by reducing the chance of Internet Explorer running. The proper fix is to update the library. Technically, you could "just" copy the new patched version over the old one, and you're done. But the Windows Update mechanism is a bit more complex.
So the mitigation is to remove the executable permission from the library. You can do it on the command line, as the advisory says, or you can do it using Windows Explorer. The reason for the command line is to take ownership of the (system) library, to be able to change its security settings. Alternatively, you can manipulate the permissions by opening cmd (or explorer) through ExecTI, a utility that lets you run programs with the highest privileges, as I've shown you in my list of must-have Windows admin utilities.
What you want to do is remove the Read & execute checkbox mark for all of the listed groups or users. But then, the side effects! For example, the aforementioned Group Policy editor will not launch correctly if execute is denied for Administrators. This also emphasizes the importance of running as standard user, as you could have no execute for Jscript for Users, and you would still be able to use Internet Explorer then, without any effect on system functionality.
Group Policy Editor with JScript.dll not allowed to execute. Messed-up layout.
But then, since this is all there is to it, you can disable Read & execute, and toggle it when you need it, until you can apply the official patch - provided you actually want to apply it. In some scenarios, you might not want to, or be able to, and you might even have to use Internet Explorer. But this is not likely in the home setup. And I'm not talking enterprise security here. So lower your pitchforks. Finally, you can do the same thing for Internet Explorer - remove the execute permission.
Other things - local scripting
Then, if you do need to use Internet Explorer, you can disable Active Scripting under Internet Options. This is old news really, so I'm not going to focus too much on this here. A more practical thing is to avoid accidentally executing Javascript files stored on your local disk, through the Microsoft Based Script Host. This is the default, even on Windows 10. But in reality, there are very few reasons why you'd need to run Javascript files locally, outside the context of your browser.
What you want to do is create a dummy Javascript file, something like file.js. Right click > Open with, and then select a text editor of some kind (under More apps). This means that even if you do double-click on a locally stored Javascript file, it will open as a text file.
Conclusion
Don't let panic be your compass. Some security problems are serious and require scrutiny. But others are not necessarily as dreadful as they may seem, based on the Internet chatter. In this case, yes, this is not a good thing. On the other hand, not running Internet Explorer pretty much solves it. Also, don't be an n00b and randomly execute files left and right, and you should be fine.
In this article, I tried to give you a somewhat calmer overview of what gives, and the options you have. Most importantly, you can use the fabulous magic of IFEO to prevent Internet Explorer from running, no questions asked. This way, you reduce the risk of nonsense, be it an old game launcher that hard-codes to iexplore.exe for messages or announcements, or your own twitchy fingers. You can also disable the execute permissions for the library, and if your system is set up with a standard user, you might not even need to compromise on reduced functionality due to the disabled library. There we go. Enjoy your Webz.
Cheers.