Latest Internet Explorer Vulnerability: A Reminder Why the Time to Shift to Microsoft Edge Was Yesterday

Yet another Internet Explorer vulnerability is being exploited even as we speak (or, in your case, read this post). This time, the vulnerability is a zero-day that allows remote code execution. The main culprit lies in the way the Windows scripting engine, jscript.dll, handles objects in memory in Internet Explorer.  

An attacker who manages to exploit this vulnerability would gain the ability to execute arbitrary code “in the context of the current user”—meaning, the attacker can gain the user rights of the user currently logged-on. If the user has administrative privileges, the attacker could take over the system the compromised IE is running on and then perform a variety of actions, like install or delete programs, view files, modify data, delete data, obtain sensitive information, change settings or even create new accounts with full administrative rights.  

How a system can be compromised  

To exploit this Internet Explorer vulnerability, an attacker may put up a malicious site that invokes the vulnerable IE scripting engine AND that site must somehow be loaded by a victim’s IE browser. There are several ways to do this. One is to simply set up a malicious site in the guise of one that normally attracts a large number of gullible visitors—like a porn, gaming or warez site—and then victimize visitors who are using IE.  

Another is through spear phishing. This is a more targeted attack wherein the attacker sends an official-looking email that compels the victim into clicking a link that then leads to an equally official-looking website actually controlled by the attacker. The site can be configured to specifically invoke IE so that the vulnerability can be exploited. There are also other techniques that can be deployed such as drive-by-downloads, malvertising attacks, trojans that contain IE scripting engine content and many others.   

What countermeasures can be applied? 

How can we counter these types of threats? There are a couple of options.  

Wait for the patch 

Normally, the best way to counter a known vulnerability on a piece of software is to apply a patch from the software’s developers. Unfortunately, this is a zero-day and, as of this writing, a patch has yet to be released. Microsoft intends to release the patch on Update Tuesday, a.k.a. Patch Tuesday, which always falls on the second Tuesday of each month.  

The reason why Microsoft prefers to release patches on a regular basis and not as soon as a patch is ready is so that companies have ample time to plan quality assurance (QA). QA is an essential procedure that ensures nothing breaks when changes are rolled out in a production environment.  

Existing mitigation factors 

For some systems, even if those systems have Internet Explorer running on them, nothing needs to be done. IE instances running on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 are relatively safe. That’s because, in these particular operating systems, IE runs in Enhanced Security Configuration by default.  

When enabled, Enhanced Security Configuration can minimize IE’s exposure (and in turn, the server’s exposure) to attacks that utilize web content and application scripts, such as the ones that are being used by attackers exploiting this zero-day IE vulnerability. 

However, this mitigating factor only applies to websites that haven’t been added to IE’s Trusted Sites Zone. If you’ve somehow unwittingly added a malicious site there, then the vulnerability could still be exploited.  

Another thing worth noting is that jscript.dll (the scripting engine that has the Internet Explorer vulnerability) isn’t the only scripting engine existing on Windows systems. There’s also Jscript9.dll, which doesn’t have the vulnerability. Jscript9.dll is the more recent version and is, in fact, the scripting engine that Internet Explorer 9, 10 and 11 use by default. So these versions of IE are supposed to be safe from the vulnerability.  

The problem is, jscript.dll is still being retained for legacy websites. Those websites are allowed to explicitly invoke this older engine to perform certain functions. Because this older engine can be invoked by any site that needs it, malicious sites can take advantage of that privilege as well and infiltrate a now-vulnerable system.  


Since the root of the problem is really jscript.dll, Microsoft has provided some workarounds that enable users to disable the problematic scripting engine. These workarounds will have to do until a patch is released.  

For 32-bit systems, you can run the following commands in an administrative command prompt. The first command allows you to take ownership of the jscript.dll, while the second command sets the “everyone” user account permissions for it to deny all. This means that everyone can’t use, modify, read, write or do practically anything with the jscript.dll. 

takeown /f %windir%\system32\jscript.dll  

cacls %windir%\system32\jscript.dll /E /P everyone:N 

A similar set of commands are also provided for 64-bit systems. Note that there are four commands all in all for 64-bit systems because these systems have jscript.dll for 32-bit and 64-bit. 

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 

There are, however, some side effects when you implement these workarounds. Other legitimate applications that rely on jscript.dll will also have limited functionality. For example, you may encounter Windows Media Player issues and printing errors.  

That’s not all. You also need to undo these workarounds once you’re ready to perform an update. The command for 32-bit systems is: 

cacls %windir%\system32\jscript.dll /E /R everyone 

And the commands for 64-bit systems are: 

cacls %windir%\system32\jscript.dll /E /R everyone  

cacls %windir%\syswow64\jscript.dll /E /R everyone 

Again, these commands should be executed in an administrative command prompt. 

Could we just move on from Internet Explorer? 

We can apply security patches, perform the recommended workarounds and enable Enhanced Security Configuration all we want—but that won’t eliminate the root of the problem, which is Internet Explorer itself. IE has so many vulnerabilities that a lot of exploit kits (EKs) designed to target those vulnerabilities are around. Spelevo EK, Fallout EK, RIG EK, GrandSoft EK and Purplefox EK are just some of the many exploit kits out there known to target IE vulnerabilities.  

This therefore begs the question: why are people still using Internet Explorer? Or, for that matter, why is Microsoft still bundling it in even the latest versions of Windows or Windows Server? The answer is actually quite predictable: Internet Explorer is there as a compatibility tool. It’s there because a lot of the legacy apps and websites that companies use were specifically designed for it. 

Microsoft’s penchant for treating Internet Explorer as a compatibility tool stretches back to IE’s early days. In IE6, they introduced “Standards Mode” and “Quirks Mode.” Standards Mode was for websites that conformed with W3C standards, while Quirks Mode was for those that didn’t. In IE7, they supported more W3C standards. But at the same time, they also supported older standards through an IE6 rendering engine. In IE8, they supported even more standards. But again, for the sake of backwards compatibility, they still supported older standards through built-in IE6 and IE7 rendering engines. 

The problem here wasn’t just the fact that IE always had a way to support legacy websites—it was also in the manner IE determined whether to switch to some “legacy-friendly mode” or remain in the standard-compliant mode. The only determinant was usually the presence of the right DOCTYPE declaration. The presence of the right DOCTYPE, which required a properly formatted document type definition or DTD, would prompt IE to enable standards mode.  

Unfortunately, most developers don’t bother entering a declaration, let alone a properly formatted DTD. So even if the rest of the website conformed to standards, IE would still end up invoking the older, less-secure mode.   

IE11, the last Internet Explorer browser, introduced some major improvements security-wise. However, just like its predecessors, it has remained a compatibility tool. Microsoft isn’t planning on supporting new web standards on Internet Explorer. And since more developers are now building sites that are conformant to W3C standards, Internet Explorer is becoming more and more obsolete.  

If your organization prefers to stick with Microsoft products, you’re better off migrating from Internet Explorer to Microsoft Edge. Not only does Microsoft Edge offer several new features, it’s also more secure. For starters, it doesn’t support often-exploited technologies like VBScript, JScript and ActiveX controls, opting instead for an extension system like Google Chrome. These extensions are offered through the Microsoft Store and require approval. Microsoft Edge also removed support for legacy IE document modes, further reducing its attack surface. 

For many years, Internet Explorer and the technologies it supported have been staple fare for exploit kits and other forms of malware. This in turn exposed the companies who used them to cyberattacks and malware infections. If the security of your endpoints is important to your organization, it’s time to give Internet Explorer a rest.