mod_ssl ssl_util_uuencode_binary potential problem

mod_ssl ssl_util_uuencode_binary potential problem

am 17.05.2004 15:32:35 von Georgi Guninski

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