Microsoft’s Printing Nightmare Continues

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.”

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

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

Share post

Please check our Community Guidelines before commenting

Conversation 33 comments

  • markbyrn

    Premium Member
    17 July, 2021 - 11:00 am

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

    • cmdrkeene

      17 July, 2021 - 11:20 am

      <p>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. </p>

      • wright_is

        Premium Member
        17 July, 2021 - 2:15 pm

        <p>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.</p>

        • Greg Green

          18 July, 2021 - 2:16 pm

          <p>Yikes.</p>

          • wright_is

            Premium Member
            19 July, 2021 - 12:34 am

            <p><em>This</em> is Windows biggest weakness, since the introduction of Windows XP. </p><p><br></p><p>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.</p><p><br></p><p>Windows XP tried to dumb down NT security for home users coming from Windows 9x. The initial user <em>was</em> 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.</p><p><br></p><p>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".</p><p><br></p><p>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.</p><p><br></p><p>Having to enter the username and password, as opposed to <em>simply</em> clicking "Yes" when asked for administration privileges, also makes you think twice about whether the request is valid.</p>

            • bluvg

              19 July, 2021 - 8:27 pm

              <p>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.</p><p><br></p><p>However, this is an escalation of privilege vuln, so it has nothing to do with running as admin.</p>

              • wright_is

                Premium Member
                20 July, 2021 - 2:01 am

                <p>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.</p>

        • youwerewarned

          20 July, 2021 - 8:09 am

          <p>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.</p><p>You all have my condolences.</p>

    • wright_is

      Premium Member
      17 July, 2021 - 2:13 pm

      <p>The problem is, you need to have administrator privileges to start and stop the service.</p><p><br></p><p>Most business users don’t have that. Plus, our users generally have between 50 and a hundred print jobs a day…</p>

  • Ron Diaz

    17 July, 2021 - 3:10 pm

    <p>But Windows 11 sure looks pretty….</p>

    • lvthunder

      Premium Member
      17 July, 2021 - 7:26 pm

      <p>Do you really want some UI people working on the print spooler?</p>

      • hrlngrv

        Premium Member
        17 July, 2021 - 10:31 pm

        <p>Based on what’s actually in Windows 11, are there any developers other than UI developers working on Windows any more?</p>

        • constable

          18 July, 2021 - 1:09 pm

          <p>Not so many no, most of them are on mobile and cloud.</p>

  • hrlngrv

    Premium Member
    17 July, 2021 - 4:20 pm

    <p>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.</p><p><br></p><p>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.</p><p><br></p><p>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.</p>

    • hrlngrv

      Premium Member
      17 July, 2021 - 4:35 pm

      <p>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.</p>

      • bettyblue

        17 July, 2021 - 7:21 pm

        <p>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.</p>

        • wright_is

          Premium Member
          18 July, 2021 - 5:23 am

          <p>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.</p>

    • lvthunder

      Premium Member
      17 July, 2021 - 7:26 pm

      <p>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.</p><p><br></p><p>As for Linux it’s probably unknown. Hackers don’t pound on it as much as they do on Windows.</p>

      • wright_is

        Premium Member
        18 July, 2021 - 5:19 am

        <p>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.</p><p><br></p><p>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.</p>

    • wright_is

      Premium Member
      18 July, 2021 - 5:01 am

      <p>No and yes.</p><p><br></p><p>No, TPM and 8th Gen won’t cope with programmers making mistakes. The hardware protection around Spectre &amp; 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.</p><p><br></p><p>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.</p><p><br></p><p>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.</p><p><br></p><p>Oh, and to ensure that you have applied all those security patches.</p><p><br></p><p>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.</p><p><br></p><p>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.</p><p><br></p><p>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.</p>

      • edlin

        Premium Member
        27 August, 2021 - 5:10 pm

        <p>Older topic I know… </p><p>Your comment is well thought out. Whether there is or is not a vulerability is not the most important issue to administrators. It is a decisions based on risk. If there is a printer spooler vulnerability in Windows, it is exploited by many many groups who live and breathe hacking. Windows is their primary platform of choice, and easiest exploit. </p><p>Linux is a smaller populous, with less people and most of these users are either more aware of their machines and security or purposefully locked away from hurting themselves (like ChromeOS). But overall they are not worthwhile to most hacker groups. </p><p>I also believe that a greater number of Linux users don’t open documents in email attachments carelessly, like an employee pool in a hospital. </p><p>SO from a mentally aware demographic standpoint, Windows users a much more valuable to these hacks and bugs, both in number and in ‘ease of passage’. </p><p>The long and the short of it is Windows NTFS, was designed for ease of use, and the purpose was moreso for dealing with getting beyond the limitations of FAT, FAT32, exFAT. Steve Jobs understood these limitations and decided to use a kernel that was based on a flavor of Unix which didn’t have a completely open architecture. So HFS, HFS+ and now APFS are entirely different than NTFS and have features in them which inherently protect the running programs. </p><p><br></p><p>More recently they introduced a cornucopia of addons in Windows 8, turning Windows into a PT Barnum marketplace, with endless new and exciting vectors for exploiting a system. All that said, I don’t believe they gained the momentum they anticipated, but they were able to have people subjected to those exploits, huge network chatter and machine upgrades, with endless patching for things like Cortana, OneDrive, HP Printing, Weather, Virtual Reality, Phone, Candy Crush, etc.</p><p><br></p><p>Heading out for a beer… as in not free :-)</p>

    • wright_is

      Premium Member
      18 July, 2021 - 5:16 am

      <p><em style="color: rgb(0, 0, 0);">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.</em></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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.</span></p>

      • bluvg

        19 July, 2021 - 8:48 pm

        <p>"<span style="color: rgb(0, 0, 0);">The fact is, whichever OS you use, such ‘oversights’ are found on a regular basis."</span></p><p><br></p><p><span style="color: rgb(0, 0, 0);">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."</span></p>

  • trparky

    17 July, 2021 - 4:25 pm

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

    • bluvg

      19 July, 2021 - 8:43 pm

      <p>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.</p>

  • navarac

    17 July, 2021 - 4:35 pm

    <p>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.</p>

    • bluvg

      19 July, 2021 - 8:37 pm

      <p>Back when you needed the <em>application</em> to have specific printer model support? Ugh, those were definitely <em>not </em>the days.</p>

  • north of 49th

    Premium Member
    17 July, 2021 - 5:22 pm

    <p>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. </p>

    • bluvg

      19 July, 2021 - 8:36 pm

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

  • bettyblue

    17 July, 2021 - 7:23 pm

    <p>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. </p><p><br></p><p>I feel like 2021 has been nothing but huge bugs, Exchange and otherwise that we have had to run around and mitigate.</p>

  • Greg Green

    18 July, 2021 - 2:22 pm

    <p>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.</p>

    • fraXis

      Premium Member
      18 July, 2021 - 9:24 pm

      <p>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. </p>

    • bluvg

      19 July, 2021 - 8:34 pm

      <p>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.</p>

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC