possible XMPP SASL bug?

[Paul Aurich]

On 2010-05-03 12:37, Joe Hildebrand wrote:
> On 5/3/10 8:05 AM, "Evan Schoenberg, M.D." <evan at adium.im> wrote:
> 
>> Ah. Your problem is not with trying multiple SASL mechs but rather that we
>> have to use jabber:iq:auth even if SASL fails entirely.
> 
> Yes.
> 
>> A long and detailed discussion of this is found at
>> http://trac.adium.im/ticket/8108 - please see
>> http://trac.adium.im/ticket/8108#comment:15 and the two following comments, in
>> particular.
> 
> This points out a downgrade attack that Adium is currently subject to.
> Right now, Adium will try to send the server the plaintext password, even if
> the server doesn't want it.  All I have to do as an attacker to get your
> password is contrive a transient login failure through the mechanisms that
> the server supports.

Maybe I'm missing something, but couldn't an attacker just swap out all
the advertised mechanisms for PLAIN and get a plaintext password the
same way?

libpurple does not immediately send the password when it falls back to
jabber:iq:auth; it queries for what the server supports and requires a
fairly valid IQ result stanza.  libpurple also will not send plaintext
passwords over an unencrypted stream without an explicit OK from the
user (not that I expect this step to make /much/ of a difference -- I
wonder how many people removing that ability at all would impact).

> I agree that this situation is poorly documented in the standards, and even
> more poorly implemented in the servers (seeing as how few of them send the
> iq:auth stream feature as XEP-78 requires).

FWIW, even though libpurple was/is in violation of XEP-78, the server's
response could be better, too:

"If the server does not support non-SASL authentication (e.g., because
it supports only SASL authentication as defined in RFC 3920), it MUST
return a <service-unavailable/> error. If the client previously
attempted SASL authentication but that attempt failed, the server MUST
return a <policy-violation/> stream error (see RFC 3920 regarding stream
error syntax)."

~Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20100503/b9cdfa7f/attachment.sig>