Microsoft has brought forward a replacement patch for CVE-2016-7237. The details were released by Nicolas Economou from Core Security. The replacement patch was due for release on February 14. However, after Core Exploit issued an embargoed blog about the issue to press, Microsoft told them they would bring the patch release forward. It is now live as part of yesterday’s Patch Tuesday release.
What is CVE-2016-7237?
It is a vulnerability discovered originally by security researcher Laurent Gaffié. Using this vulnerability an attacker can crash the Windows Local Security Authority Subsystem Service (LSASS). This causes the target machine to reboot within 60 seconds. It is present in all versions of Windows from Windows XP to Windows 10 and on 32-bit and 64-bit versions. As this affects server and client OS, it can have a significant impact in production environments.
Gaffié said that: “local privilege escalation should also be considered likely.” Microsoft agreed with him and in its original patch issued on November 8, 2016 it warned: “An attacker who successfully exploited this vulnerability could elevate their permissions from unprivileged user account to administrator. The attacker could then install programs; view, change or delete data; or create new accounts.”
Alongside his blog describing CVE-2016-7237, Gaffié published Proof of Concept (PoC) code to show how it works. It is this PoC code that is at the root of Economou’s separate investigation.
Why has Microsoft issued a second patch?
Economou discovered a problem with the Microsoft patch when he went to validate it. After applying the PoC code to Windows 7 and Windows Server 2008 R2 he found the vulnerability still existed. This raises some serious questions about the level of testing carried out by Microsoft on its original fix. Issuing a patch for a vulnerability that is easily shown to not work creates a false sense of security for customers.
This has another impact inside IT departments trying to track down bugs. Their first response is normally to check if the patch was applied. If the answer is yes, they then spend time looking for an alternative cause to the problem. This wasted time creates frustration for operations teams and customers.
The problem here is more complex than a patch that didn’t work. Economou discovered that when he applied the PoC code to unpatched installations of Windows 8.1 and Windows 10 he couldn’t replicate the vulnerability. This is because Economou says Gaffié and Microsoft misunderstood what the real issue was.
Economou originally sent out his findings last week to press under embargo. Microsoft asked that he hold off publishing until yesterday. It then included a new fix for the problem with the details in Microsoft Security Bulletin MS17-004.
Conclusion
There are a couple of big issues here for customers. Microsoft and Gaffié appear to have not tested the original PoC code against all versions of the Windows OS. Microsoft then failed to do an effective due diligence test on the patch that it issued in November. Luckily for them Economou decided to check the patch worked and discovered it didn’t. Without that cross check it was still possible for an attacker to exploit earlier versions of Windows. With many companies still running Windows Server 2008 r2 and Windows XP they are still at risk of this attack. It is also another reason for them to update their OS to a fully supported version
While researchers may have seen this as a minor issue to a vendor it is more serious than that. Look at hacking forums and as soon as a patch is released there are people testing PoC code against it. When that patch is ineffective it is quickly flagged around the hacking community. Inevitably there are those that will craft attacks to exploit the failure.
This issue was dealt with, but Microsoft needs to explain why it got it wrong. When we received the embargoed release from Core Security we emailed Microsoft asking for a statement. If we get a response we will add it below.
