Bug 55791 (CVE-2004-0488)

Summary: VUL-0: CVE-2004-0488: buffer overflow in mod_ssl
Product: [Novell Products] SUSE Security Incidents Reporter: Sebastian Krahmer <krahmer>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: david.chenworth, patch-request, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: CVE-2004-0488: 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: ---
Attachments: patch for apache
same patch for apache2
patchinfo file for apache2 (it's only on box products so far)

Description Sebastian Krahmer 2004-05-18 20:23:03 UTC 
Date: Mon, 17 May 2004 16:32:35 +0300
From: Georgi Guninski <guninski@guninski.com>
To: modssl-users@modssl.org
Cc: full-disclosure@lists.netsys.com
Subject: [Full-Disclosure] mod_ssl ssl_util_uuencode_binary potential
    problem

This email is copyrighted confidential information.
It cannot be used in vulnerability databases, especially in CAN,
securityfocus, to name a few.

hi,

there is a potential problem in mod_ssl.

in ssl_util.c there is:
-------------------------------------
void ssl_util_uuencode_binary(
    unsigned char *szTo, const unsigned char *szFrom, int nLength, BOOL bPad)
{
    const unsigned char *s;
    int nPad = 0;

    for (s = szFrom; nLength > 0; s += 3) {
        *szTo++ = ssl_util_uuencode_six2pr[s[0] >> 2];
/*PROPOSED PATCH: add "if (--nLegth ==0 ) ..." */
        *szTo++ = ssl_util_uuencode_six2pr[(s[0] << 4 | s[1] >> 4) & 0x3f];
        if (--nLength == 0) {
            nPad = 2;
            break;
        }
        *szTo++ = ssl_util_uuencode_six2pr[(s[1] << 2 | s[2] >> 6) & 0x3f];
        if (--nLength == 0) {
            nPad = 1;
            break;
        }
        *szTo++ = ssl_util_uuencode_six2pr[s[2] & 0x3f];
        --nLength;
    }
    while(bPad && nPad--)
        *szTo++ = NUL;


    *szTo = NUL;
    return;
}
-------------------------

obviously this allows writing about 4*nLegth/3 chars (not counting padding).

there may be problem if this code is hit in ssl_engine_kernel:

int ssl_hook_Auth(request_rec *r)
{
    SSLSrvConfigRec *sc = mySrvConfig(r->server);
    SSLDirConfigRec *dc = myDirConfig(r);
    char b1[MAX_STRING_LEN], b2[MAX_STRING_LEN];
    char *clientdn;

.....
ap_snprintf(b1, sizeof(b1), "%s:password", clientdn);
ssl_util_uuencode(b2, b1, FALSE);

ap_snprintf(b1, sizeof(b1), "Basic %s", b2);
.....

i doubt this is exploitable on x86, but i am too lame to emulate it if 
stack grows in the other direction.

-- 
georgi
------------- snip -----------

Looks like you can cause a SIGSEGV but thats all. However I think
his patch proposal is wrong. nLength looks like the source-length to me.
(due to the increase of 3 for s and the decrease of 3 for nlength).
A patch would be to have double size strings for the uuencode output.
(e.g. 2*MAX_STRING_LEN for b2).
I dont know whether there are more calls to ssl_util_uuencode().
Comment 1 Sebastian Krahmer 2004-05-18 20:23:03 UTC 
<!-- SBZ_reproduce  -->
...
Comment 2 Juergen Weigert 2004-05-18 23:19:42 UTC 
Created attachment 19854 [details]
patch for apache

Yes, that code does not expect that uuencoding makes strings longer. 
b2 is apr_snprintf'ed back into b1, so it will be silently truncated if we
solve by increasing sizeof(b2) and it got longer than MAX_STRING_LEN. That
should be acceptable here.

In both apache1 apache2, there are no other calls to 
ssl_util_uuencode_binary/ssl_util_uuencode.

Trivial patches using the suggested 2*MAX_STRING_LEN added.
Comment 3 Juergen Weigert 2004-05-18 23:20:11 UTC 
Created attachment 19856 [details]
same patch for apache2
Comment 4 Peter Poeml 2004-05-19 01:45:27 UTC 
Security-team, should we add the patch now and fix it together with the
ongoing apache 1 update? At the moment all packages are still under
/work/src/done
Comment 5 Peter Poeml 2004-05-19 02:55:58 UTC 
I'm adding the patch now, now is a better time than later...
Comment 6 Sebastian Krahmer 2004-05-19 17:19:12 UTC 
Hm, ok. Thanks. But it needs two bugzilla ID's in the changelog then,
as well as apropriate patchinfo description. Was there a laufzettel
for apache already?
Comment 7 Peter Poeml 2004-05-19 17:22:03 UTC 
Two bugzilla IDs? It's only this bug (40791), or is there another one?

There is no Laufzettel yet.
Comment 8 Sebastian Krahmer 2004-05-19 17:26:50 UTC 
40611 I thought. Plus this one (40791).
Comment 9 Peter Poeml 2004-05-19 17:31:35 UTC 
Those are the two that are listed in the Changelog.
Comment 10 Sebastian Krahmer 2004-05-19 17:36:40 UTC 
Great. Have there been patchinfos already? I just sent around the laufzettel.
Comment 11 Peter Poeml 2004-05-19 17:43:58 UTC 
I'll add new patchinfos shortly (and attach them to bug 55611)
Comment 12 Peter Poeml 2004-05-19 17:58:45 UTC 
Patchinfos for apache1 submitted. 

Now, I will apply the same fix to apache2.
Comment 13 Peter Poeml 2004-05-19 19:33:55 UTC 
fixed apache2 packages submitted
Comment 14 Peter Poeml 2004-05-19 19:37:36 UTC 
Created attachment 19913 [details]
patchinfo file for apache2 (it's only on box products so far)

Has been submitted to /work/src/done/PATCHINFO.
Comment 15 Peter Poeml 2004-05-19 19:59:46 UTC 
Fixed apache2 package submitted to STABLE. (apache1 does no longer exist
in STABLE.)

re-assigning to security-team for further processing.
Comment 16 Juergen Weigert 2004-05-25 22:15:14 UTC 
Just for the records: 
 
jorton@redhat.com fixed the same problem with a different approach for apache2: 
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/
ssl_engine_kernel.c?r1=1.105&r2=1.106 
 
He is entirly avoiding ssl_util_uuencode() and strings of fixed length, which 
is very elegant.
Comment 17 Sebastian Krahmer 2004-05-26 19:45:25 UTC 
Annoucned in SuSE-SA:2004:0014
Now, packages need to be approved.
Comment 18 Thomas Biege 2004-05-28 17:19:14 UTC 
I'll take care of the approval...
Comment 19 Peter Poeml 2004-06-02 21:35:22 UTC 
The issue got assigned CAN-2004-0488.

It has meanwhile been fixed upstreams with mod_ssl 2.8.18-1.3.31.

   *) Fix buffer overflow in "SSLOptions +FakeBasicAuth" implementation
      if the Subject-DN in the client certificate exceeds 6KB in length.
      (CVE CAN-2004-0488).

(The fix is they did was to remove the ssl_util_uuencode_binary function
altogether, and use ap_pbase64encode instead of ssl_util_uuencode).
Comment 20 Sebastian Krahmer 2004-06-04 15:46:02 UTC 
Approved packages. Have beenb annoucned in last advisory section 2
Comment 21 Marcus Meissner 2006-09-26 17:12:02 UTC 
*** Bug 208254 has been marked as a duplicate of this bug. ***
Comment 22 Ludwig Nussel 2006-10-04 15:33:20 UTC 
*** Bug 208254 has been marked as a duplicate of this bug. ***
Comment 23 Thomas Biege 2009-10-13 20:22:59 UTC 
CVE-2004-0488: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)