Re: [xmpp] IQ Handling vulnerabilities

Dave Cridland <dave@cridland.net> Tue, 11 February 2014 12:29 UTC

Return-Path: <dave@cridland.net>
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 728E61A0381 for <xmpp@ietfa.amsl.com>; Tue, 11 Feb 2014 04:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 i6IZN_IaMLZr for <xmpp@ietfa.amsl.com>; Tue, 11 Feb 2014 04:29:44 -0800 (PST)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB7051A0281 for <xmpp@ietf.org>; Tue, 11 Feb 2014 04:29:43 -0800 (PST)
Received: by mail-oa0-f48.google.com with SMTP id l6so9049342oag.35 for <xmpp@ietf.org>; Tue, 11 Feb 2014 04:29:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zanoJCLXFZSVa5D0soaoFjj4qlxfVXbJ2+gv/42Yht0=; b=QBFH4qk1+fwMhN9V7saFUpfPXKg1cBCKY87Xv0RH54lj/ZTQVMvtOeZ01VCEzm2f5j 1wQTXoLgwS+jQzk6zKzBrsXaR3EAjlVl7OhYrw7Ay4vdAFfTBLKRiNt/Y3L1VebZ9Txp KGr/asYQgWc98LOVXojr6qDrZe5mbzfNhNVqQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zanoJCLXFZSVa5D0soaoFjj4qlxfVXbJ2+gv/42Yht0=; b=S5TT8sPfsBj/d93QRkhiB04/TRaI7PVU7hHSkPC+DowwuMKUAm+j97hnQOQnSjFSJH 6wW23ccnIq0sJnwzdtFAx+fVYV/TPoCZF2YMSKQX96pS/7ZXLne4ntexN6mgGihIT4XP MNvBlJ4/M5++nkX7XmYd3nBMZE9P15tHoENMzQooByYWtRvPNhmj6dcyv72NcrmLkjbL yCzVvEp9lXnWYWOflrzzj9dBI+b7qMMqiRBaW/kNBtI6bp8LROtZ1/KGFICNu7qgm+Om bGcKDFOdTqTV2neHV3EMRCQarzagZ+OK4c6eOC0RWnfEKET+4RLPdpOktuLM8sGw8tQq YPSQ==
X-Gm-Message-State: ALoCoQlzqIQVAeGuRWuw7hTcrCF0YucnwnbG5RSfunGIiS+UpgydHg78sTKjwjM19M/XvTFv51Sa
MIME-Version: 1.0
X-Received: by 10.60.142.166 with SMTP id rx6mr518714oeb.57.1392121783124; Tue, 11 Feb 2014 04:29:43 -0800 (PST)
Received: by 10.60.55.197 with HTTP; Tue, 11 Feb 2014 04:29:42 -0800 (PST)
In-Reply-To: <52FA165B.8050901@ahsoftware.de>
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> <CF1A4928-54B5-4A95-9A4B-0EC572A3CDBD@cisco.com> <CF1E56C5.38F45%jhildebr@cisco.com> <B671D7DA-CE9A-4A2C-8EDE-BF94F5F6FE82@xnyhps.nl> <52FA165B.8050901@ahsoftware.de>
Date: Tue, 11 Feb 2014 12:29:42 +0000
Message-ID: <CAKHUCzzhxKLbkNE=WjtP9S6XWm14-5e7Ut150x4k1akegm+1Qw@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Alexander Holler <holler@ahsoftware.de>
Content-Type: multipart/alternative; boundary=047d7b2e0b295e1a3404f2209cb1
Cc: XMPP Working Group <xmpp@ietf.org>, Ben Campbell <ben@nostrum.com>
Subject: Re: [xmpp] IQ Handling vulnerabilities
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Tue, 11 Feb 2014 12:29:45 -0000

On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler <holler@ahsoftware.de>wrote;wrote:

> Hmm, in all these mails it was never be mentioned that IDs still have to
> be unique over some time for one session. I'm not sure if such is given
> with the above constructs. It might be very unlikely that the same ID will
> appear twice, but someone has to take a deeper look at it when using such
> constructs like above. Of course, in reality the window in time IDs must be
> unique is rather small, but ...
>

You'd need random collisions amongst cryptographically secure hashes.
You're pretty safe.

In practise, ids do not have to be unique anyway, even over a small window.
Most MUC implementations preserve ids on broadcast, for instance, to no
ill-effect.

Dave.