Bugzilla – Bug 55791
VUL-0: CVE-2004-0488: buffer overflow in mod_ssl
Last modified: 2021-10-12 13:31:09 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().
<!-- SBZ_reproduce --> ...
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.
Created attachment 19856 [details] same patch for apache2
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
I'm adding the patch now, now is a better time than later...
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?
Two bugzilla IDs? It's only this bug (40791), or is there another one? There is no Laufzettel yet.
40611 I thought. Plus this one (40791).
Those are the two that are listed in the Changelog.
Great. Have there been patchinfos already? I just sent around the laufzettel.
I'll add new patchinfos shortly (and attach them to bug 55611)
Patchinfos for apache1 submitted. Now, I will apply the same fix to apache2.
fixed apache2 packages submitted
Created attachment 19913 [details] patchinfo file for apache2 (it's only on box products so far) Has been submitted to /work/src/done/PATCHINFO.
Fixed apache2 package submitted to STABLE. (apache1 does no longer exist in STABLE.) re-assigning to security-team for further processing.
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.
Annoucned in SuSE-SA:2004:0014 Now, packages need to be approved.
I'll take care of the approval...
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).
Approved packages. Have beenb annoucned in last advisory section 2
*** Bug 208254 has been marked as a duplicate of this bug. ***
CVE-2004-0488: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)