Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 77888 - app-text/xpdf: the saga continues
Summary: app-text/xpdf: the saga continues
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A2 [glsa] koon
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-13 13:11 UTC by Sune Kloppenborg Jeppesen
Modified: 2006-03-23 19:28 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
CAN-2005-0064.patch (CAN-2005-0064.patch,773 bytes, patch)
2005-01-15 11:50 UTC, Thierry Carrez (RETIRED)
no flags Details | Diff
xpdf-3.00-r8.ebuild (xpdf-3.00-r8.ebuild,3.44 KB, text/plain)
2005-01-16 03:32 UTC, Heinrich Wendel (RETIRED)
no flags Details
xpdf-3.00pl3.patch (xpdf-3.00pl3.patch,346 bytes, patch)
2005-01-19 00:25 UTC, Thierry Carrez (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen gentoo-dev 2005-01-13 13:11:07 UTC
Multiple Unix/Linux Vendor Xpdf makeFileKey2 Stack Overflow 

iDEFENSE Security Advisory 01.18.05
http://www.idefense.com/application/poi/display?type=vulnerabilities
January 18, 2005

I. BACKGROUND

Xpdf is an open-source viewer for PDF files. More information is 
available at the following site:

http://www.foolabs.com/xpdf/


II. DESCRIPTION

Remote exploitation of a buffer overflow vulnerability in the xpdf PDF 
viewer included in multiple Unix and Linux distributions could allow for 
arbitrary code execution as the user viewing a PDF file. 

The vulnerability specifically exists due to insufficient bounds 
checking while processing a PDF file that provides malicious values in 
the /Encrypt /Length tag. The offending code can be found in the 
Decrypt::makeFileKey2 function in the source file xpdf/Decrypt.cc. 

GBool Decrypt::makeFileKey2(int encVersion, int encRevision, int keyLength,
                            GString *ownerKey, GString *userKey,
                            int permissions, GString *fileID,
                            GString *userPassword, Guchar *fileKey) {
      Guchar *buf;
      Guchar test[32];
      Guchar fState[256];
      Guchar tmpKey[16];
      Guchar fx, fy;
      int len, i, j;
      GBool ok;
      ...

            memcpy(test, userKey->getCString(), 32);
            for (i = 19; i >= 0; --i) {
                  for (j = 0; j < keyLength; ++j) {
[overflow]               tmpKey[j] = fileKey[j] ^ i; 
                  }
            ...
      }
      ...
} 

In this piece of code, the keyLength value is ultimately supplied by the 
PDF file. This allows an attacker to specify an arbitrarily large value 
and overwrite portions of stack memory. As a consequence, arbitrary code 
execution is possible.

III. ANALYSIS

Successful exploitation of this vulnerability leads to arbitrary code 
execution as the user who opened the malicious file. An attacker would 
have to convince a target to open the provided file in order to exploit 
this vulnerability, thus lessening the impact.

Exploitation can be performed reliably, especially with knowledge of the 
target system.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in version 
3.00 of xpdf. It is suspected previous versions are vulnerable. 

The following Linux vendors may be affected by this vulnerability:

	Novell Inc. (SUSE) 
	Red Hat Inc. 
	The Fedora Project 
	Debian Project 
	Gentoo Foundation Inc. 
	The FreeBSD Project 
	OpenBSD 

V. WORKAROUND

Only open PDF files from trusted individuals.

VI. VENDOR RESPONSE

A patch to address this issue is available at:

    ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.00pl3.patch

Updated binaries (ver. 3.00pl3) to address this issue are available at:

    http://www.foolabs.com/xpdf/download.html

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0064 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

01/06/2004  Initial vendor notification
01/12/2004  Initial vendor response
01/18/2004  Coordinated public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp

X. LEGAL NOTICES

Copyright 
Comment 1 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-13 13:11:07 UTC
Multiple Unix/Linux Vendor Xpdf makeFileKey2 Stack Overflow 

iDEFENSE Security Advisory 01.18.05
http://www.idefense.com/application/poi/display?type=vulnerabilities
January 18, 2005

I. BACKGROUND

Xpdf is an open-source viewer for PDF files. More information is 
available at the following site:

http://www.foolabs.com/xpdf/


II. DESCRIPTION

Remote exploitation of a buffer overflow vulnerability in the xpdf PDF 
viewer included in multiple Unix and Linux distributions could allow for 
arbitrary code execution as the user viewing a PDF file. 

The vulnerability specifically exists due to insufficient bounds 
checking while processing a PDF file that provides malicious values in 
the /Encrypt /Length tag. The offending code can be found in the 
Decrypt::makeFileKey2 function in the source file xpdf/Decrypt.cc. 

GBool Decrypt::makeFileKey2(int encVersion, int encRevision, int keyLength,
                            GString *ownerKey, GString *userKey,
                            int permissions, GString *fileID,
                            GString *userPassword, Guchar *fileKey) {
      Guchar *buf;
      Guchar test[32];
      Guchar fState[256];
      Guchar tmpKey[16];
      Guchar fx, fy;
      int len, i, j;
      GBool ok;
      ...

            memcpy(test, userKey->getCString(), 32);
            for (i = 19; i >= 0; --i) {
                  for (j = 0; j < keyLength; ++j) {
[overflow]               tmpKey[j] = fileKey[j] ^ i; 
                  }
            ...
      }
      ...
} 

In this piece of code, the keyLength value is ultimately supplied by the 
PDF file. This allows an attacker to specify an arbitrarily large value 
and overwrite portions of stack memory. As a consequence, arbitrary code 
execution is possible.

III. ANALYSIS

Successful exploitation of this vulnerability leads to arbitrary code 
execution as the user who opened the malicious file. An attacker would 
have to convince a target to open the provided file in order to exploit 
this vulnerability, thus lessening the impact.

Exploitation can be performed reliably, especially with knowledge of the 
target system.

IV. DETECTION

iDEFENSE has confirmed the existence of this vulnerability in version 
3.00 of xpdf. It is suspected previous versions are vulnerable. 

The following Linux vendors may be affected by this vulnerability:

	Novell Inc. (SUSE) 
	Red Hat Inc. 
	The Fedora Project 
	Debian Project 
	Gentoo Foundation Inc. 
	The FreeBSD Project 
	OpenBSD 

V. WORKAROUND

Only open PDF files from trusted individuals.

VI. VENDOR RESPONSE

A patch to address this issue is available at:

    ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.00pl3.patch

Updated binaries (ver. 3.00pl3) to address this issue are available at:

    http://www.foolabs.com/xpdf/download.html

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
names CAN-2005-0064 to these issues. This is a candidate for inclusion
in the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

01/06/2004  Initial vendor notification
01/12/2004  Initial vendor response
01/18/2004  Coordinated public disclosure

IX. CREDIT

The discoverer of this vulnerability wishes to remain anonymous.

Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp

X. LEGAL NOTICES

Copyright © 2004 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@idefense.com for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
Comment 2 Thierry Carrez (RETIRED) gentoo-dev 2005-01-14 02:18:38 UTC
declassifying signoff=jaervosz/koon
Waiting for more definitive patch
Comment 3 Thierry Carrez (RETIRED) gentoo-dev 2005-01-15 11:50:35 UTC
Created attachment 48566 [details, diff]
CAN-2005-0064.patch

Patch from RedHat
Comment 4 solar (RETIRED) gentoo-dev 2005-01-15 12:09:05 UTC
Heinrich Wendel (lanius) is the man for this one. adding him to the CC: 
Comment 5 Thierry Carrez (RETIRED) gentoo-dev 2005-01-15 12:18:57 UTC
Heinrich: An official patch will be available on the 18th (see url above), but if we can prepare and arch-test another one in the meantime, all the better.

We can't commit this to portage until it's public, so please attach the ebuild to the bug so that we let arches test from here.
Comment 6 Heinrich Wendel (RETIRED) gentoo-dev 2005-01-16 03:32:16 UTC
Created attachment 48638 [details]
xpdf-3.00-r8.ebuild

download the patch into your filesdirectory and use this ebuild
Comment 7 Thierry Carrez (RETIRED) gentoo-dev 2005-01-16 11:04:25 UTC
Arches, please test attached ebuild and report success. This is still confidential  until the 18th, we'll try to commit it directly to stable if possible. Calling:

for sparc: fmccor@gentoo.org & weeve@gentoo.org
for amd64: kugelfang@gentoo.org & blubb@gentoo.org
for ppc64: corsair@gentoo.org
for alpha: kloeri@gentoo.org
for ppc: SeJo@gentoo.org
Comment 8 Markus Rothe (RETIRED) gentoo-dev 2005-01-16 11:19:29 UTC
works on ppc64
Comment 9 Danny van Dyk (RETIRED) gentoo-dev 2005-01-16 11:30:26 UTC
Successfully tested on amd64.
Comment 10 Ferris McCormick (RETIRED) gentoo-dev 2005-01-16 16:36:34 UTC
Installs on sparc and seems to work fine for me.
Comment 11 Bryan Østergaard (RETIRED) gentoo-dev 2005-01-17 14:00:55 UTC
Fine on alpha.
Comment 12 Thierry Carrez (RETIRED) gentoo-dev 2005-01-18 03:23:37 UTC
This is going public sometime today, ppc testing is still needed.
Comment 13 Thierry Carrez (RETIRED) gentoo-dev 2005-01-18 06:49:36 UTC
OK apparently this patch is not sufficient. We'll just wait for the upstream official patch... sorry for wasting your time, folks.
Comment 14 Heinrich Wendel (RETIRED) gentoo-dev 2005-01-18 06:51:16 UTC
commited with "alpha amd64 ~hppa ~ia64 ~ppc ppc64 sparc x86"
Comment 15 Heinrich Wendel (RETIRED) gentoo-dev 2005-01-18 06:52:07 UTC
ok, removed the commit again
Comment 16 Thierry Carrez (RETIRED) gentoo-dev 2005-01-18 06:58:11 UTC
Heinrich: keep the engine running, you will have a lot to commit tonight !
Comment 17 Luke Macken (RETIRED) gentoo-dev 2005-01-18 13:58:04 UTC
[ http://www.idefense.com/application/poi/display?id=186 ]

This issue is now public.
Comment 18 Carsten Lohrke (RETIRED) gentoo-dev 2005-01-18 16:27:30 UTC
Do kdegraphics/koffice get their own bugs or did you forget us!? ;)
Comment 19 Sune Kloppenborg Jeppesen gentoo-dev 2005-01-18 22:26:45 UTC
@comment #17

We didn't forget just waited until public disclosure. I've just opend up bug #78619 and bug #78620
Comment 20 Thierry Carrez (RETIRED) gentoo-dev 2005-01-19 00:25:32 UTC
Created attachment 48920 [details, diff]
xpdf-3.00pl3.patch

Upstream patch
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2005-01-19 00:26:44 UTC
Heinrich: Please bump in Portage using the official patch
Comment 22 Heinrich Wendel (RETIRED) gentoo-dev 2005-01-19 05:34:13 UTC
commited
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2005-01-19 07:24:13 UTC
Arches please test & mark 3.00-r8 stable
Target KEYWORDS="alpha amd64 hppa ia64 ppc ppc64 sparc x86"
Comment 24 Ferris McCormick (RETIRED) gentoo-dev 2005-01-19 08:30:20 UTC
Stable for sparc. Installs and tests as good.
Comment 25 Karol Wojtaszek (RETIRED) gentoo-dev 2005-01-19 13:07:13 UTC
Stable on amd64
Comment 26 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-01-19 13:52:03 UTC
Stable on ppc.
Comment 27 Bryan Østergaard (RETIRED) gentoo-dev 2005-01-20 10:08:23 UTC
Stable on alpha.
Comment 28 Markus Rothe (RETIRED) gentoo-dev 2005-01-20 11:36:42 UTC
stable on ppc64
Comment 29 Thierry Carrez (RETIRED) gentoo-dev 2005-01-21 02:11:19 UTC
corsair: ppc64 stable marking doesn't show in KEYWORDS
Comment 30 Markus Rothe (RETIRED) gentoo-dev 2005-01-21 02:36:16 UTC
sorry, now it is definetly marked stable on ppc64
Comment 31 Thierry Carrez (RETIRED) gentoo-dev 2005-01-21 12:45:10 UTC
GLSA 200501-28
hppa, ia64 please mark stable to benefit from GLSA
Comment 32 René Nussbaumer (RETIRED) gentoo-dev 2005-06-26 05:32:10 UTC
Already stable on hppa