IETF Logo Mail Archive

Re: [xmpp] IQ Handling vulnerabilities

"Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> Fri, 07 February 2014 16:13 UTC

Return-Path: <jhildebr@cisco.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 C6D6B1AC4B3 for <xmpp@ietfa.amsl.com>; Fri, 7 Feb 2014 08:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level:
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 VEkvuCvunyeY for <xmpp@ietfa.amsl.com>; Fri, 7 Feb 2014 08:13:18 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEEA1A03E6 for <xmpp@ietf.org>; Fri, 7 Feb 2014 08:13:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4894; q=dns/txt; s=iport; t=1391789598; x=1392999198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7znhPWFi3bnBwufTiQszhvIuNHJVbcTaZtE0F6YLuLo=; b=EV4LQteWBQHtwVkq1uLJPFXjE3IIL+2FuQD/P2Q+nf9pkufN5kVYXWCA frLyqcG+2EC1CfICTGXPxrnamQYaACxGbDymwJ2WCNUX6otviJFoHdO3A JdkR2J0fJ2r93coapalVeukdVeGrg43oOh+wmB8rW1xm+ySzh2GRLiWri s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAB0F9VKtJXG9/2dsb2JhbABZgwy7dYQCgQ4WdIImAQEEeRACAQgEOwcyFBECBA4FFIdxzFAXjn0HgySBFASYK5Ihgy0
X-IronPort-AV: E=Sophos; i="4.95,801,1384300800"; d="scan'208,217"; a="18757772"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 07 Feb 2014 16:13:17 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s17GDHos008660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 16:13:17 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 10:13:17 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Dave Cridland <dave@cridland.net>
Thread-Topic: [xmpp] IQ Handling vulnerabilities
Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEAgACdaoCAAL9TgP//w6cAgACRRID//6GvVw==
Date: Fri, 07 Feb 2014 16:13:16 +0000
Message-ID: <CF1A4928-54B5-4A95-9A4B-0EC572A3CDBD@cisco.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>
In-Reply-To: <CAKHUCzyCwKbmnUoXLHW=XzYbiFrcg-dQsDojGUnA-_r3qK+_Vg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_CF1A492854B54A959A4B0EC572A3CDBDciscocom_"
MIME-Version: 1.0
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
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 16:13:21 -0000

I have a couple of ludicrous s2s attacks on mind, but more important I think is doing what

Mobile/terse. DYAC.

On Feb 7, 2014, at 7:50 AM, "Dave Cridland" <dave@cridland.net<mailto:dave@cridland.net>> wrote:

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

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.

Dave.

v2.23.0 | Report a Bug | By Email