Re: IQ Handling vulnerabilities

On Sun, Feb 9, 2014 at 2:13 PM, Thijs Alkemade <[email protected]> wrote:

>
> On 7 feb. 2014, at 16:50, Dave Cridland <[email protected]> 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...)
>
>
Ah! Nice one.

FWIW, it's possible to hide a offline/online event by DOSsing the original
server then spoofing it, which is hard work but practical given DNS spoofed
dialback.

Also, there's a bunch of MUC-replacement attacks, I suspect, that don't
involve having to predict a stanza id.


> > 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?
>
>
As Waqas says, there's a bunch of cases. It gets worse if the server is
running optimization-related intercepts, such as disco caching, I suspect.
I think there are interesting cases around an XMPP-level file-transfer
proxy (for anti-virus, or SI/Jingle translation) for example.

I'd hope Kev's example is way off, though - I suspect that servers ignore
the XEP-0199 reply stanza and just look for activity on the socket.

Dave.

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp