Bug 967 - Temporary file vulnerabilities in spool directory support
Summary: Temporary file vulnerabilities in spool directory support
Status: RESOLVED WONTFIX
Alias: None
Product: xprint
Classification: Unclassified
Component: Server: Spooler support: Other (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high critical
Assignee: Roland Mainz
QA Contact:
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2004-08-02 01:01 UTC by Drew Parsons
Modified: 2011-09-13 13:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to place print spool directory (Xprintjobs) in $HOME not /tmp. (8.88 KB, patch)
2004-08-02 01:08 UTC, Drew Parsons
no flags Details | Splinter Review

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 /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.)

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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.