Bug 96561 (CVE-2005-2097)

Created attachment 42033 [details]
corrupted PDF file

which tmp file? what is the contents of the file? for me it doesn't even open 
something in /tmp:  
 
$ lsof | grep kpdf | grep tmp 
kpdf      20341       dirk  mem       REG        3,5   1337356    
1002175 /var/tmp/kdecache-dirk/ksycoca 
kpdf      20341       dirk   10r      REG        3,5   1337356    
1002175 /var/tmp/kdecache-dirk/ksycoca 

same here. Works fine  - two pages  

the file differs from run to run. file tells me that it contains  
  
# file AoCRgp  
AoCRgp: TrueType font data 
 
this is easily reproduceable. Please tell me what information you need. 

hmm, it doesn't go away if you update to kpdf 3.4.1 from supplementary? 

hmm, no, that won't help. there is a fix for this problem in trunk, probably 
thats what coolo and I use.  
 
Try the kdegraphics-kpdf rpm from:  
 
/work/built/mbuild/g131-dmueller-97/9.3-i386 
 
which contains a backport of the relevant commit.  

looks like the problem is fixed with that package. 

ok. this is again fascinating. The patch that fixes the issue is written  
by a suse employee, it was checked into the KDE repository, and still its  
not anywhere near the actual suse package.   
  
I've checked in an updated package to STABLE and PLUS.  
  

question is if we can consider this a denial of service 
attack and need to release updated packages? 
 
or is this just a trivial problem? 

there are probably many ways to fill /tmp..  

but still doing something beyond simply crashing by opening a pdf is a bit 
annoying. Given that this was a pretty prominent pdf files, a lot of users 
probably ran into this bug.  
 
AJ, approve an update? 

AJ, approve an update? 

(my idea of an update would be to sync kpdf to the version from upcoming KDE 
3.4.2 which includes among many other fixes the one necessary for this). Of 
course the single commit only would do it as well - its already in the suse 
pdf package btw.  

suse pdf -> suse xpdf  

then we will probably have to update *pdf* ... :( 

Just add the one fix that's needed.

Please use: SM-Tracker-1803

We really need to be careful here when we treat it as security bug. The same  
bug is most likely in the sles8 xpdf and in cups (there it might really hurt  
actually).  
 
If we agree it's no security problem, but a nice to fix kpdf problem, we can 
go on and update 9.3's kpdf with more than this fix. 

cups uses xpdf 2.0 - unlikely to be affected, though not impossible.  
 
the patch correcting this issue comes from suse xpdf actually, its a commit of 
all the custom patches over plain xpdf from the suse xpdf. to find out which 
of the 22 patches actually fixes this particular issue is nontrivial.  
 
Furthermore I don't see why we ship patches against xpdf but don't want them 
to be included in the update kpdf package? 
 
security-team: do we treat it as security bug or not? 
 
 

Sorry, but I want to cross-check about the presence of the patch in cups. 
Dirk: which suse xpdf patch are you talking about? 

I think the bug is only in xpdf 3 versions ... fortunately, which limits the 
number of packages.  (Splash*.c, right?) 
  
I would classify this as a remote denial of service problem, so it is a  
security problem.  

The whole handling of this bug is substandard. 
 
vendor-sec not notified. 
 
no one bothered to find out the real patch that helps. 
 
no one cced takashi 

Created attachment 42729 [details]
xpdf-font-optimize.dif

trial and error shows that this patch helped.

notified vendor-sec 

CAN-2005-2097 

Created attachment 43513 [details]
upstream patch

The patch #22 should fix this problem since it changes the code to avoid temp
files.  But it alone can't be applied cleanly.  It's applied after another patch.
(also kpdf has different indentation, so it can't be applied as it is.)

The patch #25 has nothing to do with patch #22.  It fixes the size of code table
detected from the font.  It will still create temp files, and they remain if the
app  crashes or quits unexpectedly.

yeah, finally I found a gdb that works, so debugging this problem became easy. 
it comes from this chunk of code in FoFiTrueType::writeTTF: 
 
          k = locaTable[j].origOffset; 
          if (checkRegion(pos + k, n)) { 
            (*outputFunc)(outputStream, (char *)file + pos + k, n); 
          } else { 
            for (k = 0; k < n; ++k) { 
              (*outputFunc)(outputStream, "\0", 1); 
            } 
 
by interpreting trailing garbage in the pdf file as a ttf font, it tries to 
fixup the broken glyph table (which contains all kinds of weirdnesses 
including negative lengths), it almost always falls into the !checkRegion 
case, which writes out a huge amount of 0 bytes.  
 
The xpdf-font-optimize avoids this code path by patching out the single 
location in the source where this obscure writeTTF method is used.  

suse xpdf was never affected, cups is not affected because this code path does   
not exist in xpdf 2.x.    
   
For KDE, the versions affected by this bug is kpdf as included in KDE 3.3.1 up   
to including KDE 3.4.1. older or newer versions are not affected, so the only   
version for SUSE that is affected is SL 9.3, which includes KDE 3.4.0. no   
other SLES or SL version affected as far as I can see. Therefore I wonder if  
it wouldn't be better to backport the xpdf improvements of kpdf 3.4.2 (which  
is essentially the suse patchset of xpdf, as shipped in SL starting with  
SL9.1) to fix this bug, or if I should apply the minimal upstream patch. 
[security-team answer here] 
  
gpdf includes the vulnerable code as well, but I haven't investigated how 
they're affected. CC'ing them.  

Feel free to include the patch you prefer as long as it fixes the problem. 

For gpdf: Only 9.3 and STABLE/PLUS are affected. Patch submitted.

Using half of the patch in comment #25 (for FoFiTrueType.cc, file
SplashOutputDev.cc does not exist).

updated kdegraphics3 for 9.3 submitted.  

public disclosure probably on Tuesday 9.8.2005 / 15:00 GMT. 

approved gpdf and kdegraphics3-pdf patch.  
 
marking fixed 

CVE-2005-2097: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:N/I:N/A:P)