Re: [xmpp] IQ Handling vulnerabilities

Dave Cridland <> Sun, 09 February 2014 19:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 314751A0545 for <>; Sun, 9 Feb 2014 11:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.521
X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6auJZ2SGaur4 for <>; Sun, 9 Feb 2014 11:30:57 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c02::22d]) by (Postfix) with ESMTP id 721511A0443 for <>; Sun, 9 Feb 2014 11:30:57 -0800 (PST)
Received: by with SMTP id i11so6555780oag.4 for <>; Sun, 09 Feb 2014 11:30:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eYr2aQjz2lapQlqx3sdRUlUu5R5MTmCMqpjSB3YsTFQ=; b=VYyypO6JM33DMwBQHuQNcvhAkKaMkj1c4gHPLEk+MUqd0AhslpESeAFhfGAGktdkzj QZ121ra1PbCZjuDwQE7YH3LhOwqMyklDcDcaFeHYvTSPW7OLV/O76yrVs4GGoMWPRpw0 8NI3anbOnxP4eWR6DnLYVM1eRdOoWplwY8kIs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eYr2aQjz2lapQlqx3sdRUlUu5R5MTmCMqpjSB3YsTFQ=; b=HviK5yv2SBOaIvUVugKR1C3haaWH6xOPnv8Ki7Rve6Ja9Fs67QkQk5z3Mi4yn+D8Rh 7NxE4uEmo+NxEVgD13rEpeM+8mprPAkV6EPlZ5nG3QKBQnOY7amtBgnKxqM84LONx9SM 0DmlDP71UmHDwuNCaQFYx5igGCaSxh9ZyMH08REfzhWwNmGt+vkfzc04+Qxqck6PZcoP VVJHVo27w+taIrFgDg5diucZXuLN0W32Is0hthBffyZVjQzo6iH2h6EGtnJAamYvNnUg j3xYIFIaTMQWpOpMWtsgjsFope3cYeuiLALqz+CpvrK4hLatp4l//me7aBlzkkl6kOtv eozg==
X-Gm-Message-State: ALoCoQl6kPnkHeQ3QNpXg2d/llMgckqkSIUS6zZht0T78undDkWZeSJlbxFrhT5dFMezysTfM5nc
MIME-Version: 1.0
X-Received: by with SMTP id sm4mr23538667oec.9.1391974257270; Sun, 09 Feb 2014 11:30:57 -0800 (PST)
Received: by with HTTP; Sun, 9 Feb 2014 11:30:57 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Sun, 9 Feb 2014 19:30:57 +0000
Message-ID: <>
From: Dave Cridland <>
To: Thijs Alkemade <>
Content-Type: multipart/alternative; boundary=001a1136286025ef8704f1fe43a1
Cc: Ben Campbell <>, XMPP Working Group <>
Subject: Re: [xmpp] IQ Handling vulnerabilities
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 09 Feb 2014 19:30:59 -0000

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

> On 7 feb. 2014, at 16:50, Dave Cridland <> 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

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.