Bugzilla Bug 242930

xpdf reads it's settings from an xpdfrc file in the current directory.

The psFile setting is evaluated in a shell and would be executed by the user
running xpdf if a document is printed.

This was discovered when trying to change the settings in /etc/xpdfrc. It
didn't work, so the bug also affects function.

# strace xpdf 2>&1 |fgrep xpdfrc
open("/home/erikw/.xpdfrc", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("xpdfrc", O_RDONLY)                = 3

Steps to reproduce (with the risk of overstating the obvious):

Alyssa P Hacker:
alyssa@mowitz ~ $ echo 'psFile "|lpr                           ;echo echo Your
account has been compromised.>>~/.bashrc; lpr"' > xpdfrc

Ben Bitdiddle:
ben@mowitz ~ $ cd ~alyssa
ben@mowitz alyssa $ xpdf somefile.pdf

<ben prints somefile>

ben@mowitz alyssa $ bash
Your account has been compromised.
<Ben panics>

The spaces after lpr are there to fool Ben. The nasty part of the command is
not visible in the Gui.

Note that if ~/.xpdfrc exists, the xpdfrc file in the current directory is not
read.

I believe the xpdfrc it tries to open from the current directory is supposed to
be the global xpdfrc, but the build process is not setting the path correctly.

Creating a ~/.xpdfrc would be a workaround for this bug.

I looked more into this last night after reporting it. I could not attach more
information until now.

From what I found so far this is a problem in both poppler and xpdf. Solving it
in poppler would solve it in xpdf as well.

The SYSTEM_XPDFRC variable is not set by the configure script in poppler. There
should be a default value, but it seems to be missing.

It looks as if this problem is in the poppler package itself, not the ebuild.

Although it could be patched, the package maintainer should be notified before
publishing anything, since other distributions would also be affected.

(In reply to comment #2)
> I looked more into this last night after reporting it. I could not attach more
> information until now.
> 
> From what I found so far this is a problem in both poppler and xpdf. Solving it
> in poppler would solve it in xpdf as well.
> 
> The SYSTEM_XPDFRC variable is not set by the configure script in poppler. There
> should be a default value, but it seems to be missing.
> 
> It looks as if this problem is in the poppler package itself, not the ebuild.
> 
> Although it could be patched, the package maintainer should be notified before
> publishing anything, since other distributions would also be affected.

Hi Erik, thanks for your report and sorry for the delay. Did you get an answer
from upstream about it?

Erik, did you get an answer from upstream?

This is a Gentoo-specific vulnerability in the Xpdf ebuild. We are 
shipping a repackaged version of Xpdf [1] that links against the system 
poppler library. It has the Goo* code and original build system 
removed, and builds the Xpdf binary with a custom Makefile which does 
not set SYSTEM_XPDFRC.

Xpdf's behaviour in config.h then is to assume ".", which leads to the 
unfortunate situation that "xpdfrc" is loaded from the current working 
directory if no other configuration is specified via call arguments or 
present in the user's home directory.

[1]http://gentooexperimental.org/~genstef/dist/xpdf-3.02-poppler-20071121.tar.bz2

This has been previously reported as bug 200023, but without mentioning the
security impact. The bug also contains an ebuild with the fix (and another
bugfix, I did not check that fix's sanity).

Peter, can you please prepare an ebuild at least fixing the -DSYSTEM_XPDFRC
situation and attach it to this bug? We will do prestable testing here.

CVE-2009-1144 has been reserved for this Gentoo specifc issue.

+*xpdf-3.02-r2 (29 Mar 2009)
+
+  29 Mar 2009; Peter Alfredsen <loki_val@gentoo.org> +xpdf-3.02-r2.ebuild:
+  Bump. Fixes bug 200023. Thanks to KIMURA Masaru / hiyuh
+  <hiyuh.root@gmail.com> for the fix and Joseph <syscon780@gmail.com> for
+  the report.
+

Arch Security Liaisons, please test and mark stable:
=app-text/xpdf-3.02-r2
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86"

Note that the security impact of this bump is still considered under embargo,
so please do not reference this stabling as such. We can add the bug reference
to the ChangeLog later.

CC'ing current Liaisons:
   alpha : klausman, armin76
   amd64 : keytoaster, tester
    hppa : jer
     ppc : dertobi123
   ppc64 : corsair
   sparc : fmccor
     x86 : maekke, armin76

Stable on sparc.

Stable for HPPA.

Adding ranger, removing corsair since he's being retired or is retired already.

alpha/arm/ia64/sh/x86 stable

Marked ppc/ppc64 stable.

amd64 stable (approved by Tester)

This is now public.

I added this bug to the ChangeLog for easier reference in the future.

GLSA 200904-07

CVE-2009-1144 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-1144):
  Untrusted search path vulnerability in the Gentoo package of Xpdf
  before 3.02-r2 allows local users to gain privileges via a Trojan
  horse xpdfrc file in the current working directory, related to an
  unset SYSTEM_XPDFRC macro in a Gentoo build process that uses the
  poppler library.