Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 99769

Summary: app-text/xpdf another issue (CAN-2005-2097)
Product: Gentoo Security Reporter: Sune Kloppenborg Jeppesen <jaervosz>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Severity: normal CC: printing
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: A3 [glsa] koon
Package list:
Runtime testing required: ---
Description Flags
xpdf-3.00-ttf-cid-fix.dif none

Description Sune Kloppenborg Jeppesen gentoo-dev 2005-07-21 03:07:14 UTC
Reported on V-S, waiting for further information before opening more bugs for 
pdftohtml,kpdf, koffice,cups, gpdf and possibly others. 
The attached PDF file causes xpdf3 and clones (like newer kpdfs) to fill  
up /tmp with a temporary file that is growing until the filesystem is full.  
xpdf2 and clones are apparently not affected.  
I have attached the patch that detects the brokenness inside the PDF.  
It is not fully clear to me if this issue is caused by patch applied by  
us or not, but I think it is a general upstream xpdf3 issue.
Comment 1 Sune Kloppenborg Jeppesen gentoo-dev 2005-07-21 03:09:35 UTC
Created attachment 63959 [details, diff]

Patch from Marcus Meissner <>
Comment 2 Sune Kloppenborg Jeppesen gentoo-dev 2005-07-25 11:54:08 UTC
Heinrich please provide an updated ebuild.       
Opening other bugs for apps that possibly include xpdf code:       
app-text/pdftohtml lanius bug #100261 
kde-base/kdegraphics|app-office/koffice carlo bug #100263 
net-print/cups lanius bug #100264 
app-text/gpdf obz bug #100265 
Comment 3 Sune Kloppenborg Jeppesen gentoo-dev 2005-08-03 22:02:45 UTC
Adding arch security liaisons to CC. 
Comment 4 Thierry Carrez (RETIRED) gentoo-dev 2005-08-04 08:46:04 UTC
Created attachment 65072 [details, diff]

Extra patch from SuSE...

Apparently it may need this other patch applied first. Not sure KDE needs it
(it may already be in) which would explain why kpdf is the only one working
with the first patch.
Comment 5 Carsten Lohrke (RETIRED) gentoo-dev 2005-08-04 09:46:50 UTC
The applied KDE patches seem to be fine, but are prelimimary. KDE svn looks more
like this patch, when you measure in changed function signatures.
Comment 6 Guy Martin (RETIRED) gentoo-dev 2005-08-05 01:58:43 UTC
Adding KillerFox. He's the security guy on hppa and he will handle this bug.
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2005-08-06 11:47:48 UTC
This will be made public on Tuesday. Would be a good thing to have patched
versions at that date...
Comment 8 Jason Wever (RETIRED) gentoo-dev 2005-08-06 12:57:57 UTC
The initial description talks about an attached PDF but there is no PDF
attached.  Where can I find this to test with?
Comment 9 Thierry Carrez (RETIRED) gentoo-dev 2005-08-06 13:50:59 UTC
> Where can I find this to test with?

You can find the test PDF at ~koon/foo.pdf on toucan. On gpdf it triggers the
problem when you browse to the second page.
Comment 10 Heinrich Wendel (RETIRED) gentoo-dev 2005-08-07 04:14:16 UTC
with the second patch the first patch applies fine, but xpdf fails to compile: 
make[1]: Entering directory 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c In member function `SplashFontFile* 
SplashFontEngine::loadType1Font(SplashFontFileID*, SplashFontSrc*, char**)': error: no matching function for call to 
`SplashT1FontEngine::loadType1Font(SplashFontFileID*&, SplashFontSrc*&, 
SplashT1FontEngine.h:36: note: candidates are: SplashFontFile* 
SplashT1FontEngine::loadType1Font(SplashFontFileID*, char*, GBool, char**) In member function `SplashFontFile* 
SplashFontEngine::loadType1CFont(SplashFontFileID*, SplashFontSrc*, char**)': error: no matching function for call to 
`SplashT1FontEngine::loadType1CFont(SplashFontFileID*&, SplashFontSrc*&, 
SplashT1FontEngine.h:38: note: candidates are: SplashFontFile* 
SplashT1FontEngine::loadType1CFont(SplashFontFileID*, char*, GBool, char**) 
make[1]: *** [SplashFontEngine.o] Error 1 
make[1]: Leaving directory 
make: *** [all] Error 2 
Comment 11 Thierry Carrez (RETIRED) gentoo-dev 2005-08-07 08:38:35 UTC
Beh. Xpdf 3.01 is scheduled for this week, so I guess we'd better wait for it.
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2005-08-09 00:41:15 UTC
Keeping this one at "Normal" level since it affects indirectly CUPS.
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2005-08-09 13:24:15 UTC
Now public
Comment 14 Thierry Carrez (RETIRED) gentoo-dev 2005-08-09 13:46:44 UTC
Ubuntu Security Notice USN-163-1	    August 09, 2005
xpdf vulnerability
xpdf and kpdf did not sufficiently verify the validity of the "loca"
table in PDF files, a table that contains glyph description
information for embedded TrueType fonts. After detecting the broken
table, xpdf attempted to reconstruct the information in it, which
caused the generation of a huge temporary file that quickly filled up
available disk space and rendered the application unresponsive.

The CUPS printing system in Ubuntu 5.04 uses the xpdf-utils package to
convert PDF files to PostScript. By attempting to print such a crafted
PDF file, a remote attacker could cause a Denial of Service in a print
server. The CUPS system in Ubuntu 4.10 is not vulnerable against this
We might find something interesting in :
Size/MD5:    49233 4cd029c1e95456692b26dcfdb6d53ce8

Otherwise maybe just wait for upstream 3.01 ?
Comment 15 Luis Medinas (RETIRED) gentoo-dev 2005-08-10 13:39:37 UTC
commited xpdf-3.00-r10 with fedora patch which fix the security issue.
Comment 16 Luis Medinas (RETIRED) gentoo-dev 2005-08-10 13:47:06 UTC
Archs please test and stablize xpdf-3.00-r10 asap. it's stable on amd64 and x86.
Comment 17 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-08-10 13:58:57 UTC
Stable on ppc and hppa.
Comment 18 Markus Rothe (RETIRED) gentoo-dev 2005-08-11 02:05:22 UTC
stable on ppc64
Comment 19 Gustavo Zacarias (RETIRED) gentoo-dev 2005-08-11 07:14:44 UTC
sparc stable.
Comment 20 Fernando J. Pereda (RETIRED) gentoo-dev 2005-08-12 06:01:42 UTC
alpha stable
Comment 21 Aaron Walker (RETIRED) gentoo-dev 2005-08-12 06:44:20 UTC
Stable on mips.
Comment 22 Thierry Carrez (RETIRED) gentoo-dev 2005-08-12 08:36:43 UTC
That would do a good common GLSA with kpdf and gpdf... since both are mostly
ready too.
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2005-08-12 08:38:43 UTC
Security: Don't forget to talk about the CUPS DoS problem in the GLSA, since
it's what this vulnerability in XPDF can most likely be used for.
Comment 24 Bryan Ƙstergaard (RETIRED) gentoo-dev 2005-08-12 14:06:28 UTC
Stable on ia64.
Comment 25 Sune Kloppenborg Jeppesen gentoo-dev 2005-08-15 22:27:14 UTC
GLSA ID:  200508-08