Ivan Fratric, a security researcher at Google Project Zero found a way to bypass Arbitrary Code Guard (ACG), a feature added by Microsoft to Edge in Windows 10 Creators Update alongside Code Integrity Guard (CIG). The details of this vulnerability have been made public as Microsoft failed to release a patch for the vulnerability within the 90-day deadline. The security feature added by Microsoft in February 2017 was designed to prevent browser exploits from being able to execute malicious code.
The inclusion of the above features into the Edge browser as a modern trend developed where a large number of browser exploits attempt to transform a memory safety vulnerability into a method of running arbitrary native code on a target device. Utilising this technique offered the attacker the path of least resistance as it enabled the attacker to uniformly stage each phase of their attack. Well, such techniques present the attacker with certain advantages, the defender can successfully defend against such attacks without any prior knowledge of the attack, this being a definite advantage if used correctly. A successful defence then has to simply be able to prevent arbitrary code form from executing.
In a blog released to explain the function of both ACG and CIG, researchers explained “An application can directly load malicious native code into memory by either 1) loading a malicious DLL/EXE from disk or 2) dynamically generating/modifying the code in memory. CIG prevents the first method by enabling DLL code signing requirements for Microsoft Edge.” Further, it was stated “This ensures that only properly signed DLLs are allowed to load by a process. ACG then complements this by ensuring that signed code pages are immutable and that new unsigned code pages cannot be created.”
“If a content process is compromised and the content process can predict on which address JIT process is going to call VirtualAllocEx() next (note: it is fairly predictable), the content process can:
- Unmap the shared memory mapped above using UnmapViewOfFile()
- Allocate a writable memory region on the same address JIT server is going to write and write a soon-to-be-executable payload there.
- When JIT process calls VirtualAllocEx(), even though the memory is already allocated, the call is going to succeed and the memory protection is going to be set to PAGE_EXECUTE_READ.”
The vulnerability has been classified as being of Medium Severity. It is also important to note that due Edge's small market share when compared to Chrome and Safari, the security issue is unlikely to affect too many people, but it's embarrassing for Microsoft regardless. While vulnerabilities occur, which may be embarrassing particularly when the feature is designed to prevent exploits, what is more, embarrassing is Microsoft’s failure to release a patch within the 90-day deadline. Project Zero even granted Microsoft a 14-day extension over and above the 90 days at Microsoft’s behest. This extension was granted as Microsoft found the problem was more complex, and therefore more difficult to fix than first thought. Microsoft is expected to release a patch for the vulnerability as part of March’s Patch Tuesday, which will mean that it will be a full month after it was scheduled to be released.
Microsoft’s Poor Deadline History
This is not the first time that Project Zero has uncovered vulnerabilities in Microsoft’s browser offerings. In February 2017 Fratric made public details and proof-of-concept code for a high severity type confusion issue that could have been exploited to crash Internet Explorer and Edge. Further, it was feared that the vulnerability could be used to execute arbitrary code. Again, Microsoft missed the deadline forcing the finding to be made public. The vulnerability, tracked as CVE-2017-0037, was fixed by Microsoft in March 2017, roughly two weeks after it was disclosed.
In the past, Google has been criticised for its rigid reporting timeline and the deadline for patching. A lot of this criticism occurred in 2015 when Project Zero released vulnerabilities, which resulted in some Windows 8.1 and OSX bugs being released before the respective companies had patches ready to deploy. Some felt that applying such a rigid deadline was used to damage competitors reputation rather than solve security issues. In light of the criticisms, Google would allow companies a further 14-day extension on the company’s request to resolve the vulnerability.
The deadlines for disclosure of vulnerabilities have in the past been a thorn in the side of companies, and they will continue to be. This is mainly due to the fact that there is a very little consensus between companies and researchers as to what amounts to responsible vulnerability disclosure. Google’s 90 days, effectively 104 when you include the extension that can be granted, is by far not the most stringent deadline. Carnegie Mellon's CERT only gives developers 45 days before releasing information to the public. While the Zero Day Initiative is far more lenient provider developers 120 days to solve the issue. A few years ago the industry standard seemed to be roughly around 180 days.
Project Zero may appear aggressive than in looking to drastically speed up the process. Effectively halving what was estimated to be the standard of a few years ago would definitely be interpreted as a shock to the system for many. Given the rise of drat breaches, particularly in light of Equifax and Uber, and the use of ransomware which propagates through systems on the back of vulnerabilities having quick solutions to security holes should be considered fundamentally important. While questions of reputational damage should be asked, the creation of a safer computer infrastructure should be the prime goal and the prime motivation for disclosures. The Meltdown and Spectre vulnerabilities of earlier this year once again proved that greater cooperation between competitors is required despite the issue of deadlines. Asking major corporations to leave egos behind for a safer infrastructure is perhaps far too idealistic to hope for.