|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2005-0064: xpdf buffer overflow in Decrypt::makeFileKey2 | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | Ludwig Nussel <lnussel> |
| Component: | Incidents | Assignee: | 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
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) |