Google ‘Irresponsibly’ Discloses Windows Zero-Day

Google discovered a “threat actor” exploiting a pair of bugs—one in Chrome and one in Windows. Together, the bugs allowed a dodgy web page to elevate to Administrator.

So Google responsibly kept quiet about the Windows bug until Microsoft had fixed it, right? Wrong: It gave Redmond only a week, and then blabbed some specious story about the zero-day being “actively exploited.”

Despite the fact that Microsoft disagrees. In today’s SB Blogwatch, we don’t like the precedent this sets.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: New Wave Royals.

Microsoft Quietly Fuming

What’s the craic? Catalin Cimpanu reports—“Google discloses Windows zero-day”:

 The zero-day is expected to be patched on November 10, [the] next Patch Tuesday, according to Ben Hawkes, team lead for Project Zero, Google’s elite vulnerability research team. … The Google Project Zero team notified Microsoft last week and gave the company seven days to patch the bug, [but] Microsoft did not release a patch in the allotted time.

The zero-day is … in the Windows kernel. [It] can be exploited to elevate an attacker’s code. [It] impacts all Windows versions between Windows 7 and the most recent Windows 10 release.

What does Redmond have to say for itself? Zack Whittaker acts as conduit—“Google reveals a new Windows zero-day bug … under active attack”:

 Google has dropped details of a previously undisclosed vulnerability in Windows, which it says hackers are actively exploiting. [It] is labeled CVE-2020-17087.

Attackers are using the Windows vulnerability in conjunction with a separate bug in Chrome, which Google disclosed and fixed last week. This new bug allows an attacker to escape Chrome’s sandbox.

Microsoft … said in a statement: … “While we work to meet all researchers’ deadlines for disclosures, including short-term deadlines like in this scenario, developing a security update is a balance between timeliness and quality.” … A Microsoft spokesperson also added that the reported attack is “very limited and targeted in nature, and we have seen no evidence to indicate widespread usage.”

And Sergiu Gatlan adds—“Windows kernel zero-day vulnerability used in targeted attacks”:

 [It’s an] elevation of privileges (EoP) vulnerability … a pool-based buffer overflow … in the Windows Kernel Cryptography Driver (cng.sys). … Even though the bug was added to the Project Zero issue tracker only 8 days ago, it was disclosed after only 7 days because it was being used by attackers in the wild.

How could we improve Chrome’s security on Windows? Yo, dawg, raymorris heard you like sandboxes:

 If Chrome were a .NET application, you could put a sandbox around the sandbox.

But wait—Google disclosed after only seven days? jfreedle2 waxes excoriating:

 Google is irresponsible for disclosing the vulnerability after only seven days. Sure it only takes about five minutes to update all of Google’s code, but more useful software like an operating system takes longer. These people need to be removed from the Internet.

LOL be careful what you wish for. Google’s Ben Hawkes explains himself:

 We think there’s defensive utility to sharing these details, and that opportunistic attacks using these details between now and the patch being released is reasonable unlikely. So far it’s been used as part of an exploit chain, and the entry-point attack is fixed.

The short deadline for in-the-wild exploit also tries to incentivize out-of-band patches or other mitigations being developed/shared with urgency. Those improvements you might expect to see over a longer term period.

It’s not always clear if we’ve struck the right balance since this “in the wild exploit” situation is so rare, but we’re definitely trying to do the right thing for user security! It’s not easy for either researcher or vendor in these situations unfortunately.

Is that fair? u/sigmoid10 approves this message:

 They literally had less than a week for the patch. It was either this or keep it secret until the next patch Tuesday while it is already getting exploited. Now people at least have a very good reason to keep all other software updated, because if anything on the system isn’t, the workstation is as good as rooted.

What is the bug, anyway? Mateusz Jurczyk and Sergei Glazunov go into more detail—“Issue 2104: Windows Kernel cng.sys pool-based buffer overflow in IOCTL 0x390400”:

 The Windows Kernel Cryptography Driver (cng.sys) exposes a \Device\CNG device to user-mode programs and supports a variety of IOCTLs with non-trivial input structures. It constitutes a locally accessible attack surface that can be exploited for privilege escalation (such as sandbox escape).

The bug resides in the cng!CfgAdtpFormatPropertyBlock function and is caused by a 16-bit integer truncation issue. … If SourceLength is equal to or greater than 0x2AAB, an inadequately small buffer is allocated [which] is subsequently overflown. … A crash is easiest to reproduce with Special Pools enabled for cng.sys, but even in the default configuration the corruption of 64kB of kernel data will almost surely crash the system shortly after running the exploit.

We have evidence that this bug is being used in the wild. Therefore, this bug is subject to a 7 day disclosure deadline.

Meanwhile, arglebargle_xiv thinks that’s just not on:

 CNG is part of Windows’ security, and bad guys aren’t supposed to use Windows security components to break Windows security. There’s a big “security line, do no cross” label attached to it, and all attackers should respect that and not attack beyond that point. It’s just unsporting.

And Finally:

Puddles goes old-skool

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Image sauce: Edouard Bourguignon (cc:by-sa)

Featured eBook
Managing the AppSec Toolstack

Managing the AppSec Toolstack

The best cybersecurity defense is always applied in layers—if one line of defense fails, the next should be able to thwart an attack, and so on. Now that DevOps teams are taking  more responsibility for application security by embracing DevSecOps processes, that same philosophy applies to security controls. The challenge many organizations are facing now … Read More