Bugzilla Bug 99769

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.

Created an attachment (id=63959) [details]
xpdf-font-optimize.dif

Patch from Marcus Meissner <meissner@suse.de>

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 

Adding arch security liaisons to CC. 

Created an attachment (id=65072) [details]
xpdf-3.00-ttf-cid-fix.dif

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.

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.

Adding KillerFox. He's the security guy on hppa and he will handle this bug.

This will be made public on Tuesday. Would be a good thing to have patched
versions at that date...

The initial description talks about an attached PDF but there is no PDF
attached.  Where can I find this to test with?

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

with the second patch the first patch applies fine, but xpdf fails to compile: 
 
make[1]: Entering directory 
`/var/tmp/portage/xpdf-3.00-r10/work/xpdf-3.00/splash' 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c Splash.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashBitmap.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashClip.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashFTFont.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashFTFontEngine.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashFTFontFile.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashFont.cc 
x86_64-pc-linux-gnu-g++ -O2 -pipe -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi 
-I.   -c SplashFontEngine.cc 
SplashFontEngine.cc: In member function `SplashFontFile* 
SplashFontEngine::loadType1Font(SplashFontFileID*, SplashFontSrc*, char**)': 
SplashFontEngine.cc:114: error: no matching function for call to 
`SplashT1FontEngine::loadType1Font(SplashFontFileID*&, SplashFontSrc*&, 
char**&)' 
SplashT1FontEngine.h:36: note: candidates are: SplashFontFile* 
SplashT1FontEngine::loadType1Font(SplashFontFileID*, char*, GBool, char**) 
SplashFontEngine.cc: In member function `SplashFontFile* 
SplashFontEngine::loadType1CFont(SplashFontFileID*, SplashFontSrc*, char**)': 
SplashFontEngine.cc:140: error: no matching function for call to 
`SplashT1FontEngine::loadType1CFont(SplashFontFileID*&, SplashFontSrc*&, 
char**&)' 
SplashT1FontEngine.h:38: note: candidates are: SplashFontFile* 
SplashT1FontEngine::loadType1CFont(SplashFontFileID*, char*, GBool, char**) 
make[1]: *** [SplashFontEngine.o] Error 1 
make[1]: Leaving directory 
`/var/tmp/portage/xpdf-3.00-r10/work/xpdf-3.00/splash' 
make: *** [all] Error 2 
 

Beh. Xpdf 3.01 is scheduled for this week, so I guess we'd better wait for it.

Keeping this one at "Normal" level since it affects indirectly CUPS.

Now public

===========================================================
Ubuntu Security Notice USN-163-1	    August 09, 2005
xpdf vulnerability
CAN-2005-2097
===========================================================
[...]
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
attack.
[...]
We might find something interesting in :
http://security.ubuntu.com/ubuntu/pool/main/x/xpdf/xpdf_3.00-11ubuntu3.1.diff.gz
Size/MD5:    49233 4cd029c1e95456692b26dcfdb6d53ce8

Otherwise maybe just wait for upstream 3.01 ?

commited xpdf-3.00-r10 with fedora patch which fix the security issue.

Archs please test and stablize xpdf-3.00-r10 asap. it's stable on amd64 and
x86.
Thanks

Stable on ppc and hppa.

stable on ppc64

sparc stable.

alpha stable

Stable on mips.

That would do a good common GLSA with kpdf and gpdf... since both are mostly
ready too.

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.

Stable on ia64.

GLSA ID:  200508-08