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.