possible XMPP SASL bug?

[Evan Schoenberg, M.D.]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20100503/a2815f21/attachment-0002.html>