Full Disclosure mailing list archives
mod_ssl ssl_util_uuencode_binary potential problem
From: Georgi Guninski <guninski () guninski com>
Date: Mon, 17 May 2004 16:32:35 +0300
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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- mod_ssl ssl_util_uuencode_binary potential problem Georgi Guninski (May 17)
- Re: mod_ssl ssl_util_uuencode_binary potential problem Byron L. Sonne (May 17)