iq 'from' attributes are not checked everywhere #278

Closed
xnyhps opened this Issue Feb 3, 2014 · 4 comments

Comments

Projects
None yet
3 participants

xnyhps commented Feb 3, 2014

I've been looking into XMPP implementations and whether they verify the source of iq replies. See http://mail.jabber.org/pipermail/jdev/2014-January/089824.html and http://mail.jabber.org/pipermail/jdev/2014-January/089838.html for more discussion.

The iq.send function at https://github.com/fritzy/SleekXMPP/blob/develop/sleekxmpp/stanza/iq.py?source=c#L161 registers a handler to be called when a reply with the specified id comes in. However, it does not verify whether the from on the reply matches the to on the original iq. This makes it possible for attackers to spoof replies, for example spoofing vcards or intercepting file transfers.

I have verified that using the XEP 0092 (Software Version) plugin does indeed have this problem. self['xep_0092'].get_version(jid) will accept a reply that does not originate from the specified JID. Roster spoofing seems to be impossible, but there are many other iqs I didn't try.

@legastero legastero added a commit that referenced this issue Feb 4, 2014

@legastero legastero Fix verifying 'from' for IQ results.
Closes issue #278
bd03f07
Collaborator

legastero commented Feb 4, 2014

Thanks for the effort you've put into checking implementations, @xnyhps!

IQ senders are verified now, but I'm going to leave this open until I also get MAM sender verification checked.

Could this problem, related to resource binding to Facebook XMPP, be caused by this change?

xnyhps commented Feb 13, 2014

From the log, it looks like Facebook's behavior is correct, though it is tricky to implement:

<iq type="result" from="-100002126842229@chat.facebook.com" id="6e6fe59f-1683-41a9-9a32-dc8a952cdecd-2">
    <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
        <jid>-100002126842229@chat.facebook.com/xymAXUKM</jid>
    </bind>
</iq>

This reply informs SleekXMPP what its JID is, but because it changes the nodepart, it doesn't know yet that that reply is authorized. The reply is only authorized if it is handled first (which it isn't, because it appears unauthorized).

A workaround I heard from Swift (IIRC) is to consider any reply valid before a resource is bound, because malicious other's can't send you incorrect replies before you have bound a resource anyway.

Collaborator

legastero commented Feb 14, 2014

The Facebook issue should now be resolved in Sleek 1.2.4

legastero closed this Jun 8, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment