Re: IQ Handling vulnerabilities

On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland <[email protected]> wrote:
> On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr)
> <[email protected]> wrote:
>>
>> On 2/7/14 2:46 AM, "Thijs Alkemade" <[email protected]> wrote:
>>
>> >The property we really want from ids is that predicting the next one(s)
>> >given
>> >some historic ones is hard.
>>
>> (as individual)
>>
>> I agree with everything you said to this point.  However, I think we need
>> to strengthen this a little: we want to ensure predicting the next one(s)
>> in *any* way is hard.
>>
>> Luckily using the from address also mitigates this need slightly for some
>> of the use cases.
>
>
> 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?

Yes and no. By far the biggest issue here is the stanza-faking one,
and predictable ids are a part of what's needed to make the simplest
attack, but aren't actually the broken bit.

There are various unlikely (and arguably unimportant, I suppose)
issues around being able to observe where in a stream a client is. As
an incredibly contrived example, client A shows client B an id that
means "You are the first person I'm sending a message to this session"
and user A says to user B "I'm busy chatting to C in another window".

> 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.

Yes, it's clear that the document needs to cover this.

/K