Re: [xmpp] IQ Handling vulnerabilities

Kevin Smith <> Sun, 09 February 2014 16:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A02161A0322 for <>; Sun, 9 Feb 2014 08:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.422
X-Spam-Level: *
X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UDhOIgNKVCCR for <>; Sun, 9 Feb 2014 08:56:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::235]) by (Postfix) with ESMTP id EDE361A01DA for <>; Sun, 9 Feb 2014 08:56:25 -0800 (PST)
Received: by with SMTP id cz12so4315239veb.12 for <>; Sun, 09 Feb 2014 08:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=PBXGFcIYnOOY51ycS9zi9LZ8HMas9af/fpBSDRmwdxc=; b=Q7C9Gi+g0FjDwKh8XQIHd77WWpi3PSxkuPxCMGERi8CepggUafZIOUOhJVYPoiBapk lIvf4DOt1VG1WmhM8yzKL4Ga7aXOOpxRGF2zDkwbkiXw1exN82b8vWbVzEQf+QRYMQg4 oONEbcC/ULr6UB7LlR+oSWU/3J/edMKgD0WjYTA+dM+rNPHRmtQ3ciCn/MGZy7hofnAv 0nvYXpJ+8D8gBBqjbTN9RfeIMJK0BM+RI1wPL3PmVNiQsaWflgqxQsbYvuCGuHEXwu+k t8WN2xmVIS0/biGdMU0ddWHExPuqRQ3ATZhkaABftL8fxYFxlQnulcps1vGQxoET3wS9 XATA==
MIME-Version: 1.0
X-Received: by with SMTP id as4mr16817096vdc.0.1391964985831; Sun, 09 Feb 2014 08:56:25 -0800 (PST)
Received: by with HTTP; Sun, 9 Feb 2014 08:56:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Sun, 9 Feb 2014 16:56:25 +0000
X-Google-Sender-Auth: N4Yp5-A-_nkQsJk_KEDy12_EcMM
Message-ID: <>
From: Kevin Smith <>
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 16:56:27 -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...)
>> 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?

There's a fun one where the server sends a ping to the client to check
for inactivity. If another client can keep a dead session alive,
that's quite interesting.