Re: [xmpp] IQ Handling vulnerabilities

Alexander Holler <holler@ahsoftware.de> Tue, 11 February 2014 12:24 UTC

Return-Path: <holler@ahsoftware.de>
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 EC6B41A081F for <xmpp@ietfa.amsl.com>; Tue, 11 Feb 2014 04:24:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.208
X-Spam-Level:
X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, 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 dmESqtrXAZIS for <xmpp@ietfa.amsl.com>; Tue, 11 Feb 2014 04:24:06 -0800 (PST)
Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id D275B1A0281 for <xmpp@ietf.org>; Tue, 11 Feb 2014 04:24:05 -0800 (PST)
Received: by mail.ahsoftware.de (Postfix, from userid 65534) id C1E32423C2E6; Tue, 11 Feb 2014 13:24:02 +0100 (CET)
Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 98BE9423C2BC for <xmpp@ietf.org>; Tue, 11 Feb 2014 13:24:01 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id 252A87FA1B; Tue, 11 Feb 2014 13:24:00 +0100 (CET)
Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id 0FB597F82C; Tue, 11 Feb 2014 12:23:56 +0000 (UTC)
Message-ID: <52FA165B.8050901@ahsoftware.de>
Date: Tue, 11 Feb 2014 13:23:55 +0100
From: Alexander Holler <holler@ahsoftware.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Thijs Alkemade <thijs@xnyhps.nl>, "Joe Hildebrand (jhildebr)" <jhildebr@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> <CF1A4928-54B5-4A95-9A4B-0EC572A3CDBD@cisco.com> <CF1E56C5.38F45%jhildebr@cisco.com> <B671D7DA-CE9A-4A2C-8EDE-BF94F5F6FE82@xnyhps.nl>
In-Reply-To: <B671D7DA-CE9A-4A2C-8EDE-BF94F5F6FE82@xnyhps.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
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: Tue, 11 Feb 2014 12:24:09 -0000

Am 10.02.2014 20:25, schrieb Thijs Alkemade:
>
> On 10 feb. 2014, at 18:15, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
>
>> On 2/7/14 8:13 AM, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com> wrote:
>>
>>> I have a couple of ludicrous s2s attacks on mind, but more important I
>>> think is doing what
>>>
>>> Mobile/terse. DYAC.
>>
>> Yes, well that was even more terse than normal.  I was going to say
>> something about generating less-guessable IDs that don't eat up much
>> entropy.  For example:
>>
>> start = sha1(crytpo_rand())
>> start+1 = sha1(start)
>>
>> would probably do nicely.
>
> Uhm. Maybe this email is missing a line again, but if you use those values as
> 'id's directly, they will not be unpredictable at all, as anyone who receives
> an <iq/> can generate the rest of the chain.
>
> However, if you make sure the 'id' values are only half the hashes, it should
> be unpredictable unless an attacker is willing to spend an insane amount of
> work.
>
> So:
>
> start = sha1(crytpo_rand())
> start+1 = sha1(start)
> ...
>
> id1 = start[0:10]
> id2 = start+1[0:10]
> …

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

Regards,

Alexander Holler