Re: [xmpp] IQ Handling vulnerabilities

Thijs Alkemade <> Sun, 09 February 2014 14:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 17E901A02A8 for <>; Sun, 9 Feb 2014 06:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.446
X-Spam-Level: *
X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zjNBFkRGDnjT for <>; Sun, 9 Feb 2014 06:13:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B37C61A00F5 for <>; Sun, 9 Feb 2014 06:13:44 -0800 (PST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 73DB8201B7; Sun, 9 Feb 2014 15:13:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1391955218; bh=dn5g7xAupLHQTsmM2tu3cPOKisfQ63bUmPWCAht5T2k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hGkrbmwGBOdIETUuKOrakxm+NlQ8hmMZqliRP5nAYQB1HZo7w9EKu5odO+0PWuWUx ax3xGX6GS6jPG32tvysdLttapoQr95/t4gIIwSDSeJt0f97kAhTrq6hRkDT6YYSQwL xBQnPsYm8wiWIzfv3WiUNduFSU/9RulSfR3uqebs=
Content-Type: multipart/signed; boundary="Apple-Mail=_DF8E7BC4-A1AE-4221-94C1-2C874FB4471D"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thijs Alkemade <>
In-Reply-To: <>
Date: Sun, 9 Feb 2014 15:13:34 +0100
Message-Id: <>
References: <> <> <> <> <> <>
To: Dave Cridland <>
X-Mailer: Apple Mail (2.1827)
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 14:13:47 -0000

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

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