This bug is reported as a grave (i.e. critical) bug on the Debian bug tracker,
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.
Here is the bug report, from Dwayne C. Litzenberger:
The built-in "spooldir" virtual printers found in xprint-common suffer
a flaw that allows a local attacker to mount symlink attacks,
denial-of-service attacks (or both) on any user that prints to the
The printer models in question are the "PSspooldir" and
printer models. I will discuss the problem with PSspooldir,
the behaviour of the "spooltodir.sh" script that drives the PSspooldir
virtual printer. Although I only discuss the PSspooldir printer here,
PS2PDFspooldir-GS printer is equally vulnerable.
The spooltodir.sh program creates a directory called /tmp/Xprintjobs,
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
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
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
(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
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
can run a single command to cause a complete break in the
and integrity of the spooldir printer:
ln -s /email@example.com,24309sds24s/foo
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
that ensures that /tmp/Xprintjobs has safe permissions) to work around
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)
causes the PSspooldir and PS2PDFspooldir-GS to place their files in
$HOME/Xprintjobs for the calling user, instead of in /tmp/Xprintjobs.
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,
depends on perl. (However, that might give some insight into why
chose to use /tmp/Xprintjobs in the first place.)
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.
Closing WONTFIX because nobody cares about Xprint. Reopen if you plan to address this bug.
Also adding "patch" to keywords.