Bug 64840 (CVE-2005-0064)

Summary: VUL-0: CVE-2005-0064: xpdf buffer overflow in Decrypt::makeFileKey2
Product: [Novell Products] SUSE Security Incidents Reporter: Ludwig Nussel <lnussel>
Component: IncidentsAssignee: E-mail List <gnome-bugs>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Major    
Priority: P3 - Medium CC: gnome-bugs, kde-maintainers, ke, nadvornik, security-team, werner
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: CVE-2005-0064: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on:    
Bug Blocks: 62730    
Attachments: patch proposed by redhat
upstream patch

Description Ludwig Nussel 2005-01-14 17:59:05 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.
Comment 1 Ludwig Nussel 2005-01-14 20:58:16 UTC
Created attachment 27646 [details]
patch proposed by redhat
Comment 2 Ludwig Nussel 2005-01-14 22:59:20 UTC
Karl: libextractor also contains xpdf code. Your chance to drop it now before 
it's shipped on any distribution :-) 
Comment 3 Vladimir Nadvornik 2005-01-18 00:01:54 UTC
Fixed xpdf is submitted. Can you please submit patchinfos? 
Comment 4 Ludwig Nussel 2005-01-18 19:28:49 UTC
xpdf done. next one in list: gpdf -> gnome-maintainers 
Comment 5 Holger Hetterich 2005-01-18 20:48:49 UTC
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?
Comment 6 Ludwig Nussel 2005-01-18 20:49:45 UTC
yes of course 
Comment 7 Holger Hetterich 2005-01-18 21:24:23 UTC
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
Comment 8 Ludwig Nussel 2005-01-18 22:25:17 UTC
* 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
Comment 9 Ludwig Nussel 2005-01-19 17:08:35 UTC
Created attachment 27745 [details]
upstream patch

When you apply this patch please make sure it's in the correct function.
Comment 10 Marcus Meissner 2005-01-19 17:43:30 UTC
is public. 
Comment 11 Vladimir Nadvornik 2005-01-19 17:53:56 UTC
xpdf packages with upstream patch are submitted. 
Comment 12 Holger Hetterich 2005-01-19 18:30:26 UTC
gpdf packages with upstream patch are submitted
Comment 13 Karl Eichwalder 2005-01-19 18:33:27 UTC
pdf{2,to}html packages with upstream patch are submitted.
Comment 14 Adrian Schröter 2005-01-20 19:00:38 UTC
kdegrpahics3 and patchinfos are submitted  
Comment 15 Klaus Singvogel 2005-01-20 22:51:35 UTC
CUPS status: new packages for all maintained SuLi versions (= 8.1 - 9.2) 
submitted. 
Comment 16 Waldo Bastian 2005-01-21 01:07:09 UTC
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 
  
  
Comment 17 Klaus Singvogel 2005-01-21 21:33:49 UTC
I submitted CUPS packages with upstream patch. 
Comment 18 Marcus Meissner 2005-01-25 19:01:01 UTC
xpdf, pdftohtml, pdf2html, gpdf patches approved. 
 
rest is pending qa. (tetex update still missing) 
Comment 19 Dr. Werner Fink 2005-01-25 19:08:48 UTC
Yep ... I've read a lot of mails which have reached last four weeks.
Comment 20 Dr. Werner Fink 2005-01-25 22:03:59 UTC
Which of the patches is valid now?
Comment 21 Ludwig Nussel 2005-01-25 22:21:33 UTC
/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. 
Comment 22 Dr. Werner Fink 2005-01-26 02:25:17 UTC
submited tetex for SLES9 and SL8.1, SL8.2, SL9.0, SL9.1, and SL9.2
Comment 23 Thomas Biege 2005-02-01 19:52:15 UTC
cups and tetex packages approved
Comment 24 Thomas Biege 2009-10-13 20:57:46 UTC
CVE-2005-0064: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)