possible XMPP SASL bug?

[Joe Hildebrand]

This *almost* works.  The error is now correct, but we shouldn't
auto-reconnect if the password was bad.


On 5/3/10 2:30 PM, "Evan Schoenberg, M.D." <evan at adium.im> wrote:

> 
> On May 3, 2010, at 11:42 AM, David Smith wrote:
> 
>> I'd be happy to check if I can still connect to iChat Server if someone gives
>> me a patched Adium.
> 
> 
> I should have checked the code instead of the ticket; I left later-me some
> good details there.
> jabber_auth_start_cyrus() for us includes:
> {
> /* We have no mechs which can work.
> * Try falling back on the old jabber:iq:auth method. We get here if the server
> supports
> * one or more sasl mechs, we are compiled with cyrus-sasl support, but we
> support or can connect with none of
> * the offerred mechs. jabberd 2.0 w/ SASL and Apple's iChat Server 10.5 both
> handle and expect
> * jabber:iq:auth in this situation.  iChat Server in particular offers SASL
> GSSAPI by default, which is often
> * not configured on the client side, and expects a fallback to jabber:iq:auth
> when it (predictably) fails.
> *
> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure is
> wrong. However,
> * I believe this refers to actual authentication failure, not a simple lack of
> concordant mechanisms.
> * Doing otherwise means that simply compiling with SASL support renders the
> client unable to connect to servers
> * which would connect without issue otherwise. -evands
> */
> js->auth_mech = NULL;
> jabber_auth_start_old(js);
> return JABBER_SASL_STATE_CONTINUE;
> }
> 
> 
> However, elsewhere in auth_cyrus, jabber_cyrus_handle_failure() has what
> appears to be better logic:
> 
> if (tried_gssapi_first) {
> /* If we tried GSSAPI first, it failed, and it was our only shot, try
> jabber:iq:auth
> * for compatibility with iChat 10.5 Server.
> *
> * iChat Server 10.5  offers SASL GSSAPI by default, which is often
> * not configured on the client side, and expects a fallback to jabber:iq:auth
> when it (predictably) fails.
> *
> * Note: xep-0078 points out that using jabber:iq:auth after a sasl failure is
> wrong. However,
> * I believe this refers to actual authentication failure, not a simple lack of
> concordant mechanisms.
> * Doing otherwise means that simply compiling with SASL support renders the
> client unable to connect to servers
> * which would connect without issue otherwise. -evands
> */
> sasl_dispose(&js->sasl);
> js->sasl = NULL;
> js->auth_mech = NULL;
> jabber_auth_start_old(js);
> return JABBER_SASL_STATE_CONTINUE;
> }
> 
> (comments expanded just-now by me).
> In im.pigin.adium.1-4's 2fcd834324b05d3becf6878db8ce1c474578e720 I have
> removed the former, aggressive behavior and left the latter.  I think this
> should solve the problem presented while maintaining the workaround for iChat
> Server 10.5's apparent wrongness.
> 
> 
> This is committed in adium-1.4's [6534647aece5289a0e5ac90c012bcbf75e3918f3].
> 
> A build for testing is uploaded at
> http://adiumx.cachefly.net/Adium_1.4b18-noJabberHack.dmg
> 
> The downgrade attack Joe mentions does still exist, but now if and only if
> ((GSSAPI is the only offered SASL mech) && (GSSAPI fails)).  Further
> improvement would be a prompt as described in that setting; patches welcome.
> 
> Look forward to any feedback.
> 
> -Evan

-- 
Joe Hildebrand