Microsoft first dismissed the elevation of privilege flaw but decided yesterday that attackers injecting malicious code is worthy of attention.
It looked like Google Project Zero blew its own 90-day disclosure window when, on Wednesday, it disclosed an elevation of privilege (EoP) flaw in Windows that it reported to Microsoft just over a month ago on July 8.
But no: It turns out that Microsoft flip-flopped on whether or not it was planning to fix the issue, and the “WontFix” designation flipped the trigger and resulted in Project Zero’s disclosure of details on the flaw.
Microsoft initially said that it wasn’t going to bother: On July 18, it told Project Zero that exploitation requires compromising an AppContainer – i.e., a sandbox used to test Windows app security before letting the apps run free – that’s presumably already accessing the internet.
Given that, Microsoft said that “it’s a non-issue and they will not fix it,” according to Project Zero security researcher James Forshaw. Then, after further analysis, Microsoft spun on its heel. Yesterday, on Wednesday, the company said that yes, it would be tackling the beast.
As Forshaw recounted in a technical report about the flaw, the researcher basically shrugged at the “can’t be bothered” response from Redmond. It’s still an issue, Forshaw said at the time, given that attackers could still exploit the flaw to sneak in via intranet locations that, otherwise, they wouldn’t typically be able to get at. Nonetheless, a day after Microsoft’s “Won’tFix” response on July 18, Forshaw accepted the company’s choice to ignore the vulnerability.
Bullies in the Sandbox
The gist of the matter is that the default rules of the Windows Filtering Platform (WFP) – a set of API and system services that provide a platform for creating network filtering apps – permit executable files to connect to TCP sockets in AppContainers, which can enable malicious actors to pull off EoP.
Essentially, some rules defined in WFP can be matched by a malicious actor to connect to an AppContainer and inject malicious code.
As Forshaw explained in his report, connecting to an external network resource from an AppContainer is enforced through default rules in the WFP: “For example, connecting to the internet via IPv4 will process rules in the FWPM_LAYER_ALE_AUTH_CONNECT_V4 layer,” he wrote.
That layer can contain rules such as “InternetClient Default Rule” that will match if the caller is in an AppContainer (AC) that’s internet-connected. “If a match is made then the connection is allowed,” Forshaw continued. “Eventually an AC process will match the ‘Block Outbound Default Rule’ rule if nothing else has, which will block any connection attempt.”
He gave this example of one such rule, found in both IPv4 and IPv6 connect layers and illustrated below:
Name : Allow outbound TCP traffic from dmcertinst.exe
Action Type: Permit
Key : e83eb750-283b-43e6-b8b5-2ec0df33a2f0
Id : 70341
Description:
Layer : FWPM_LAYER_ALE_AUTH_CONNECT_V4
Sub Layer : {b3cdd441-af90-41ba-a745-7c6008ff2300}
Flags : Indexed
Weight : 422487342972928
Conditions :
FieldKeyName MatchType Value
———— ——— —–
FWPM_CONDITION_ALE_APP_ID Equal \device\harddiskvolume3\windows\system32\dmcertinst.exe
FWPM_CONDITION_IP_PROTOCOL Equal Tcp
“This will permit TCP traffic to any host and port as long as the process executable is dmcertinst.exe,” Forshaw noted. “There’s similar rules for omadmclient.exe and deviceenroller.exe. As there’s no restrictions other than the process executable an AC just has to inject code into an instance of one of those processes and it can connect to arbitrary TCP hosts.”
It’s a ‘General Problem’
Forshaw noted that this is, of course, “a general problem” for any application that’s added permit rules that can be reached by an AC, given that the rules could be matched ahead of the blocking rule. Although the flaw affects any system with these default rules, he specifically mentioned testing on Windows 10 version 2004 in his report.
“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,” he elaborated. “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.”
As far as a fix goes, Forshaw suggested that perhaps 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.”
Then again, maybe the rules are “too flexible,” he hypothesized, and provide too broad an attack surface. “Even limiting to a specific port might at least reduce the attack surface,” he said. “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.”
081921 16:15 UPDATE: On Thursday, Forshaw published an in-depth look at network access in Windows AppContainers: an interesting subject, he explained, given that the Windows Firewall is “used to enforce various restrictions such as whether AppContainer sandboxed applications can access the network.
“Being able to bypass network restrictions in AppContainer sandboxes is interesting as it expands the attack surface available to the application, such as being able to access services on localhost, as well as granting access to intranet resources in an Enterprise,” he said.
Microsoft Changes Its Mind
As of Wednesday, Microsoft had decided to take this EoP problem seriously, reaching out to Project Zero to let Forshaw know that it had decided to work on the issue in spite of its initial feedback being that it was “out of scope.” At this point, a fix is in progress, Forshaw said.
Threatpost has reached out to Forshaw for a clarification of Project Zero’s 90-day disclosure policy, which, in this case, appears to have shrunk. The disclosure policy, as Forshaw posted in his report, states the following:
This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2021-10-06. —Project Zero, Issue 2207
081921 16:02 UPDATE: There was, in fact, no truncation of Google’s 90-day disclosure policy, given Microsoft’s initial decision not to fix this issue. A Google spokesperson directed Threatpost to the company’s disclosure policy, which explains that when vendors indicate they won’t issue a patch, the issue gets a “WontFix” status in the issue tracker, along with an additional technical assessment of the developer’s response.
Here’s a current list of WontFix issues in Zero Project’s tracker. From its policy:
In essence we shift from treating the bug report as a vulnerability (where the rules of vulnerability disclosure apply) and instead begin to treat the issue as a non-security bug (where there are typically no restrictions on public discussion). We think this incentivizes vendors to perform high-quality triaging of our bug reports, and we’ve seen a significant improvement in the quality of the triage we receive in response to this approach.
Software maintainers have been very good at assessing the security risk of the issues we report to them, and it’s rare that Project Zero and a developer disagree about the severity of an issue. —Project Zero Vulnerability Disclosure policy
Microsoft fixed a similar EoP flaw in Windows 10 last month. The bug would have opened all systems to attackers to access data and create new accounts on systems. Microsoft issued a workaround to prevent such exploitation.
Threatpost reached out to Microsoft for some insight into what made the company change its mind about fixing this flaw.
High Marks for Project Zero’s Initiatives
Security experts applaud the effort that Google puts into trying to improve vulnerability disclosures. “Too many other vendors and enterprise infosec organizations take an unacceptable ‘head in the sand’ approach, hoping vulnerabilities just go away,” remarked Yaniv Bar-Dayan, CEO and co-founder at Vulcan Cyber, via email.
It can be messy, though, he noted on Thursday, given that maximum transparency may be ideal, but real-world security “is never that easy.” Still, he said, it would be sweet if the cyber security industry “would start treating vulnerabilities with the urgency Google assumes in their new Project Zero disclosure policies,” Bar-Dayan said.
It gets particularly tricky when it comes to the won’t-fix, will-fix, “disclosure’s still going out” timeline, he observed, particularly when you’re talking about megalodons like Microsoft and Google. “There are number of moving pieces behind the scenes, between the vendor affected and the researchers behind the discovery,” he said. Both organizations have their own ways they discover and address vulnerabilities.”
They have their own ways of prioritizing fixes, but that doesn’t mean that bad actors are twiddling their thumbs while the tech giants mull fixes. “The time between vulnerability disclosure to vulnerability exploit is continuously shrinking, and the bad actors aren’t going to wait for the good actors to get their act together,” Bar-Dayan continued.
There’s no perfect, one-size-fits-all disclosure timeline, at any rate. Dirk Schrader, global vice president of security research at New Net Technologies (NNT), told Threatpost on Thursday that some issues just can’t be fixed in the allotted time, even with extensions. Unfortunately, the fact that there are now details out for this particular vulnerability means that threat actors are going to pick it up for further analysis, checking its exploitability, he predicted.
081921: UPDATES: Added input from Yaniv Bar-Dayan and Dirk Schrader, plus additional details relating to Google’s disclosure policy and a link to James Forshaw’s Thursday blog posting.
Source: https://threatpost.com/windows-eop-bug-detailed-by-google-project-zero/168823/?web_view=true
