Issue metadata
Sign in to add a comment
|
CUPS should filter cupsPreFilter |
||||||||||||||||||||||
Issue descriptionPlease see the following section of crbug.com/884511. Can CUPS filter cupsPreFilter more carefully? [ Cups command execution ] The custom ChromeOS version of cupstestppd does not filter cupsPreFilter [9] as strictly as it does cupsFilter{,2} [10]. The cupsPreFilter option as specified in a PPD file can be used to set the full path to a filter binary, which is called with uncontrollable parameters, along with a path to the print job pdf file, as generated by Chrome before being sent to cups. [0] By specifying the /usr/bin/dc binary (‘an arbitrary precision calculator’), it was found to be possible to execute shell commands using the ‘!’ command available inside dc. dc will iterate across all arguments and attempt to execute them as files containing instructions, not exiting if a file does not exist. Argv[6] as passed to dc is the pdf file of the printed page. The majority of the text contents of a pdf file are stored as binary data, but links specified in the page are stored in plaintext /URI parameters, such as the following: /URI (http://example.org/) dc will continue execution if invalid characters are specified. Using this, it is possible to construct a webpage that, when printed, executes a shell command through dc. The relevant dc commands are as follows: q - Immediately exit dc [string] - push ‘string’ onto the program stack x - evaluate the item on the top of the stack ! - run a shell command. Therefore, [!id]x will run the ‘id’ shell command. The following html page will cause the dc command to execute the payload. The payload has been chosen to execute the PPD file (an environmental variable configured by cups) as a shell script. An initial ] closes the dc string delimiter opened by the PDF file structure, and the repeated A padding characters remove the ‘q’ character from the first binary section in the PDF, to ensure that the payload does not quit early. data:text/html,<a href="hxxp://][!/bin/sh ${PPD} &]x">AAA</a> For unknown reasons, directly printing this URL does not trigger the exploit reliably. First printing to PDF and then printing the resultant PDF reliably triggers the command execution. Commands executed using this method are run as cups:root, with a very restrictive seccomp policy [1][2].
,
Sep 17
,
Sep 17
ideally we'd implement an allow list of keywords that a ppd may include and reject ppds that use anything else (rather than implement a block list and add "cupsPreFilter" to it). hopefully the ppd spec should be stable enough for this to not be an issue ?
,
Sep 17
should note that, for the purpose of breaking the exploit chain, doing a directed fix like blocking "cupsPreFilter" would be OK so we can backport something easy. but for tot/master, we should think bigger. filing another bug for that bigger thinking is OK too if you guys prefer.
,
Sep 18
,
Sep 19
,
Sep 19
Do we know whether we require support for cupsPreFilter at all? If not, lets just drop it... ;-)
,
Sep 19
Agreed. PPD parsing has been used in two full-chain Chrome OS exploits already. It needs to be reliably hardened going forward. Mike's suggestion makes sense: let's only accept a subset of keywords (whitelist) rather than implement a blacklist of suspect keywords.
,
Sep 21
crbug.com/885296 will track the quick fix. We'll use this bug for the long term fix.
,
Sep 21
,
Sep 21
,
Oct 5
skau: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 17
,
Oct 19
skau: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 6
,
Nov 17
We commit ourselves to a 60 day deadline for fixing for high severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue? For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 26
,
Nov 26
,
Nov 30
skau@ do you have any updates on this issue since you are actively working on a fix?
,
Nov 30
Whitelisting ppd keys turns out to be harder than anticipated. I'm going to land a change to blacklist cupsPreFilter since it's not commonly used and it's not used by the PPDs that we host at all.
,
Dec 1
PPD attribute whitelisting will be handled in https://bugs.chromium.org/p/chromium/issues/detail?id=910789.
,
Dec 4
skau@ is this the final fix? has this been checked into master?
,
Dec 5
,
Dec 11
skau@ Can you please comment on if this is the final fix and if this is in master?
,
Dec 14
Further filtering over what was done in https://bugs.chromium.org/p/chromium/issues/detail?id=885296 doesn't provide additional safety as cupsFilter has the same capabilities. General filtering of PPD keys will be handled separately. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by kerrnel@chromium.org
, Sep 17