Bug 967

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 /sfs/@some-sfs-host.example.com,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.)

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.