Microsoft Issues Workaround for New Windows Vulnerability

Posted on July 21, 2021 by Paul Thurrott in Windows 10 with 13 Comments

Google Reveals Another Microsoft Vulnerability Before Its Fixed

Windows 10 versions 1809 and newer suffer from a vulnerability that can grant system privileges to hackers. Microsoft is still investigating the problem, but it has issued a workaround.

“An elevation of privilege vulnerability exists because of overly permissive Access Control Lists (ACLs) on multiple system files, including the Security Accounts Manager (SAM) database,” a Microsoft security bulletin explains. “An attacker who successfully exploited this vulnerability could run arbitrary code with SYSTEM privileges. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.”

US-CERT provides a bit more detail.

“With a successful exploit, a non-privileged user may leverage access to these files to achieve a number of impacts, including but not limited to extracting and leveraging account password hashes, discovering the original Windows installation password, obtaining DPAPI computer keys, which can be used to decrypt all computer private keys, [and] obtaining a computer machine account, which can be used in a silver ticket attack.”

The good news? These possibilities require the PC to be using Volume Shadow Copy Service (VSS) shadow copies. And an attacker must have the ability to execute code on a victim system before they can exploit this vulnerability, so the system has to have been exploited some other way first.

This new vulnerability was discovered by a security researcher who described an anomaly with the SAM that allowed system access. The issue was later confirmed by Microsoft, which is still investigating and will presumably issue a fix.

For now, however, Microsoft’s security bulletin describes a workaround that involves restricting access to a particular folder and then deleting VSS shadow copies, an act that could impair future restore operations using Microsoft or third-party tools.

And if it makes you feel any better, security researchers also discovered two similar escalations of privilege vulnerabilities in Linux. You can learn more from Qualys here and here.

Tagged with

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (13)

13 responses to “Microsoft Issues Workaround for New Windows Vulnerability”

  1. wright_is

    The exploit doesn't require VSS. The VSS part was that, after using the icacls command to restore the proper protection to the files, you then need to delete any VSS copies that exist on the system, to ensure that no residual copies of the files in unrestricted access form are available. If you are worried about later recovery, you can create a new VSS shadow copy after you have deleted the old ones.

    He found the problem on Windows 11 beta and wondered whether it was a mistake on the beta, but upon checking Windows 10 installations, he discovered that it was an error that crept in earlier, probably during a recent patch.

    • wright_is

      VSS is usually disabled on sub 128GB drives, but if the drive/partition is over 128GB in size, Windows will automatically created a VSS shadow copy when installing patches or the user installs a new application using an .MSI installer.

      I had 2 shadow copies on my work and private machines.

  2. colin79666

    Microsoft needs to explain how this came about. Legacy code being found wanting in the current security climate with printing is one thing but to actually introduce such a permission flaw as part of forced feature updates is another level of concern.

    • wright_is

      Probably someone disabled the protection to change something on the fly and forgot to reset the permissions before using the tool that goes through all changed files, when generating the patch package.

      • hrlngrv

        If your surmise is correct, it'd still be damning about the lack of procedural checklists and controls.

        That is, WHEN and HOW should any developer disable the protection to change something on the fly without getting approval to do so from someone else whose job is ensuring that protection would be reenabled within, say, 30 minutes.

    • winner

      Microsoft's crack QC testing group at work again.

      Oh, wait...

      • hrlngrv

        Is it the Insider Program members providing so little feedback, or the Windows developers paying to little attention to it?

  3. mattbg

    "And an attacker must have the ability to execute code on a victim system before they can exploit this vulnerability, so the system has to have been exploited some other way first."

    This is for sure a mitigation, but I'm not sure it should make anyone breathe easier. With the number of domestic and foreign contractors that have accounts on internal IT systems in corporations these days, being able to bypass the device controls on their own PCs or on any PCs they have non-privileged access to is a big deal.

    • wright_is

      Or the ability to send files, even Word documents or PDFs per email or messaging system, getting to execute code on the machine is comparatively easy.

  4. hrlngrv

    The link to the 2nd Linux vulnerability describes a way to crash a Linux system, not a privilege escalation vulnerability.

  5. ezzy

    That Linux vulnerability is crazy.

    Step 1. Create a file path greater than 1GB in size. (Think a file path 10 million or so characters long)

    I mean, who comes up with this stuff?

    • wright_is

      Security testers and, unfortunately, the bad guys.

    • hrlngrv

      Almost certainly this was discovered due to an error trying to do something else. That is, generating the GB-length pathname was a bug, but that bug exposed the vulnerability. Making lemonade from lemons, as it were.