by Mitja Kolsek, the 0patch Team
[Update 2/22/2020: More details on the exploit code for CVE-2020-0674 were published, making exploitation by new malicious actors more likely.]
Hi 0patch users and supporters around the globe!
With February 2020 Patch Tuesday we began our three-year journey of providing critical security micropatches for Windows 7 and Windows Server 2008 R2 to our users, who could not - or decided not to - use Microsoft's Extended Security Updates.
Status of Windows 7 and Windows Server 2008 R2 micropatches
This first Patch Tuesday brought a large number of security fixes for these platforms, and we've set up a status page for public tracking of our progress on providing associated micropatches, which you can always find at this address:
Status of Windows 7 and Windows Server 2008 R2 micropatches
As you know, it is not our goal to provide micropatches for all vulnerabilities fixed by Microsoft - instead, our goal is to provide micropatches for high-risk vulnerabilities: those that are likely to get exploited (e.g., because details are published), that allow for a remote attack (e.g., through visiting a malicious web page, or opening a malicious email or document). This doesn't mean we won't micropatch publicly detailed local privilege escalation issues, but they will have a lower priority.
Improved Micropatch for CVE-2020-0674
You will remember that after January Patch Tuesday, Microsoft issued an advisory about a remotely exploitable vulnerability in Scripting Engine CVE-2020-0674 that was detected as being used in the wild. There was no official patch from Microsoft and their workaround had some unpleasant side effects, so we stepped in and created a micropatch without such side effects. Both the workaround and our micropatch did prevent functioning of legacy JScript code, so any web page still using it (and we hear from our enterprise users that JScript is still very much alive in internal corporate web applications) would not work properly.
As expected, Microsoft fixed this issue with February Patch Tuesday, but not for Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. In addition, the original reporters of this issue, a Chinese security company Qihoo 360, published a technical article which provided sufficient information about the vulnerability that anyone skilled in this game could easily reproduce it. The latter changed our risk assessment - before the exploitation was limited, but now anyone motivated can build an exploit and start targeting vulnerable Windows computers.
And there are at least as many vulnerable Windows computers out there as there are Windows 7 computers without Extended Security Updates.
So we reproduced the issue and traced the root cause to JScript function sort(), specifically when called using a sorting function, and its binary code implementation in function JsArrayFunctionHeapSort. This function has changed significantly with February updates, but so have many, many others, and we know from previous analyses of jscript.dll that many of these changes are not security related. (One is impressed with how much development effort Microsoft continues to invest in this legacy scripting engine.)
While we understood what the root cause of the issue was and knew what had to be done to fix it, we did not find a sufficiently risk-free method of doing it, at least not yet, and thus decided on a compromise: we would remove the exploitable part of sort()'s functionality, effectively causing
array.sort(sortfunction)
to become
array.sort()
It was our assessment that this change should not have a significant impact on majority of web applications using JScript. (If any 0patch users do experience a significant impact, please contact support@0patch.com!)
Our primary target for this micropatch were Windows 7 and Windows Server 2008 R2 computers, for which we also revoked our initial "workaround" micropatch. However, we subsequently learned that February Windows Updates were causing severe problems for Windows 10 v1903/v1909 users, prompting many of them to likely delay or forgo applying of these updates. Since that would leave them vulnerable to CVE-2020-0674, we ported our micropatch to Windows 10 v1903/v1909 as well (and revoked the associated "workaround" micropatch).
Online Test For 0patch Users
Once we had micropatched this web-deliverable vulnerability, we were able to construct an online test for all our 0patch users to check whether the micropatch is getting properly applied. This is particularly important for Windows 7 and Windows Server 2008 R2 users, who need to have their computers fully updated in order for our post-end-of-service micropatches to apply.
The online test page is located here:
https://0patch.com/poc/CVE-2020-0674/0patch_test.html
To use it, you have to visit it with Internet Explorer 11; Internet Explorer is the only browser using jscript.dll, and we only provided a micropatch for version 11 as this is the only still-supported version on Windows 7 and Server 2008.
Once you open the test page, you will see one of the following:
This means everything is okay; your computer is properly updated for 0patch, and 0patch has applied the micropatch for CVE-2020-0674 to your Internet Explorer, making you not-vulnerable.
This message indicates that our micropatch did not get applied. You may have not applied the January 2020 rollup update on your computer, or are using Internet Explorer version other than 11. Or, you may be on Extended Security Updates, in which case this test doesn't apply to you.
Go ahead, use this test and let us know (support@0patch.com) if our micropatch isn't getting applied.
What's Next?
Being that CVE-2020-0674 was the only remote code execution vulnerability with a published proof of concept, micropatching it was our priority. There are a couple of other issues in our status table that are already making us busy with either recreating a proof-of-concept or already analyzing the vulnerability, but there is one issue that stands out: the LNK vulnerability (CVE-2020-0729), which has "massive exploitation" written all over it. It also reportedly has a proof-of-concept successfully reproduced in the security research community, so once those details are available, we'll have to respond quickly to protect our users.
Cheers!
@mkolsek
@0patch
No comments:
Post a Comment