[jdev] Spoofing of iq ids and misbehaving servers

[Thijs Alkemade]

Hello!

Some time ago I wrote a patch for Pidgin for CVE-2013-6483
(https://pidgin.im/news/security/?id=78):

   The XMPP protocol plugin failed to ensure that iq replies came from the
   person they were sent to. A remote user could send a spoofed iq reply and
   attempt to guess the iq id. This could allow an attacker to inject fake
   data or trigger a null pointer dereference.

As probably many other XMPP clients, Pidgin can register callbacks to be
called when iq replies come in. These didn't keep track of the intended
recipient, only of the iq's id. I patched that to also keep track of the JID
with some special casing for iqs sent without a 'to' (no 'to' is equivalent of
addressing your own account). I tested that against my own server, which
worked and then I didn't spend much more time on it, as I assumed other
clients would get this right.

But now that Pidgin 2.10.8 is released, we're running into a pile of trouble:

The worst offenders are iChat server (I have no version number) and ejabberd
(2.1.10, I think). These reply to iqs with no 'to' with a 'from' of the full
JID of the client's resource:

C: <iq type='get' id='purple24c740bb'><vCard xmlns='vcard-temp'/></iq>
S: <iq type='result' id='purple24c740bb' from='user at chat.company.com/Office'>...</iq>

Then we have Facebook. All replies to iqs without 'to' have
from='chat.facebook.com':

C: <iq type='get' id='purple3a6232a6'><ping xmlns='urn:xmpp:ping'/></iq>
S: <iq from='chat.facebook.com' id='purple3a6232a6' type='result'/>

jabber.org itself shows a similar problem:

C: <iq type='set' id='purplec5ae5254'>
      <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
   </iq>
S: <iq from='jabber.org' type='result' id='purplec5ae5254'/>

I don't know if this covers anything other than <session>. We can argue that
<session> is deprecated, and according to RFC 3921 it should be addressed to
the server itself, not to the account. But I think it's important to keep the
addressing rules of iqs used consistently and not make exceptions based on the
payload of the iqs.


But what baffles me even more is that it almost appears like nobody else ever
ran into this problem. Is it really the case that every XMPP client out there
does not check for the correct 'from' on result iqs either? Or have they all
implemented workarounds to deal with the incorrect behavior of the servers
listed above?

For clients using long and randomly generated ids for every iq, I could accept
not verifying the sender, though it is risky. But many use a simple
incrementing counter. Other contacts can observe your current counter and spam
you with other ids near it. Possible attacks include spoofing vcards, rosters,
disco information, intercepting file transfers, etc.


I regret that this issue is now already public, so please take some time to
check your code whether your clients are vulnerable to this problem too.

Regards,
Thijs Alkemade

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://www.jabber.org/jdev/attachments/20140130/d9f95ca8/attachment.pgp>