Microsoft’s Printing Nightmare Continues

Posted on July 17, 2021 by Paul Thurrott in Microsoft, Windows with 32 Comments

Microsoft has acknowledged the third printer-related vulnerability in Windows in the past month or so.

“An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly performs privileged file operations,” Microsoft’s description of CVE-2021-34481, the third printer-related vulnerability, 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.”

If this sounds familiar, it’s because this description is nearly identical to that of PrintNightmare, the first printer-related vulnerability that it acknowledged in early July. And while Microsoft issued two patches to fix that problem, neither seems to be effective. And the advice, repeated in CVE-2021-34481, remains the same: To be truly safe from these vulnerabilities, you need to stop and then disable the Print Spooler service.

The problem? Doing so disables the ability to print. As Microsoft explains, the Print Spooler service is what manages print jobs, print queues, loading the correct printer drivers, and so on. This is useful functionality, obviously, but it’s also been targeted by hackers for years.

Microsoft says it is working on a security update to address CVE-2021-34481, just as it did with the previous two exploits. But given the seriousness of these exploits, you may want to just stop and then disable the Print Spooler service for now (as described in the Workarounds section of this vulnerability disclosure). And if you’re an IT admin, you should look into restricting the installation of new printer drivers as well.

Tagged with

Join the discussion!

BECOME A THURROTT MEMBER:

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

Register
Comments (32)

32 responses to “Microsoft’s Printing Nightmare Continues”

  1. Avatar

    markbyrn

    Would it be safe to manually enable the service when needed to print and then disable it when done?

    • Avatar

      cmdrkeene

      That would certainly decrease your risk. And remember, an attacker would already need to have ability to execute code on your machine before they could leverage this print spooler vulnerability, so you have to already be infected for this to matter, which arguably means it's already too late.

      • Avatar

        wright_is

        And, if you have the ability to start and stop the service, you are already logged in as an administrator and therefore the malware doesn’t need to raise its privileges.

        • Avatar

          youwerewarned

          Having been both a long-time VAR and Sr Network Admin in a Microsoft environment, reading through these latest issues leads me to one conclusion: couldn't pay me enough to do this anymore...and retirement is sweet.

          You all have my condolences.

          • Avatar

            wright_is

            This is Windows biggest weakness, since the introduction of Windows XP.


            Before that, Windows NT always had an administrator and "normal" users. If you needed to change the configuration, you logged on as an administrator, if you wanted to work, you logged on with your normal account. This carried on through Windows 2000.


            Windows XP tried to dumb down NT security for home users coming from Windows 9x. The initial user was the administrator. That saved users having to learn how to do things properly and getting frustrated during the initial set-up, where they might have to ping-pong between the administrator and their normal account.


            Unfortunately, it was also the undoing of security on Windows. Now, nearly everybody on Windows Home was running all the time with full administration privileges. Vista on tried to temper this by reducing the user context and asking for the rights to be promoted to accomplish an administration task, but the account was, at the end of the day, an administrator, so malware quickly found a way around the "problem".


            I am an administrator at work. My normal every day account is a plain user account, like everybody else's. Not even on my own PC is that account an administration account. When I need to do administration tasks, I use a separate account with administration privileges. For day-to-day use on the PC, I never need administration privileges. When I do need it - installing software, changing the configuration of a network card etc. I just log on using the admin account or I enter the username and password when Windows asks for raised privileges.


            Having to enter the username and password, as opposed to simply clicking "Yes" when asked for administration privileges, also makes you think twice about whether the request is valid.

            • Avatar

              bluvg

              I don't disagree that they should never have resorted to making users admins by default. If you look at reviews from the time--which was a much different time--they caved to appcompat pressure. Even UAC was met with derision in reviews for being a hassle. Congrats, those people, you got what you wanted.


              However, this is an escalation of privilege vuln, so it has nothing to do with running as admin.

              • Avatar

                wright_is

                Correct, although, if you are running as admin, the escallation of privilege is not needed in the first place, making it even easier for the bad actor.

    • Avatar

      wright_is

      The problem is, you need to have administrator privileges to start and stop the service.


      Most business users don’t have that. Plus, our users generally have between 50 and a hundred print jobs a day…

  2. Avatar

    Greg Green

    I’m not a coder so I barely understand this, but why aren’t these things compartmentalized from the beginning? You’re a print job, you talk only to a printer, you don't access hard drives, soft drives, any drives or any ram.

    • Avatar

      fraXis

      It’s not that simple. If you are printing a file, then it needs access to the hard drive. If you are printing something cached in ram, then it needs access to ram, etc.

    • Avatar

      bluvg

      You're not wrong, they should be. This vuln is an ease-of-use penalty: Microsoft favored ease of use and compatibility over security in this case. If a driver can do things with SYSTEM-level rights, and you give the ability to standard user accounts to install such drivers, you've poked a big hole in that security boundary. To close it, as you suggest, you could compartmentalize by reducing the necessary rights for printer drivers. The other option (which they recommend) is to prevent standard users from installing printer drivers. There are likely other options, but those are the dynamics.

  3. Avatar

    bettyblue

    My team rolled through every single server and made sure the spooler was off. Most were because your 2012 R2, 2016, and 2019 VMware templates already had that service disabled.


    I feel like 2021 has been nothing but huge bugs, Exchange and otherwise that we have had to run around and mitigate.

  4. Avatar

    north of 49th

    Dumb question - at this point wouldn't it be better to go back to a blank sheet of paper and redesign the print spooler service from scratch? It's 2021 and I have to believe there are better ways to create a job queuing service than what has been in place since Windows xx.

    • Avatar

      bluvg

      Cloud print, probably? Much, much easier said than done to just start from scratch, though. The ecosystem around printing is deep and wide.

  5. Avatar

    navarac

    Strikes me we have had problems with printers since the days CP/M and Dot Matrix Printers and their "handshaking". That was sometimes a total nightmare as well.

  6. Avatar

    trparky

    Would making sure that your system is properly firewalled off be sufficient in maintain safety?

    • Avatar

      bluvg

      Depends. Outside of a business environment (with print servers), this is not nearly as big of a deal. This exploit is more in the context of print servers in businesses, where it could be an initial step of a major compromise. If you change the firewall settings on a print server to prevent the exploit, you also prevent it from doing its job of printing.

  7. Avatar

    hrlngrv

    On a tangent, I haven't read more than a few articles about PrintNightmare, but I have to ask whether TPM 2 or 8th get Intel/AMD Ryzen 2000 and later processors could prevent it.


    On a different tangent, does Linux have analogous vulnerabilities? If not, time to bring in Linux servers for printing duty? Yet another tangent, does printing to PDF involve the print spooler? If not, users could print to PDF, ensure the PDF looks right, then send the PDF to the Linux server, and the Linux server could handle the actual printing.


    Now I'm going to be a cynic and ponder whether the Windows print spooler dates back to Windows 95 with too few changes over the last 2.5 decades, so that it's fundamentally inherently insecure. Indeed, if Windows printing is insecure but Linux printing isn't, that'd be uncomfortable evidence MSFT got printing so wrong it should consider a rewrite starting from scratch.

    • Avatar

      lvthunder

      PDF's use the print spooler. If your command starts out with the Print dialog box you are going to be using the print spooler.


      As for Linux it's probably unknown. Hackers don't pound on it as much as they do on Windows.

      • Avatar

        wright_is

        Linux gets pounded on more than Windows Server, because it is responsible for a majority of the backbone of the Internet, with a majority of web/email/application servers, routers, switches, IoT devices, Android smartphones etc.


        And bugs are regularly found. But most of those servers and devices aren't acting as a print server. They get attacked in other areas.

    • Avatar

      wright_is

      Now I'm going to be a cynic and ponder whether the Windows print spooler dates back to Windows 95 with too few changes over the last 2.5 decades, so that it's fundamentally inherently insecure. Indeed, if Windows printing is insecure but Linux printing isn't, that'd be uncomfortable evidence MSFT got printing so wrong it should consider a rewrite starting from scratch.


      That isn't so easy to say. The code comes from Windows NT, not Windows 95. And it has been modified over the years, for things like the current point and print issue that is the issue that came to light after the current patches. That was a feature added much later, with good intentions. The problem is, such a feature has to be built on trust. You have to trust to device/server/PC to are printing to. That was fine, in the corporate model, where it was developed. Everything behind a firewall and managed. Unfortunately, malware authors have put the kybosh on most assumptions of a secure environment. But, with hundreds of millions of lines of code (Windows and Linux), it is hard to catch every instance, where such an assumption has been made and the resultant code is exploitable.


      If it was easy, we'd have found most of these flaws about 15 years ago, when malware started really trying to exploit such problems. The fact is, whichever OS you use, such "oversights" are found on a regular basis.


      If the print spooler on Linux is more secure, their mail server wasn't (major exploits in Exim earlier this year), there have been dozens of Kernel remote code or escalation bugs found this year.


      Also, the point and print allows great flexibility, when visiting a different office, you simply point to the printer you want to print to and the paper is spouted out the other end. On Linux, for example, that isn't so easy, you still need some configuration.


      On the other hand, we don't allow point and print at work, we set up the printers each user can use, when they get their PC or when they move departments. They print directly to the printers, no managed queues on a print server - each printer is its own print server. And they cannot install drivers on demand and none of the PCs are acting as print servers.


      That means, that for us, the risk is fairly minimal, but we have still pushed out the patch to everybody and have set the recommended policies to disable the print server and driver download features - even though they should already be deactivated on every PC in the company... With so many PCs, it is easy for some manufacturer to turn it on with a driver installation, without you being aware of it - I checked a few dozen different PCs and none had either option enabled, but, as we don't use them, I didn't take any chances.


      We also disabled print spooler on all of our servers, with the exception of one server, which has an application that uses streaming jobs localhost to print.


      You can look for someone to blame, but at the end of the day, all operating systems are as good/bad as each other in this respect. The only thing you can do is ensure you have taken all the precautions you can.

      • Avatar

        bluvg

        "The fact is, whichever OS you use, such 'oversights' are found on a regular basis."


        Exactly. The "many eyes" principle of OSS has not proven true, even with something as widely-used as Linux. There have been multiple cases of serious security flaws that have existed for many years despite those "many eyes."

    • Avatar

      wright_is

      No and yes.


      No, TPM and 8th Gen won't cope with programmers making mistakes. The hardware protection around Spectre & Meltdown mean that the programmer doesn't have to build in checks and delays all over the place (it takes away anywhere between 20 and 30% of the processor performance) and can concentrate on getting the actual code working properly.


      TPM, like the Secure Enclave on the Apple side of the fence, along with secure boot, can help stop bad actors getting in at the bottom of the stack (root kits etc.) and ensure biometrics are more securely stored, the key for Bitlocker is secure etc.


      Security isn't a one-size-fits-all garment. There are so many layers and attack vectors, you need as many as possible to cover as many areas as possible - and you can be sure, at the end of the day, regardless of operating system and security tools configured in your environment, there is a small opening, somewhere, that has been overlooked and is just waiting for hackers to find. You can only hope that the good hackers find it first and report it to the hardware of software provider, instead of a bad actor finding it and exploiting it to get into your network.


      Oh, and to ensure that you have applied all those security patches.


      Linux suffers from exactly the same sorts of errors. On my SUSE, I get a couple of hundred patches a week to install (each library or application is patched separately, not a bundled patch, like Microsoft, that covers the thousands of built-in libraries and applications). The SUSE is a rolling release (newest releases of each product), so some of those patches are also simply newer versions of some packages.


      But Linux still needs to be patched on a regular basis. The one upside/downside is that the patches are released, once they have been tested. That means you get the ability to patch your systems much more quickly than waiting until 2nd Tuesday. The downside is, you either need to keep abreast of security patch releases for Linux and the applications you run, or you need to have some mechanism to check several times a week to ensure nothing critical has been overlooked - there are tools you can set up to monitor this, which is helpful, if you have a server farm to cope with.


      And, yes, on the desktop and mobile, Apple and Google also have exactly the same problem. Apple have usually shied away from monthly patches, keeping fixed exploits and packaging them up for less regular fixes, which often include new features - it took them over 8 months to patch a Java zero day, Sun gave them the patch information at the same time as Microsoft, Google, Linux etc. were informed and they had a coordinated release in the January, it was only after an uproar in July/August that Apple finally got around to pushing out the patch. That was around 2009/2010, they have improved somewhat since then.

    • Avatar

      hrlngrv

      Now after a bit more reading, Linux's cups has had remote code execution vulnerabilities in the past, but I haven't found anything about escalation of privilege vulnerabilities.

      • Avatar

        bettyblue

        Print drivers and associated software will be lacking on Linux. Your HR person may want to use tray 3 and do some duplex printing on your 8K MFP down the hall.

        • Avatar

          wright_is

          All perfectly possible on Linux. But the drivers are simpler on Linux and aren't proprietary executables, but usually definition files. General printing, trays, duplex etc. should all be available for most printers these days. Some advanced features, like borderless printing or Pantone accuracy might not be so wide-spread, but most manufacturers provide the information needed to create a driver, if they don't provide them themselves, or they have standard PCL or PostScript modes that let them work with Linux.

  8. Avatar

    Ron Diaz

    But Windows 11 sure looks pretty....

Leave a Reply