Georgi Guninski reported a possible problem with mod_ssl on full-disclosure: 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 Reproducible: Didn't try Steps to Reproduce: I guess this is not a critical bug. I entered it so that people are aware there _might_ be a problem. I'm watching fd and bugtraq for follow up emails and POC. As soon as there's more information we can re-rate the bug. regards, Tobias
After some research : http://marc.theaimsgroup.com/?l=apache-modssl&m=108549001500319&w=2 This appears to be CAN-2004-0488. Note : "It can only be triggered if mod_ssl is configured to use FakeBasicAuth and will trust a CA which issues a client cert with a >6K long subject DN." Fix for apache 2.0.x is : http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_kernel.c?r1=1.105&r2=1.106 Fix for mod_ssl 2.8 (apache 1.3.x) is not available yet. zul : we can patch or wait. Your call...
I would wait for the apache 1.3.x version so we can do them both at the same time.
OK, so we are waiting for upstream fix in mod_ssl.
mod_ssl 2.8.18 is out : http://marc.theaimsgroup.com/?l=apache-modssl&m=108566416009373&w=2 Waiting for an apache-2.0.49-r3 and mod_ssl-2.8.18 ?
Ive added the patch to 2.0.49 and above. Ill will be commiting a 2.0.49-r3 tongiht.
1.3.31-r1 and mod_ssl 2.8.18 is in as well.
Arches, please mark stable : apache-1.3.31-r1 = "x86 ppc sparc mips alpha hppa amd64 ia64" apache-2.0.49-r3 = "x86 ppc sparc mips alpha hppa amd64 ia64 s390" mod_ssl-2.8.18 = "x86 ppc sparc mips alpha hppa" Thanks !
Stable on alpha.
Stable on mips & sparc
Marked stable on amd64.
*** Bug 52802 has been marked as a duplicate of this bug. ***
GLSA is ready ppc, hppa : please mark apache-1.3.31-r1 apache-2.0.49-r3 and mod_ssl-2.8.18 stable ia64 : please mark apache-1.3.31-r1 and apache-2.0.49-r3 stable
stable on ia64
Good to go on ppc.
Ready to send
All done for hppa. Sorry for the delay but I had exams :-/
GLSA 200406-05