Bug 152819 - overflow bugs in xpdf - CAN-2004-0888, CAN-2004-0889
overflow bugs in xpdf - CAN-2004-0888, CAN-2004-0889
Status: CLOSED CURRENTRELEASE
Product: Fedora Legacy
Classification: Retired
Component: General (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Fedora Legacy Bugs
1, LEGACY, rh73, rh90
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-21 11:03 EDT by Michal Jaegermann
Modified: 2008-05-01 11:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Lawrence 2005-03-30 18:28:34 EST
FEDORA-2004-348 security update notification showed up which says the following:

During a source code audit, Chris Evans and others discovered a number
of integer overflow bugs that affected all versions of xpdf. An
attacker could construct a carefully crafted PDF file that could cause
xpdf to crash or possibly execute arbitrary code when opened.

Also this in a changelog:

- Apply patch to fix can-2004-0888, can-2004-0889
- Fix xpdf crash when selecting outline without page reference #134993
- Fix locale issue #133911
- Fix default fonts setting

Although personally I am using xpdf-3.00 even on RH7.3 machine for a long
time an initial peek at sources seem to indicate that indeed all versions
of xpdf are affected.



------- Additional Comments From rob.myers@gtri.gatech.edu 2004-10-21 11:39:48 ----

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135394



------- Additional Comments From marcdeslauriers@videotron.ca 2004-10-21 14:23:54 ----

Red Hat's bugzilla:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135394
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393




------- Additional Comments From michal@harddata.com 2004-10-21 19:49:45 ----

Created an attachment (id=890)
a patch for xpdf-1.00 as supplied with RH7.3

This is what I could fit, with some edits, from new patches into a structure
of xpdf-1.00.  It is difficult to say if this solves all problems but it
has this obviuos advantage that with that patch added on the top of
xpdf-1.00-7.src.rpm the program still compiles and works. :-)

xpdf-1.00 is using tmpnam() which cannot be eliminated without a deep 
intervention in sources.  This usage is claimed to be "safe" and it does look
that way.

The real solution to all these issues is to switch to a patched xpdf-3.00
(which is doable on RH7.3).




------- Additional Comments From marcdeslauriers@videotron.ca 2004-10-23 01:41:31 ----

Created an attachment (id=893)
Mandrake patch

Here is Mandrake's patch for xpdf-1.01.

Can someone take a look at it and comment please.



------- Additional Comments From michal@harddata.com 2004-10-23 07:25:37 ----

Comments about patches from attachement.

'Catalog.cc' part is in both practically identical (differs by a comment).
The first two 'XRef.cc' chunks from Mandrake patch are missing in the first
one and can be trivially dropped in.  The next one is already in as a part
of a bigger chunk in the first path.  The last one from Mandrake seem to
missing but, for a change, Mandrake skips on another check.

I think that I will combine the two.  It should not take very long.



------- Additional Comments From michal@harddata.com 2004-10-23 08:50:01 ----

Created an attachment (id=894)
"combined" patch for xpdf-1.00-7

Closer examination shows that Mandrake patch adds just two extra "sanity"
checks 
(and is  missing some other pieces lifted from updates to FC2).  The first of 
these checks cannot be added "as is" due to a 'errCode = errDamaged;'
assignment
where both sides are not defined.  Probably depends on some earlier Mandrake
patches but this line can be just skipped.

xpdf-1.00-7.src.rpm with an added patch from this attachment compiles and
works.



------- Additional Comments From rob.myers@gtri.gatech.edu 2004-10-25 06:02:35 ----

Created an attachment (id=898)
proposed patch for xpdf-2.03-1

neither patches for xpdf-3.xx or xpdf-1.xx apply directly to xpdf-2.03.  i
attempted to grab the important bits from those patches and apply them to
xpdf-2.03.  i have verified sane failure with each of the bad pdfs available
from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393

if someone could look over this patch to make sure that i have not omitted
anything...



------- Additional Comments From michal@harddata.com 2004-10-25 08:53:16 ----

Created an attachment (id=899)
one more version of a patch for xpdf-1.00

A reference to bugzilla with test pdf files turned out to be very useful.
Thanks!

It allowed me to catch that although a comment in Catalog.cc says:
  // The gcc doesnt optimize this away, so this check is ok,
  // even if it looks like a pagesSize != pagesSize check.
this is actually not always true; possibly with some versions of gcc.  It looks
like that if a variable in question was just assigned to before a test then
this is not optimized away.  Relaying on obscure features of an optimizer does
not seem like a good plan, especially for security fixes.  I converted all such
tests in this patch to use an assignment to an auxilliary variable.
xpdf-1.00-7 plus this patch rejects all bad test pdf files.



------- Additional Comments From michal@harddata.com 2004-10-25 14:51:11 ----

re comment #7:

AFAICS the patch looks all right; but I was only reading it and not trying
to test.  You may still want to check if you are not affected by optimizer
issues like those detailed in comment #8.  It seems that none of
"bad pdfs" triggers tests from Catalog.cc.  Viewing a non-corrupted file
under a debugger may get you there and then you can check if that test
is even considered; or you can try to disassemble, in gdb, that line and
see if you are getting any code you would expect there.

BTW - a patched xpdf-3.00 recompiled on rh7.3 system, and without my
recent "anti-optimizer" changes, rejects all files from a test set but
I did not check yet what happens there in Catalog.cc.  I still do not like
that "now you see it, now you don't" aspect of the code.



------- Additional Comments From michal@harddata.com 2004-10-28 04:30:39 ----

https://rhn.redhat.com/errata/RHSA-2004-592.html
showed up. A patch from listed there xpdf-2.02-9.3.src.rpm should be
easy to compare with the one proposed for 2.03-1



------- Additional Comments From rob.myers@gtri.gatech.edu 2004-10-28 06:52:20 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Here are updated cups packages to QA for rh73, rh9 and fc1:
 
these CAN's should all be fixed:
CAN-2004-0888,0889 xpdf integer overflows
 
michal's patch was used for xpdf-1.00
redhat's patch was used for xpdf-2.0x
added simple xfont patch for xpdf-2.0x from redhat
 
changelogs:
rh73:
* Thu Oct 28 2004 Rob Myers <rob.myers@gtri.gatech.edu> 1.00-7.1.legacy
- - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186)
 
rh9:
* Thu Oct 28 2004 Rob Myers <rob.myers@gtri.gatech.edu> 2.01-11.1.legacy
- - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186)
- - added simple non-security patch for xfont fix
 
fc1:
* Thu Oct 21 2004 Rob Myers <rob.myers@gtri.gatech.edu> 1:2.03-1.1.legacy
- - patch for CAN-2004-0888 CAN-2004-0889 (FL #2186)
- - include simple non-security xfont patch
- - fix files listed twice for %{_datadir}/xpdf/locales
 
sha1sums:
 
rh73:
53dd2e385ae1fd0be76e796c78d27158400520db  xpdf-1.00-7.1.legacy.i386.rpm
9dda9a5d963102a14dd8115298ae449398d46f81  xpdf-1.00-7.1.legacy.src.rpm
3346ba3f8f7fd8d0e5d8a28a53f60ac9e3742c1c 
xpdf-chinese-simplified-1.00-7.1.legacy.i386.rpm
c195ac98130cfb30b04dad4bfe47f1acedf94853 
xpdf-chinese-traditional-1.00-7.1.legacy.i386.rpm
e497ec78eb00c8fe28b0c04d629c5fd1ec56b498  xpdf-japanese-1.00-7.1.legacy.i386.rpm
ef978836d35bfb9126470dfa0d96903522fd8c9a  xpdf-korean-1.00-7.1.legacy.i386.rpm
 
rh9:
e915eb6ccda9a31b1649e4985f34bc31e906e326  xpdf-2.01-11.1.legacy.i386.rpm
64afd548881ea331db3566eac16b73fe7b052ee1  xpdf-2.01-11.1.legacy.src.rpm
5cc270a154e064dc97ecfc7c7d0425d48eb193d9 
xpdf-chinese-simplified-2.01-11.1.legacy.i386.rpm
c18694dfa88a08117864b7377167288cf6ff1d89 
xpdf-chinese-traditional-2.01-11.1.legacy.i386.rpm
92d80db603f52a23dea2029dc23c66b09a14b436  xpdf-debuginfo-2.01-11.1.legacy.i386.rpm
e6d4970eebc45a69d7151798b464da66409ff427  xpdf-japanese-2.01-11.1.legacy.i386.rpm
8617305ed57a218d348f4710857efc02b9e87ac5  xpdf-korean-2.01-11.1.legacy.i386.rpm
 
fc1:
00b6beb2d7be7c40369f2d4185ce75e573efc252  xpdf-2.03-1.1.legacy.i386.rpm
38a0d62526625366068ba1a479f3f949ba6715fe  xpdf-2.03-1.1.legacy.src.rpm
ad158552141b3c93bb320660f0ef740b4002b7de  xpdf-debuginfo-2.03-1.1.legacy.i386.rpm
 
files:
 
rh73:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-1.00-7.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-1.00-7.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-chinese-simplified-1.00-7.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-chinese-traditional-1.00-7.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-japanese-1.00-7.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-korean-1.00-7.1.legacy.i386.rpm
 
rh9:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-2.01-11.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-2.01-11.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-chinese-simplified-2.01-11.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-chinese-traditional-2.01-11.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-debuginfo-2.01-11.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-japanese-2.01-11.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-korean-2.01-11.1.legacy.i386.rpm
 
fc1:
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-2.03-1.1.legacy.src.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-2.03-1.1.legacy.i386.rpm
http://www.stl.gtri.gatech.edu/rmyers/fedoralegacy/xpdf-debuginfo-2.03-1.1.legacy.i386.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
 
iD8DBQFBgSNItU2XAt1OWnsRAkjcAJsGnYHUnVrVegRv85LMO0Yg0ca2KgCeK6jr
yx4iR83D5L6L4aI1Yq+XV7I=
=+Vhl
-----END PGP SIGNATURE-----




------- Additional Comments From fedora-extras@deesconsulting.com 2004-11-03 21:50:29 ----

Installing the src.rpm for FC1: 
warning: user machbuild does not exist - using root  
warning: group machbuild does not exist - using root  
 
Otherwise, it installs fine and compiles perfectly. 
Opening the test pdfs on the RedHat bug just gives an error, no crash. 



------- Additional Comments From fedora-legacy-bugzilla-2004@fumika.jp 2004-11-11 22:14:41 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I did QA on RH9 package:
xpdf-2.01-11.1.legacy.i386.rpm
xpdf-2.01-11.1.legacy.src.rpm
xpdf-chinese-simplified-2.01-11.1.legacy.i386.rpm
xpdf-chinese-traditional-2.01-11.1.legacy.i386.rpm
xpdf-japanese-2.01-11.1.legacy.i386.rpm
xpdf-korean-2.01-11.1.legacy.i386.rpm

sha1sum matches
rpm signature ok
source files ok
spec file ok
patches ok (vs. RHEL3 xpdf-2.02-9.3.src.rpm)
src rebuilds ok
rpm-build-compare script ok
installs ok
runs ok
5 demo pdfs in Red Hat Bugzilla ok(no crash)
+PUBLISH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFBlG6UuZYb5AhVqVoRAj46AKDjH8q8RDgw1LO62+N4OvXH+F3TvQCfbWJq
1SQlW+qoR8WnIUGzqFkWnE0=
=P7Ym
-----END PGP SIGNATURE-----




------- Additional Comments From josh.kayse@gtri.gatech.edu 2004-11-16 07:56:30 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I QAd the FC1 package:

38a0d62526625366068ba1a479f3f949ba6715fe  xpdf-2.03-1.1.legacy.src.rpm

- - source identical to previous
- - patches look good
- - builds cleanly
- - spec looks good
- - installs cleanly
- - runs good
- - pdfs give error

+ PUBLISH

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBmj89wnUFCSDmt7ERAu7bAJ0aTkquRDINxzqs8+MLCQ3Nl7mYEQCghEc+
/5KfFQvCGeMtX4khBkLc1ak=
=bfy0
-----END PGP SIGNATURE-----




------- Additional Comments From michal@harddata.com 2004-11-16 13:36:30 ----

> - - pdfs give error

Hopefuly this really meant "_bad_ pdfs give error instead of crash". :-)



------- Additional Comments From josh.kayse@gtri.gatech.edu 2004-11-17 05:46:56 ----

yes...bad pdfs give error...
my bad
thanks



------- Additional Comments From marcdeslauriers@videotron.ca 2004-11-25 17:28:43 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

QA on the rh73 package:

9dda9a5d963102a14dd8115298ae449398d46f81  xpdf-1.00-7.1.legacy.src.rpm

- - Source files match previous release
- - Michal's patch looks good
- - Spec file changes good
- - Builds, installs and runs OK

+PUBLISH

QA on the rh9 package:

64afd548881ea331db3566eac16b73fe7b052ee1  xpdf-2.01-11.1.legacy.src.rpm

- - Source files match previous release
- - Patch is good
- - Spec file changes good
- - Builds, installs and runs OK

+PUBLISH

QA on the fc1 package:

38a0d62526625366068ba1a479f3f949ba6715fe  xpdf-2.03-1.1.legacy.src.rpm

- - Source files match previous release
- - Patch is good
- - Spec file changes good
- - Builds, installs and runs OK

+PUBLISH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD4DBQFBpqMNLMAs/0C4zNoRAk6WAJdUTh7CKGtYsX0jfKFYItwD900GAJ0aHTZN
m5naxTVwxPIZzCuqBPyllA==
=AZrF
-----END PGP SIGNATURE-----




------- Additional Comments From florin@andrew.cmu.edu 2004-11-29 06:07:24 ----

QA on the RH73 binary packages:

xpdf-1.00-7.1.legacy.i386.rpm doesn't contain the xpdf binary /usr/bin/xpdf

Rebuilding from src generates a good binary package.



------- Additional Comments From rob.myers@gtri.gatech.edu 2004-11-29 06:34:38 ----

thanks, florin. looking back at the mach build log, this warning is clear:

configure: warning: Couldn't find X -- you will be able to compile
        pdftops, pdftotext, pdfinfo, pdffonts, and pdfimages, but not xpdf

looks like a missing XFree86-devel BuildPrereq for rh73.




------- Additional Comments From marcdeslauriers@videotron.ca 2004-12-01 18:22:50 ----

Packages were pushed to updates-testing.



------- Additional Comments From dwb7@ccmr.cornell.edu 2004-12-06 12:22:25 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Installed xpdf on rh 7.3

Seems to function properly.

Signature verified.

sha1sum:

sha1sum -b xpdf-1.00-7.2.legacy.i386.rpm 
017fba06b9ba578aad48f07ec3c2e6f0f954d781 *xpdf-1.00-7.2.legacy.i386.rpm

+VERIFY

- -DWB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFBtNtZSY7s7uPf/IURAmIQAJwJCAjG/R1HdSyPo6M7YBfYMHkXOwCgpaKl
OsgjPYfxo2ZxlUMWUf8DuIw=
=j/xL
-----END PGP SIGNATURE-----



------- Additional Comments From dom@earth.li 2004-12-10 02:22:50 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

017fba06b9ba578aad48f07ec3c2e6f0f954d781  xpdf-1.00-7.2.legacy.i386.rpm

- - installs ok
- - runs ok

VERIFY rh73
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBuZULYzuFKFF44qURAslWAJ9WnOARii5+65XM7BTfIngwEtam3wCgo0W3
yxT0IgRfEjpvKMvVXVlCS3U=
=4b3O
-----END PGP SIGNATURE-----




------- Additional Comments From pekkas@netcore.fi 2004-12-13 08:34:53 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

cb457f94ba08d7c8a8750b41596959a6e8e4df01  xpdf-2.01-11.1.legacy.i386.rpm

Signature verified.

Seems to work OK.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFBveCdGHbTkzxSL7QRAhDBAKCK6VRkaK3EjjdSyksyJkIueGtgcgCggCfI
3DNdKRbPn8ryPvtY8liO3oc=
=rtZV
-----END PGP SIGNATURE-----




------- Additional Comments From pekkas@netcore.fi 2004-12-14 10:18:38 ----

In case it wasn't clear, my above message was meant as a +VERIFY :)



------- Additional Comments From bugzilla.fedora.us@beej.org 2004-12-21 23:28:36 ----

there's another possibly exploitable buffer overflow recently disclosed by
iDefense:
http://www.idefense.com/application/poi/display?id=172&type=vulnerabilities

CAN-2004-1125



------- Additional Comments From marcdeslauriers@videotron.ca 2004-12-22 05:37:21 ----

The new issue should be covered in it's own bug as these packages are about to
get released.



------- Additional Comments From rob.myers@gtri.gatech.edu 2004-12-22 13:21:27 ----

see bug #2352 for CAN-2004-1125.



------- Additional Comments From sheltren@cs.ucsb.edu 2005-01-13 07:03:43 ----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Verify for FC1 package:

119e2f11d6037391a9f687c35795afbb563f7b68  xpdf-2.03-1.1.legacy.i386.rpm

Signatures are OK
Package installs OK
xpdf runs fine - I opened a few pdf documents without problems.

FC1 VERIFY++
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFB5qlSKe7MLJjUbNMRAvyrAKC0xq0kcTsAvCqLI8BjxMSZlWAv4gCgmz+J
ymPAqvrJI/cwRUXDiH1xCO8=
=y6XJ
-----END PGP SIGNATURE-----



------- Additional Comments From marcdeslauriers@videotron.ca 2005-02-10 13:03:45 ----

Packages were officially released.



------- Bug moved to this database by dkl@redhat.com 2005-03-30 18:28 -------

This bug previously known as bug 2186 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=2186
Originally filed under the Fedora Legacy product and General component.

Attachments:
a patch for xpdf-1.00 as supplied with RH7.3
https://bugzilla.fedora.us/attachment.cgi?action=view&id=890
Mandrake patch
https://bugzilla.fedora.us/attachment.cgi?action=view&id=893
"combined" patch for xpdf-1.00-7
https://bugzilla.fedora.us/attachment.cgi?action=view&id=894
proposed patch for xpdf-2.03-1
https://bugzilla.fedora.us/attachment.cgi?action=view&id=898
one more version of a patch for xpdf-1.00
https://bugzilla.fedora.us/attachment.cgi?action=view&id=899

Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.


Note You need to log in before you can comment on or make changes to this bug.