A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer, aka ‘Scripting Engine Memory Corruption Vulnerability’. This CVE ID is unique from CVE-2020-0673, CVE-2020-0710, CVE-2020-0711, CVE-2020-0712, CVE-2020-0713, CVE-2020-0767.

Recent assessments:

sjossi at March 09, 2020 10:49pm UTC reported:

Summary

First published in a Microsoft out of band advisory, this vulnerability was detected as exploited in the wild by Google’s Threat Analysis Group. No further details were given in the advisory other than the fact that it’s a vulnerability in the JScript interpreter. This reduced the attack surface to Internet Explorer and excluded Edge. Furthermore, the website had to force Internet Explorer’s Compatibility Mode for IE8 or lower.

Exploitability

The exploit is a use-after-free vulnerability, giving the attacker remote code execution in the users context. The user has to load the weaponized website, so it requires getting the user navigate to a malicious page. Furthermore, in the default configuration, Internet Explorer would ask in a separate dialog to enable ActiveX content, requiring further user interaction.

Unfortunately these hurdles can be lowered in a specialized attack by either attacking a often visited website, abusing configured whitelists (as is often the case for business applications) or targeted phishing attacks.

Pre patch situation

This vulnerability was hotly debated when it was first published, because there was no patch available yet and the mitigation proposed by Microsoft was not satisfactory. Disabling access to the jscript.dll would break many applications that internally relied on old JavaScript or JScript features. Most notably, PAC would not work anymore and client computers could lose internet access. All applications would have to be tested for jscript.dll usage and hope that they didn’t break.

Post patch situation

The patch mitigated the exploit, so patching is advised. It is not known if similar attacks could still be found. The similarity to CVE-2019-1429 and the fact that the Project 0 Bug for CVE-2019-1429 could be used to verify access of the DLL could lead to believe that similar vulnerabilities could be found in the future.

gwillcox-r7 at November 22, 2020 2:15am UTC reported:

Summary

First published in a Microsoft out of band advisory, this vulnerability was detected as exploited in the wild by Google’s Threat Analysis Group. No further details were given in the advisory other than the fact that it’s a vulnerability in the JScript interpreter. This reduced the attack surface to Internet Explorer and excluded Edge. Furthermore, the website had to force Internet Explorer’s Compatibility Mode for IE8 or lower.

Exploitability

The exploit is a use-after-free vulnerability, giving the attacker remote code execution in the users context. The user has to load the weaponized website, so it requires getting the user navigate to a malicious page. Furthermore, in the default configuration, Internet Explorer would ask in a separate dialog to enable ActiveX content, requiring further user interaction.

Unfortunately these hurdles can be lowered in a specialized attack by either attacking a often visited website, abusing configured whitelists (as is often the case for business applications) or targeted phishing attacks.

Pre patch situation

This vulnerability was hotly debated when it was first published, because there was no patch available yet and the mitigation proposed by Microsoft was not satisfactory. Disabling access to the jscript.dll would break many applications that internally relied on old JavaScript or JScript features. Most notably, PAC would not work anymore and client computers could lose internet access. All applications would have to be tested for jscript.dll usage and hope that they didn’t break.

Post patch situation

The patch mitigated the exploit, so patching is advised. It is not known if similar attacks could still be found. The similarity to CVE-2019-1429 and the fact that the Project 0 Bug for CVE-2019-1429 could be used to verify access of the DLL could lead to believe that similar vulnerabilities could be found in the future.

Assessed Attacker Value: 3
Assessed Attacker Value: 3Assessed Attacker Value: 1