Re: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )


Subject: Re: saslauthd -a ldap ( possible BO / bug with long userpassword strings ? )
From: Igor Brezac (igor at ipass dot net)
Date: Wed Apr 16 2003 - 09:47:53 EDT


On Wed, 16 Apr 2003, Jose Miguel Varet wrote:

> Hello all,
>
> AFAIK, this problem hasn't been exposed in the list, except for one message
> dated September 2001 which was unanswered, so here it goes.
> I've got a working installation such as :
>
> cyrus-imap-2.1.12
> cyrus-sasl-2.1.12 , using saslauthd for PLAIN auths against the LDAP server
> openLDAP 2.1.12 ( 2.1.16 removed cache functions needed by sasl2.1.12, had

2.1.12 openldap leaks memory.

Upgrade to 2.1.17, it has stub cache functions as well. I also recommend
upgrading sasl to 2.1.13 which removed these functions.

> to go down to 2.1.12 )
> Berkeley DB4.1.25
> sendmail 8.12.9 + lmtp delivering to Cyrus IMAP
>
>
> Everything works and interoperates just fine.
>
> The only issue is a - bug ? - in cyrus-sasl, which can be triggered under
> the following circumstances :
>
> 1) saslauthd -a ldap ( plain auth against our LDAP server )
> 2) "Userpassword" attribute in LDAP user entry extracted directly from
> /etc/shadow, i.e. , in the LDIF file we'd put :
>
> dn: uid=test,dc=testdomain,dc=com
> modify userpassword
> userpassword: {crypt}$1$cnd5NASV$hOHd2091l3Ui.pxHUA0dm0

This is not crypt hash (unix crypt hash has 13 characters).

What does your saslauthd.conf look like?

> and then ldapmodify -x -D "cn=manger..." -W -f test.LDIF
>
>
> Now, any attemp to authenticate as user "test" throught saslauthd will FAIL
> with what appears ( to me, at least ) to be a possible buffer overflow. For
> example, with the SAMPLE sasl client/server programs :
>
> ./server
> ./client -m PLAIN localhost
>
> ( the client ask for our user/pass )
>
> and then, "Authentication failure". But it's not that the user/pass is
> incorrect. If you look at the logs :
>
> Apr 16 11:23:21 murmansk lt-server: size read failed
> Apr 16 11:23:21 murmansk lt-server: Password verification failed
>
> At first, I could that perhaps this could be an issue with the client/server
> sample programs. But then, I configured cyrus IMAP in order to authenticate
> via saslauthd, and tried a "imtest -m login -a test localhost". Again,
> authentication failure. The logs cofirmed taht the problem lied within
> saslauth itself :
>
> Apr 16 11:27:35 murmansk imapd[21585]: size read failed
>
> Different aplications, same error message, same authentication procedure....
> looks like saslauthd's fault for me.
>
> Just out of curiosity, I tried to "ldappasswd" the user "test" . ldappasswd
> uses the directive "password-hash {CLEARTEXT}" from slapd.conf , so the
> resulting string in "userpassword" field is stored in cleartext, thus being
> *much* shorter than a {crypt} one.
>
> ldappasswd -x -D "cn=manager..." -W -S "uid=test,dc=testdomain,dc=com"
>
> now, testsaslauthd worked flawlessly ! Same for cyrus-imapd auth.
>
> here's an "userpassword" ldap entry with {crypt} :
>
> userPassword:: e2NyeXB0fSQxJGNuZDVOQVNWJGhPSGQyMDkxbDNVaS5weEhVQTBkbTA=
>
> here's the ldappassword normal one ( note : both are base64 encoded,
> anyways )
>
> userPassword:: a7VfaEto
>
> for some reason, a ldap-enabled saslauthd is failing to allocate enough
> memory to read a userpassword string long enough, as is the case for a
> base64-encoded {crypt} shadow password . Other than that, it will work
> flawlessly with shorter password strings.
>
> Note : I've been able to check that this is not openLDAP's fault, since if
> we do :
>
> ./saslauthd -a pam
>
> and create a /etc/pam.d/sample with :
>
> #%PAM-1.0
> auth required /lib/security/pam_ldap.so
> account required /lib/security/pam_ldap.so
> session required /lib/security/pam_ldap.so
>
> and then :
>
> sample/server -s sample
> sampe/client -m PLAIN localhost
>
> (prompt for user/pass )
> Auth OK for user test
>
> So, the direct path saslauthd --> LDAP doesn't work with long enought
> password strings.
> If we take a small walkaround, and do saslauthd --> PAM ---> LDAP, it DOES
> work, regardless of password string lenght.
>
> It's my guess, that nss_ldap ( responsible por pam ldap modules ) has a
> better boundary check than ldap's portion of saslauthd. But again, I'm
> anything but an expert developer, so all of this could be BS, and I could be
> absolutely wrong. If some sasl developer could confirm/provide a fix for
> this issue, I'd be very thankful, since this is the only thing that is
> preventing me about switching all this to our production servers.
>
> Greets,
>
> Jose,
>
>
>
>

-- 
Igor







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD