Bugzilla – Bug 64840
VUL-0: CVE-2005-0064: xpdf buffer overflow in Decrypt::makeFileKey2
Last modified: 2021-10-27 11:48:39 UTC
We received the following report via vendor-sec. This issue is not public yet, please keep any information about it inside SUSE! Date: Thu, 13 Jan 2005 15:56:10 -0500 From: vendor-disclosure <vendor-disclosure@idefense.com> To: vendor-sec@lst.de Cc: vendor-disclosure <vendor-disclosure@idefense.com> Subject: [vendor-sec] iDEFENSE Security Advisory [IDEF0764] Multiple Unix/Linux Vendor Xpdf makeFileKey2 Stack Overflow The attached advisory will be released on Tuesday January 18th. I am passing it along so that you may begin work on addressing the issue and pass along distribution specific patches/statements if appropriate. I would however ask that details of the vulnerability not be publicly released until the iDEFENSE advisory has gone out. Regards, Michael Sutton Director, iDEFENSE Labs Content-Description: pub_Multiple Unix Linux Vendor Xpdf makeFileKey2 Stack Overflow.TXT 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.
Created attachment 27646 [details] patch proposed by redhat
Karl: libextractor also contains xpdf code. Your chance to drop it now before it's shipped on any distribution :-)
Fixed xpdf is submitted. Can you please submit patchinfos?
xpdf done. next one in list: gpdf -> gnome-maintainers
there is still a gpdf submit in /work/src/done/9.1 and /work/src/done/9.2 not yet checked in! ------------------------------------------------------------------- Mon Jan 10 13:21:52 CET 2005 - meissner@suse.de - Applied xpdf security patch. CAN-2004-1125/#49463 Shall I add the patches from this bug and resubmit gpdf?
yes of course
ok, I submitted the packages to gpdf-new because I had no write access to the gpdf directory. patchinfo submitted /work/src/done/PATCHINFO/gpdf.patchinfo.box
* This comment was added by mail. *grmbl* Date: Tue, 18 Jan 2005 15:15:41 +0100 From: Martin Pitt <martin.pitt@canonical.com> To: vendor-sec@lst.de Subject: Re: [vendor-sec] Re: iDEFENSE Security Advisory [IDEF0764] Multiple Unix/Linux Vendor Xpdf makeFileKey2 Stack Overflow Hi! Martin Schulze [2005-01-14 10:28 +0100]: | --- Decrypt.cc~ 2002-02-02 00:15:45.000000000 +0100 | +++ Decrypt.cc 2005-01-14 10:25:21.000000000 +0100 | @@ -158,7 +158,7 @@ GBool Decrypt::makeFileKey2(int encVersi | } else if (encRevision == 3) { | memcpy(test, userKey->getCString(), 32); | for (i = 19; i >= 0; --i) { | - for (j = 0; j < keyLength; ++j) { | + for (j = 0; j < keyLength && j < 16; ++j) { | tmpKey[j] = fileKey[j] ^ i; | } | rc4InitKey(tmpKey, keyLength, fState); Mark J Cox [2005-01-14 12:54 +0000]: | --- Decrypt.cc.jn 2002-12-06 00:44:32.000000000 +0100 | +++ Decrypt.cc 2005-01-14 13:38:48.192647128 +0100 | @@ -132,13 +132,19 @@ GBool Decrypt::makeFileKey2(int encVersi | Guchar *buf; | Guchar test[32]; | Guchar fState[256]; | - Guchar tmpKey[16]; | + Guchar *tmpKey; | Guchar fx, fy; | int len, i, j; | GBool ok; | | + // check whether we have non-zero keyLength | + if ( !keyLength ) { | + return gFalse; | + } | + | // generate file key | buf = (Guchar *)gmalloc(68 + fileID->getLength()); | + tmpKey = (Guchar *)gmalloc(keyLength * sizeof(Guchar)); | if (userPassword) { | len = userPassword->getLength(); | if (len < 32) { | @@ -191,6 +197,7 @@ GBool Decrypt::makeFileKey2(int encVersi | ok = gFalse; | } | | + gfree(tmpKey); | gfree(buf); | return ok; | } I think both patches catch the vulnerability too late. Decrypt::makeFileKey2() is only called by Decrypt::makeFileKey(). The latter function is called from "outside", i. e. from XRef.cc. However, makeFileKey() already contains the same vulnerability: Guchar tmpKey[16]; [...] for (j = 0; j < keyLength; ++j) { tmpKey[j] = test[j] ^ i; _after_ this code, makeFileKey2() is called with the same keyLength. So as far as I can see, keyLength should just be clipped to 16 in makeFileKey(), or the function should just fail if keyLenght > 16. Well, let's see what upstream's patch does. :-) This is just meant to be a warning to not release updates prematurely. Martin
Created attachment 27745 [details] upstream patch When you apply this patch please make sure it's in the correct function.
is public.
xpdf packages with upstream patch are submitted.
gpdf packages with upstream patch are submitted
pdf{2,to}html packages with upstream patch are submitted.
kdegrpahics3 and patchinfos are submitted
CUPS status: new packages for all maintained SuLi versions (= 8.1 - 9.2) submitted.
The upstream patch doesn't seem to handle keyLength == 0. Although not exploitable, it could cause a crash I think in rc4InitKey where it does: index1 = (index1 + 1) % keyLen; So it might not be a bad idea to add + // check whether we have non-zero keyLength + if ( !keyLength ) { + return gFalse; + } to makeFileKey and makeFileKey2
I submitted CUPS packages with upstream patch.
xpdf, pdftohtml, pdf2html, gpdf patches approved. rest is pending qa. (tetex update still missing)
Yep ... I've read a lot of mails which have reached last four weeks.
Which of the patches is valid now?
/work/SRC/all/xpdf/xpdf-3.00pl3.patch is the one used by upstream. Bonus points for fixing the division by zero but that's not required.
submited tetex for SLES9 and SL8.1, SL8.2, SL9.0, SL9.1, and SL9.2
cups and tetex packages approved
CVE-2005-0064: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)