Bugzilla Bug 51368

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