Re: [xmpp] IQ Handling vulnerabilities

Kevin Smith <> Fri, 07 February 2014 15:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E88681ACC7E for <>; Fri, 7 Feb 2014 07:57:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0UveOlrRqbRc for <>; Fri, 7 Feb 2014 07:57:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::22d]) by (Postfix) with ESMTP id 7A76E1AC497 for <>; Fri, 7 Feb 2014 07:57:24 -0800 (PST)
Received: by with SMTP id oz11so2852205veb.4 for <>; Fri, 07 Feb 2014 07:57:24 -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; bh=rjBJvTEPd0Q89Je66dsI22iVvGmRgTecHev3gtZja2k=; b=hbKIQsB7IDJ0XqvkgO/x0L2KYvcrVOCSm7nO9FNjzpfMWMvqP6ZO40UQIbM0UHhdku Ojn4cloaZQAeVXagS3e7Re5NU7SGmnqSFbemVp0qwNOruHDacWPzJTshvYefRM2cgaco Go8JG3pJltA54sbQHSSmXcsjLWwKnC4IQEMXy/u5WinXUEewUs1oXmg9u2oqsJStvNpj PWMoRZXUoAn2N+x2kioUOe7nF5ISOwqyFL5QQ0yeYf/hyEL3NmW2v7h7Py5v6nJaPyoM EMSIzFoLMvUDKYK+3nZfP00PadbGwDKFmAFinftuRYUlmCV6nZI3VcNtpKNOoVMcTVww cvSA==
MIME-Version: 1.0
X-Received: by with SMTP id dz6mr644908vec.35.1391788644243; Fri, 07 Feb 2014 07:57:24 -0800 (PST)
Received: by with HTTP; Fri, 7 Feb 2014 07:57:24 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 7 Feb 2014 15:57:24 +0000
X-Google-Sender-Auth: HR4BxLGv1h8Cy4uo9CfSmJ-unac
Message-ID: <>
From: Kevin Smith <>
To: Dave Cridland <>
Content-Type: text/plain; charset=ISO-8859-1
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: Fri, 07 Feb 2014 15:57:26 -0000

On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland <> wrote:
> On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr)
> <> wrote:
>> On 2/7/14 2:46 AM, "Thijs Alkemade" <> wrote:
>> >The property we really want from ids is that predicting the next one(s)
>> >given
>> >some historic ones is hard.
>> (as individual)
>> I agree with everything you said to this point.  However, I think we need
>> to strengthen this a little: we want to ensure predicting the next one(s)
>> in *any* way is hard.
>> Luckily using the from address also mitigates this need slightly for some
>> of the use cases.
> 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?

Yes and no. By far the biggest issue here is the stanza-faking one,
and predictable ids are a part of what's needed to make the simplest
attack, but aren't actually the broken bit.

There are various unlikely (and arguably unimportant, I suppose)
issues around being able to observe where in a stream a client is. As
an incredibly contrived example, client A shows client B an id that
means "You are the first person I'm sending a message to this session"
and user A says to user B "I'm busy chatting to C in another window".

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

Yes, it's clear that the document needs to cover this.