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: