Re: IQ Handling vulnerabilities

On Fri, Feb 7, 2014 at 11:23 AM, Alexander Holler <[email protected]> wrote:
> Am 06.02.2014 12:26, schrieb Kevin Smith:
>>
>> Hi folks,
>>
>>    Discussion in the XSF and at the recent XMPP Summit has shown that
>> there are widespread issues with handling of iq responses in XMPP
>> software. This is probably something we need to consider handling.
>>
>> The basis of this is that many libraries/clients
>> a) Only check the id of an iq error/result, not the sender, to check
>> it matches one they've sent (Very Wrong)
>> b) Use predictably generated ids for stanzas (ill-advised, but not
>> strictly wrong)
>> c) Use known resource strings (bad, but not strictly wrong)
>
>
> Just to make it clear, the real problem here is neither the IDs nor the
> resources, but not checking the sender of the reply.

There are three issues here. They have different severities, as I
noted initially, and not checking the sender of a reply is the one
that is completely and fundamentally broken. That doesn't preclude
that the other two are also issues (which we may or may not decide
need addressing right now - although I'm of the opinion that while
writing a document explaining the issues, explaining all three would
be worthwhile).  The most egregious of the vulnerabilities involve
having all three present.

We've known the from checking to be an issue for at least three years
(that's the first record I could easily find of discussing the
problem), but how widespread that problem is is news. Using
predictable ids and resources is well known.

(There's an additional point to be made about checking the from of
roster pushes, although I believe this to be a less widespread
problem)

> One of the reasons why clients don't check the sender part seems to be that
> it wasn't clear what the sender of a reply is, if the IQ query was without
> an explicit 'to' attribute.

I'd assert that the correct handling is clear, just that it seems to
go unnoticed for some reason - but why we're in the state of needing
to say something about this seems less important than what we now say.

> A simple rule for clients could be to check that the JID of IQ replies where
> the origin should be the connected server is either the JID of the server
> (no node, no resource) or the received bare JID (stripping a possible
> resource) is the bare JID of the client.

The rules here are clear. If a client sends a stanza without a 'to',
the server is to handle it as if it was sent to the bare JID of the
client's session. The server replying with the server JID is a bug.

/K