January, 2013

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.

Today we released seven security bulletins addressing 12 CVE’s. Two of the bulletins have a maximum severity rating of Critical, and five have a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Victim browses to a trusted website via HTTPS. A malicious attacker positioned on the network as a man-in-the-middle under certain circumstances can potentially downgrade encryption to an easier-to-decrypt protocol.

Important

1

Likely to see reliable exploits developed within next 30 days.

Attacker must be man-in-the-middle on the network to leverage this vulnerability.Attacker must also separately exploit a weakness in SSLv2 to decrypt traffic.

Attacker sends victim a link exploiting a Cross-Site Scripting (XSS) vulnerability on a SCOM server for which they have access rights. When the victim clicks the link, an automatic action is taken on their behalf on the SCOM server that they otherwise might not have wanted to execute.

Important

1

Likely to see reliable exploits developed within next 30 days.

Script execution would be within context of SCOM application (not on Windows itself).