Segfaults with SASL

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> With the new behaviour of sasl_decode64(), the result is far better.
> No segfault at all now :)
> But I still reckon there is a problem in SASL libraries which do not
> deal well with the input of sasl_* functions...

This rings a vague bell.  There was some sort of change in the decoding of
the Cyrus SASL libraries recently, I think.  Maybe:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400955

is related?

| The new Cyrus SASL has a partially rewritten sasl_decode64 function,
| which is stricter and more complete than the old one. However, it seems
| that applications (at least imtest) assume they can pass in a
| CRLF-terminated string. The code anticipates this in a comment, but
| doesn't actually implement CRLF-ignoring at the end of the string.

Also, more generally, it sounds like they rewrote the base64 functions,
possibly after etch, which may have fixed some bugs.

> The only weird thing I have now, and I do not understand what is going
> on, is the following sequence:
>
> AUTHINFO SASL DIGEST-MD5
> 383 bm9uY2[...]U9IkxJT=
> *
> 481 Client cancelled authentication
> MODE
> 501 Syntax is:  MODE READER
> AUTHINFO SASL DIGEST-MD5
> 481 authentication failure
> AUTHINFO SASL DIGEST-MD5
> 383 bm9uY2[...]U9IkxJT=
>
> I cannot send twice in the row AUTHINFO SASL...  The MODE command is
> there only to show that we are not inside the SASL function.

Very odd.  What error message is returned by the library in the failure
case and is there any more error text anywhere?

> The last thing I see is that the SASL server needs to be renewed.  That
> is to say if the authentication fails, we have to dispose of the
> connection and start a fresh new SASL server, waiting for a connection.
> (But I do not see why the second attempt if the connection is not
> disposed, will work in our case.)  Do you think it is the right use of
> SASL?

I'm afraid I really don't know here.  I haven't used the Cyrus SASL
library very much; most of the SASL implementations I've done I've written
myself from scratch (which saves time if you only care about one
mechanism, but otherwise isn't a good idea).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.