Re: [xmpp] IQ Handling vulnerabilities

Kevin Smith <kevin@kismith.co.uk> Fri, 07 February 2014 15:57 UTC

Return-Path: <k.i.smith@gmail.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88681ACC7E for <xmpp@ietfa.amsl.com>; Fri, 7 Feb 2014 07:57:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UveOlrRqbRc for <xmpp@ietfa.amsl.com>; Fri, 7 Feb 2014 07:57:24 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7A76E1AC497 for <xmpp@ietf.org>; Fri, 7 Feb 2014 07:57:24 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so2852205veb.4 for <xmpp@ietf.org>; Fri, 07 Feb 2014 07:57:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.58.181.230 with SMTP id dz6mr644908vec.35.1391788644243; Fri, 07 Feb 2014 07:57:24 -0800 (PST)
Sender: k.i.smith@gmail.com
Received: by 10.52.245.134 with HTTP; Fri, 7 Feb 2014 07:57:24 -0800 (PST)
In-Reply-To: <CAKHUCzyCwKbmnUoXLHW=XzYbiFrcg-dQsDojGUnA-_r3qK+_Vg@mail.gmail.com>
References: <CAOb_FnxS-dMT85N7LHj5M9JWk3pL85=ugrDqaT7j5d28HBr0Cw@mail.gmail.com> <CF194491.38AD3%jhildebr@cisco.com> <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <CF1A369C.38BE2%jhildebr@cisco.com> <CAKHUCzyCwKbmnUoXLHW=XzYbiFrcg-dQsDojGUnA-_r3qK+_Vg@mail.gmail.com>
Date: Fri, 7 Feb 2014 15:57:24 +0000
X-Google-Sender-Auth: HR4BxLGv1h8Cy4uo9CfSmJ-unac
Message-ID: <CAOb_Fnx31sVsQMZxG7E0gpv+gSNwfSuOPcEhsCZ2mJS2zFqh_Q@mail.gmail.com>
From: Kevin Smith <kevin@kismith.co.uk>
To: Dave Cridland <dave@cridland.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Ben Campbell <ben@nostrum.com>, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] IQ Handling vulnerabilities
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: kevin@kismith.co.uk
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Feb 2014 15:57:26 -0000

On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland <dave@cridland.net> wrote:
> On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr)
> <jhildebr@cisco.com> wrote:
>>
>> On 2/7/14 2:46 AM, "Thijs Alkemade" <thijs@xnyhps.nl> 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.

/K