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 attachment 63959 [details, diff] 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 attachment 65072 [details, diff] 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
