Google's Project Zero team is famous (or infamous, depending upon which side of the fence you are) for discovering vulnerabilities in the software developed by the company itself as well as those built by other firms. Its methodology involves identifying security flaws in software and privately reporting them to vendors, giving them 90 days to fix them before public disclosure. Depending upon the complexity of the fix required, it sometimes also offers additional days in the form of a grace period.
The security team has discovered and disclosed multiple security flaws in the past few years following the respective vendor's inability to patch them in a timely manner. This includes Qualcomm's Adreno GPU drivers, Microsoft's Windows, Apple's macOS, and more. It recently also unveiled a new Rowhammer variant that can be used to alter the memory contents of new DRAM chips. A couple of months ago, Google disclosed a Windows bug that could cause elevation of privilege (EoP) following a botched fix from Microsoft, and today, it has done almost exactly the same.
The highly technical report can be found here for those curious, but the gist of the matter is that the default rules of the Windows Filtering Platform (WFP) permit executable files to connect to TCP sockets in AppContainers, which leads to EoP. Essentially, some rules defined in WFP can be matched by a malicious actor to connect to an AppContainer and inject malicious code.
Security researcher James Forshaw, who reported the vulnerability, went on to say that:
This is a general problem of course, if any application has added permit rules which can be reached by an AC then those could be matched ahead of the blocking rule. Of course this is no doubt by design, but the problem here is these rules are there by default on all systems I’ve tested therefore any system would be vulnerable. Note this doesn’t grant access to localhost, as that fails in the ACCEPT/RECV layer which blocks AppContainer localhost connections early.
Fixing wise perhaps these default rules shouldn’t match AC processes (so add a check for FWPM_CONDITION_ALE_PACKAGE_ID) or they should be ordered after the AC block rule. It might also be that they’re too flexible, even limiting to a specific port might at least reduce the attack surface. I’m not sure if there’s a general way of fixing the issue, but as an AC process can’t enumerate the current rules (AFAIK) then an AC process would never know if non-default rules have been added that they could abuse.
Although Forshaw mentions that any system with these default rules is impacted, the OS mentioned in his report is Windows 10 version 2004.
Google Project Zero awarded the vulnerability a "low" criticality rating and privately reported it to Microsoft on July 8, 2021. Microsoft asked for a 14-day extension on July 15, citing the complexity of the issue, which was granted. However, on July 19, the Redmond tech giant stated that it would not be fixing the problem at all because the vulnerability requires an AppContainer already being exposed to the internet. While Forshaw states that the flaw would still result in a malicious executable gaining access to intranet locations, making it somewhat severe, he did accept Microsoft's reasoning.
This is where the tricky bit comes in. Microsoft reached out to Google Project Zero on August 18, and stated that it has started working on fixing the problem once again. That said, it's unclear why the issue has been made public already given that it was awarded the standard 90-day disclosure deadline and it's barely been over a month. We have reached out to James Forshaw for more clarity on the disclosure policy and will provide an update once we hear back.
Update: Google has responded to Neowin's request for more details about its disclosure policy, stating that if a vendor states that it won't fix an issue, the security team treats it as a non-security bug and makes information about it publicly available. This is part of its standard policy, and you can find out more details about it here. For those who are interested in learning more about the WFP problem, do check out James Forshaw's detailed blog post about it here .
18 Comments - Add comment