Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CUPS admin user can execute arbitrary files as *cupsFilter #790

Closed
michaelrsweet opened this issue Jun 30, 2004 · 2 comments
Closed

CUPS admin user can execute arbitrary files as *cupsFilter #790

michaelrsweet opened this issue Jun 30, 2004 · 2 comments
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

@michaelrsweet michaelrsweet commented Jun 30, 2004

Version: 1.2-feature
CUPS.org User: jsmeix.suse

Assume the CUPS admin user is not root.
Then this user can execute arbitrary files under the user lp.

The easiest case is for a PostScript printer but for any other
printer is should be only a little bit more tricky.

copy the PPD for any existing queue from /etc/cups/ppd/.ppd
to /tmp/myppd.ppd

add the following line to /tmp/myppd

*cupsFilter: "application/vnd.cups-postscript 0 /tmp/mfilter"

Make /tmp/myfilter as you like - for example

! /bin/bash

echo "I am $( id )" >>/tmp/myfilter.out
cat -
exit 0

Change the queue to use /tmp/myppd.ppd

At least the CUPS admin user can copy this way any printout
to any place he likes (e.g. send it via mail to any external address
or copy it via scp to any external place).

I think this is more than the CUPS admin user should be able to do.

Therefore I suggest that cupsd doesn't execute filters which are
not located in /usr/lib/cups/filter (at least a link must be there)
so that only root can add arbitrary filters.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Jun 30, 2004

CUPS.org User: mike

This is a known issue, however disabling the functionality would prevent driver developers from installing in alternate locations and referencing them from the PPD file. I believe that this functionality is used by many Apple developers, for example, so we can't change it wholesale.

I don't think this is a realistic security concern, given the user "lp" typically has little or no access to critical resources and that you need administrative priviledges to perform the type of attack you outlined. The only time it can affect the printing system configuration is if you use the RunAsUser mode, and that mode has a number of similar side-effects for malicious filters or documents that are passed through the system (which is why we don't use that mode by default...)

If you would like to contribute a patch which adds a "RestrictFilters" option (or a list of allowed paths, or something like that), we will consider it for inclusion in CUPS 1.2.

@michaelrsweet
Copy link
Collaborator Author

@michaelrsweet michaelrsweet commented Sep 19, 2005

CUPS.org User: mike

This STR has not been updated by the submitter for two or more weeks and has been closed as required by the CUPS Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.