MS13-001 addresses a vulnerability in the way the Windows Print Spooler handles maliciously-crafted print jobs. The potential attack scenario is a little different than previous spooler service vulnerabilities so we’d like to share more details to help you assess the risk it may pose in your environment.
Potential Attack Scenario
A malicious attacker given permission to queue print jobs to a shared printer could potentially leverage this vulnerability to compromise other workstations that subsequently interact with the same print queue. This is a different attack scenario than we have typically seen in previous print spooler cases. The print server itself is not targeted in this case; instead, the potential victims are other clients printing to or querying the status of the shared printer.
How other workstations could be targeted
This vulnerability could be used to trigger a double-free of memory used by the print spooler service process (running as LocalSystem) when a client uses third party software to enumerate the queued print jobs on a remote print server. Network configurations that require users to authenticate before submitting print jobs would only be at risk from an attacker who is first able to authenticate and then able to send the malformed print job to the shared printer. A clever attacker could submit a malicious print job and then pause the job, allowing the malicious job to remain in the shared print queue to be enumerated by other clients.
Mitigating Factors
Windows clients printing to a shared printer using default settings do not query pending print jobs in a manner that could trigger this vulnerability. By default, the vulnerability would not be triggered by clients printing to a shared printer unless third party software is installed on the client that enumerates print jobs differently than built-in Windows components. Even the Windows Devices and Printers “See What’s Printing” user interface cannot be used to trigger this vulnerability.
This vulnerability could be triggered on unpatched clients by add-on software shipped by printer manufacturers to monitor the print queue. A subset of these optional components, sometimes included with the printer driver installation, may even query the printer queue every time a user submits a new print job.
The discrepancy of vulnerability exposure when printing with inbox components vs. third party add-on software is due to the “level” of information enumerated by the client workstation. The default Windows print spooler and the “See What’s Printing” user interface requests “level 4” information. Only when then the print spooler services handles requests for “level 2” information could this vulnerability be triggered.
Using the vulnerability for local elevation of privilege
We should note, however, that this vulnerability could also be used as a local elevation of privilege vulnerability by a malicious low-privileged user, whose intent is to run code in the context of LocalSystem. A malicious low-privileged user able to queue a print job could then run a custom tool that requests “level 2” print job information, triggering the vulnerability locally to elevate privileges on the machine on which they are logged in.
Conclusion
We hope this information helps you assess the risk this issue may pose in your environment. Please let us know if you have any questions.
- Ali Rahbar and Jonathan Ness, MSRC Engineering