Re: [xmpp] IQ Handling vulnerabilities

[Kevin Smith <[e-mail]>]

On Sun, Feb 9, 2014 at 2:13 PM, Thijs Alkemade <[e-mail]> wrote:
>
> On 7 feb. 2014, at 16:50, Dave Cridland <[e-mail]> wrote:
>
>> What are the attacks possible against an entity using predictable stanza ids, but which otherwise acts properly (ie, checks to/from on responses, etc)?
>>
>> I'm a bit confused - if an entity isn't checking the to/from of the responses, then sure there's a slew of attacks possible. If it *also* has predictable ids, then the attacks are easier - but they're the same attacks. Aren't they?
>
> The least far-fetched scenario I can think of: you're offering a file transfer
> to someone's MUC room nick. The person disconnects, someone else takes their
> nick and intercepts the file transfer by guessing the 'id' that was used. This
> is also a scenario where a per-address counter will not protect you. (Though a
> better fix is probably to cancel all pending queries to participants when you
> see them disappear from the room...)
>
>> I'm not saying that we shouldn't generally recommend unpredictable ids - it seems relatively simple and causes little harm - but cryptographically secure ones seems overkill, and I'm always nervous of imposing unneeded drains on the entropy store of a system.
>>
>> Also, I've mentioned this elsewhere, but I'll mention it here too: much of the XMPP community seems focussed on clients exhibiting this class of bug, and attacks against those clients. I strongly suspect that not all servers are immune to this, and the attacks on servers are likely to be just as fascinating.
>
> I'm trying to think of a situation where the server sends a iq 'get' to the
> client, but I don't really know any. A lot of iq 'set's, where the server
> informs the client of something (and probably doesn't really care whether that
> results in an 'error' or 'result'), but nothing where the server wants to know
> something from the client. Could you give an example?

There's a fun one where the server sends a ping to the client to check
for inactivity. If another client can keep a dead session alive,
that's quite interesting.

/K