| Summary: | app-text/xpdf another issue (CAN-2005-2097) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> | ||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | normal | CC: | printing | ||||||
| Priority: | High | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | A3 [glsa] koon | ||||||||
| Package list: | Runtime testing required: | --- | |||||||
| Attachments: |
|
||||||||
|
Description
Sune Kloppenborg Jeppesen (RETIRED)
2005-07-21 03:07:14 UTC
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 |