See bug #99769.
Pulling in Allanonjl
xpdf/SplashOutputDev.cc <-- this file is not distributed with the xpdf in gpdf,
but all the other files are.
The top of the included README says:
Its not clear to me that this version is affected without a test pdf.
Heres the GNOME viewcvs view of the xpdf directory, and mysteriously,
SplashOutputDev.cc is there, but SplashOutputDev.cc does not appear in the
tarballs. Seems like the file(s) is/are excluded when they build it.
The provided patch was a tad different in a few places. I'm attaching my patch
which is just a little bit different.
However, a major portion of the diff could not be applied because
SplashOutputDev.cc is not included in gpdf's source. Its not even in the
Makefile, so I don't think its supposed to be there either. The content doesn't
seem to be in any other file in the gpdf package either.
My patch applies cleanly to 2.8.3 what I used for testing, but leaves out a
large portion at the end of the supplied patch to SplashOutputDev.cc.
Bottom line is that even with my patch gpdf is still affected ( tested with a
bad pdf ).
Created attachment 64745 [details, diff]
i also have problems applying it to xpdf, maybe another suse patch is needed
With the 2nd patch applied in the parent bug, everything applies cleanly except
for the missing file SplashOutputDev.cc ( in both patches ). Gpdf is still affected.
So, I did some more digging.
Basically, the gpdf guys created their own OutputDev called GPOutputDev.cc. I
believe this is where they implement the functionality of SplashOutputDev.cc.
Tonight / Tommorrow I'll try and hack out a patch against GPOutputDev.cc that
Have a try, if you don't succeed, we can wait for an official gpdf release
taking this into account...
client-based DoS -> downgrading severity
AllanonJL: any success in patching ? anything up in gpdf upstream ?
Adding herd alias rather than individual names.
I didn't successfully patch it w/o breaking functionality of gpdf. While the
file is similar, I didn't have enough time to fully understand what they are
doing in GPOutputDev. ( I may have time this weekend )
nothing has changed upstream for gpdf.
So we should wait for upstream.
Maybe someone who already has a Gnome bugzilla account can post a bug there ?
You can point them to http://www.kde.org/info/security/advisory-20050809-1.txt
Note: Do not provide the PoC PDF on Bugzilla, but you can send it to the
developer in charge in case of need.
Created attachment 65732 [details, diff]
Patch from Mandriva SRPMS, apparently originally from RedHat.
AllanonJL: you could try this new one and see if it fixes.
patch applied, tested, and committed.
Arches, please test gpdf-2.10.0-r1 and mark stable accordingly.
stable on ppc64
Marked Stable on AMD64.
I resurrected gpdf-2.10.0.ebuild until -r1 is stable. Removing the stable
version out from under everyone is not the way we do it.
Stable on ppc.
Stable on alpha + ia64.
Stable on hppa.