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='[email protected]/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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
