|Summary:||Temporary file vulnerabilities in spool directory support|
|Product:||xprint||Reporter:||Drew Parsons <dparsons>|
|Component:||Server: Spooler support: Other||Assignee:||Roland Mainz <roland.mainz>|
|Status:||RESOLVED WONTFIX||QA Contact:|
|i915 platform:||i915 features:|
Description Drew Parsons 2004-08-02 01:01:51 UTC
This bug is reported as a grave (i.e. critical) bug on the Debian bug tracker, bug #262871. It refers to /tmp/Xprintjobs, used when printing to file. The bug reporter claims that the first use to use this directory gains ownership of it, which he or she can leverage to make symlink or DOS attacks. A patch is provided. Since the Debian bug tracking system is currently down, I will repeat the bug report here, together with the patch. Note the patch uses perl to define the user's home directory. Using perl will not be a problem on a Debian system (it will already be installed because of other dependencies), but I can speak for others. The patch is supposed to make printed files go into $HOME/Xprintjobs instead of /tmp/Xprintjobs. Roland, can you tell me if there is any reason why the patch is bad? Otherwise I will put it into Debian later this week, since Debian is now preparing to freeze for our new stable release (final upload date for packages before projected freeze: 13 August). I will place the contents of the bug report into a separate message.
Comment 1 Drew Parsons 2004-08-02 01:05:52 UTC
Here is the bug report, from Dwayne C. Litzenberger: The built-in "spooldir" virtual printers found in xprint-common suffer from a flaw that allows a local attacker to mount symlink attacks, denial-of-service attacks (or both) on any user that prints to the "spooldir" printers. The printer models in question are the "PSspooldir" and "PS2PDFspooldir-GS" printer models. I will discuss the problem with PSspooldir, specifically, the behaviour of the "spooltodir.sh" script that drives the PSspooldir virtual printer. Although I only discuss the PSspooldir printer here, the PS2PDFspooldir-GS printer is equally vulnerable. The spooltodir.sh program creates a directory called /tmp/Xprintjobs, and places the files it prints there. When the directory is created, its "sticky" bit is set, so one might think that it would behave in a similar fashion to /tmp. However: - If a /tmp/Xprintjobs directory (or symlink to a directory) exists, no attempt to verify its integrity is made. - /tmp/Xprintjobs is created by a non-root process, and is therefore owned by the first user to use the PSspooldir printer driver. - The files created inside /tmp/Xprintjobs have moderately-predictable filenames, and their creation is not protected against symlink attacks. (Note that predicting filenames may not even be necessary; see below.) If no user has used the PSspooldir printer, or if the attacker was the *first* user to use the PSspooldir printer (i.e. the attacker created /tmp/Xprintjobs via the PSspooldir printer driver), then: - The attacker can create his/her own /tmp/Xprintjobs and wreak havoc on other users. If the postscript file is subsequently viewed in ghostscript without the -dSAFER option, then an attacker may even be able to execute arbitrary code as that user. - A user need not predict any filenames. For example, if the sfs-client package is installed, the first user to use the PSspooldir printer driver can run a single command to cause a complete break in the confidentiality and integrity of the spooldir printer: ln -s /firstname.lastname@example.org,24309sds24s/foo /tmp/Xprintjobs I'm sure there are other things that can be done. Although we could put in a bunch of code (such as a setuid root executable that ensures that /tmp/Xprintjobs has safe permissions) to work around the above two problems, the reality of the matter is that /tmp/Xprintjobs is not a particularly good place place to put the files in the first place. I've attached a patch (to be placed in the debian/patches directory) that causes the PSspooldir and PS2PDFspooldir-GS to place their files in $HOME/Xprintjobs for the calling user, instead of in /tmp/Xprintjobs. It adds a dependency on perl (to call getpwuid, since the HOME environment variable isn't available to spooltodir.sh). That shouldn't be a problem for Debian, since the xprt-common package already depends on debconf, which depends on perl. (However, that might give some insight into why upstream chose to use /tmp/Xprintjobs in the first place.)
Comment 2 Drew Parsons 2004-08-02 01:08:34 UTC
Created attachment 554 [details] [review] Patch to place print spool directory (Xprintjobs) in $HOME not /tmp. Patch provided by Dwayne C. Litzenberger in Debian bug #262871.
Comment 3 Corbin Simpson 2011-09-13 13:35:38 UTC
Closing WONTFIX because nobody cares about Xprint. Reopen if you plan to address this bug. Also adding "patch" to keywords.