IssueTracker

Migrated from https://crbug.com/777215 

Google Chrome           61.0.3163.123 (Official Build) (64-bit)
Platform                9765.85.0 (Official Build) stable-channel swanky
Firmware Version        Google_Swanky.5216.238.5

Two different bugs (CRLF injection and eval based code injection) can be used by a malicious IPP server to cause ChromeOS to install a malicious PPD file which, on printing, will cause the payload to be executed with the same privileges as the cups daemon (cups:root inside a seccomp jail [1]).

To enable exploitation, the test ippserver from the cups distribution [2] can be modified and used.

The IPP server can specify formats to be accepted by the printer, which can be used to specify a specific filter executable to be executed when a print job is sent. Since the passed value is interpolated into the cupsFilter2 line, it is necessary to inject newlines and PPD comment characters to completely control the configuration item.

cupsFilter2 lines should normally look similar to:

*cupsFilter2: "application/vnd.cups-pdf application/pdf 10 -"

but the IPP server can control the second parameter, so we can inject a payload as below:

*cupsFilter2: "application/pdf application/vnd.cups-postscript 0 pstopxl"
*%;echo ********EXPLOIT START********|logger;env|logger;echo ****    ****|logger|cat ${PPD}|logger;echo ********EXPLOIT END********|logger;exit
*% application/pdf application/vnd.cups-postscript 0 pstopxl"
*%;echo ********EXPLOIT START********|logger;env|logger;echo ****    ****|logger|cat ${PPD}|logger;echo ********EXPLOIT END********|logger;exit
*% 10 -"

The payload is injected twice, but we can use \n*% to cause subsequent lines to be turned into comments. The format of our payload will become clear with the second exploit.

The configuration for this bug is specified in the 'formats' variable in the malicious IPP server [3], which we can change to the following to achieve the above payload:

-               *formats = "application/pdf,image/jpeg,image/pwg-raster";
+               *formats = "application/pdf,application/pdf application/vnd.cups-postscript 0 pstopxl\"\n*%;echo ********EXPLOIT START********|logger;env|logger;echo ****    ****|logger|cat ${PPD}|logger;echo ********EXPLOIT END********|logger;exit\n*%";

Along with our payload, we also specify the 'pstopxl' filter executable, which is present on ChromeOS. This executable contains an eval based command injection vulnerability. eval is used in multiple locations throughout the cups filter distributions, but the specific one we exploit in this case is the DefaultInputSlot injection point [4]. This parameter can also be controlled by the malicious IPP server to cause the injection. In this case we modify the 'media_source_supported' array by changing the default value of 'auto' to one that will break out of the eval location and execute our code.

-  "auto",
+  "x}\"$(sh${IFS}${PPD})\"x",

Since the payload length is limited, we use the PPD file itself as a shell based payload. As can be seen in the above cupsFilter2 payload, we use ; to add multiple commands on the same line, and an 'exit' so the payload is not executed twice. The value of ${PPD} is set by the parent of the filter, so we do not need to worry about locating our payload file. In my tests, all lines in the PPD file are not valid shell commands, so there are no side effects other than errors being output for invalid commands.

With these two exploits the malicious IPP server can gain command execution on ChromeOS as cups:root, inside the seccomp jail [1]. I was unable to escape from the seccomp jail and limited user, but the seccomp policy is open enough for most malicious activities. From the restricted position, the payload should be able to read most current and future print jobs (after a reboot it would be necessary for the malicious printer to be re-used as there is no persistence)

To reproduce this vulnerability, patch ippserver from the cups distribution using the attached patch (commit 0bc1a539f used for testing, but any should work).  Compile and run similarly to the following:

sudo ./ippserver -v exploit -p 631

Add a new printer
- chrome://md-settings/cupsPrinters
- or print a page, change Destination, Local Destinations -> Manage (will redirect to chrome://settings/cupsPrinters)
Add printer, Add nearby printer

Once the printer has been added using zeroconf, print to it and observe the payload output in file:///var/log/messages (^F for EXPLOIT). Interestingly,
printers added using this method persist across a powerwash (noticed when transitioning into dev mode).

The exploit printer could masquerade as a legitimate printer, and proxy all jobs to the real printer for invisible exploitation.

Judging by the network traffic generated by the print preview window, I would imagine that one day local printers would automatically appear, increasing the likelihood of this exploit, but I was unable to get this to work, hence having to navigate to the settings and add the printer with more button clicks.

A LAN presence is required to exploit this vulnerability.

I have also attached the PPD file created on the device (obtained via developer mode) to show the injection locations.

[1] https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/net-print/cups/files/cupsd-seccomp-amd64.policy
[2] https://github.com/apple/cups/blob/master/test/ippserver.c
[3] https://github.com/apple/cups/blob/master/test/ippserver.c#L485
[4] https://github.com/richud/gstoraster/blob/master/cups/gstopxl#L110