iq 'from' attributes are not checked

[xnyhps]

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.

https://github.com/robbiehanson/XMPPFramework/blob/783f62533885e027e8189f8dc133c72a17e9dea0/Utilities/XMPPIDTracker.m appears to contain no code that checks whether the received iq's from attribute matches the expected to attribute. This can lead to spoofing of iq replies (spoofing rosters, vcards, intercepting file transfers, etc.). The use of UUIDs makes this a lot harder, but not impossible.

More importantly,

XMPPFramework/Extensions/Roster/XMPPRoster.m

Line 686 in bcaae05

- (BOOL)xmppStream:(XMPPStream *)sender didReceiveIQ:(XMPPIQ *)iq

does not check for roster pushes whether they come from the server or not. Any incoming iq with an <query xmlns='jabber:iq:roster'> child is handled as if it were a push from the server. I have verified (using Flamingo) that it is possible to send additional, fake roster replies from other accounts and the received roster items get added to the contact list. This is a very serious security issue. These replies should come from your own bare JID, but some other servers out there send it from the bare domain or from your own full JID.

[ObjColumnist]

Hi,

I was at the XSF summit and heard about the issues.

The roster one is easy enough to fix, but servers replying from non conforming jids makes it a problem.

[xnyhps]

For libpurple we decided on the following change:
Replies that are expected to come from your own bare JID (i.e. the "server acting on behalf of your own account" as it is described in the RFC), will be accepted if they have:

• No from.
• from = the bare account JID.
• from = the full account JID (legal in 3920, but not 6120).
• from = the server's domain.

That seems to cover all servers that people reported problems with.