Re: [xmpp] IQ Handling vulnerabilities

Waqas Hussain <> Sun, 09 February 2014 15:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C1E801A0325 for <>; Sun, 9 Feb 2014 07:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YhrdU9x-74bi for <>; Sun, 9 Feb 2014 07:01:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c02::231]) by (Postfix) with ESMTP id 50B341A0320 for <>; Sun, 9 Feb 2014 07:01:32 -0800 (PST)
Received: by with SMTP id x14so3971908vbb.22 for <>; Sun, 09 Feb 2014 07:01:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=m62Mu8BObcQdaizNNdnolPJ9SniVfpz2HMMgNvQ28oE=; b=PyAvq6TAxCDdM7zTZzoC5Ag4M9ynBOp29MC49N1InJhOlvIEJDd6AYh22lyzvnHWlL ksR5D7KT6pzinXvPBKEG7uL1ZmF8tWoJ6QHwB6I2Ro71WAfHD2fm+6oWOMacBZeTtQaF MIfH+lqJOWqU+FOD7UbKLtSNl+Nzar7gx0jn2Oaz6wXUuewrfuevJh8RRfdyYwIfZFGm 8Kq1swiev33ik923z5s1W8ukrTdMO+UF50RGFQcwN5knypn8Xs7WJWClm4lJ5EFkLo9J efUnTowOU8+XDbzFQouIE57C33snIuMJcPQfqBGyd+1/RMLeFO4dW9DvgPwHkTf57KlI EroA==
X-Received: by with SMTP id dn9mr16382833vdb.3.1391958092271; Sun, 09 Feb 2014 07:01:32 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 9 Feb 2014 07:01:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Waqas Hussain <>
Date: Sun, 9 Feb 2014 10:01:12 -0500
Message-ID: <>
To: Thijs Alkemade <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 15:01:33 -0000

On Sun, Feb 9, 2014 at 9:13 AM, Thijs Alkemade <> wrote:
>> 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?

disco#info requests for PEP, though in this case Prosody happily uses
a single constant id for all requests, only using the sender's JID and
subscription status.
MUC is another when it proxies IQ requests (vCards, private IQs), and
for vCards Prosody encodes a bunch of information in the id for

A quick search through prosody-modules found implementations of
XEP-0309: Service Directories and XEP-268: Incidents Handling
listening for IQ results.

Waqas Hussain