Re: [xmpp] IQ Handling vulnerabilities

Waqas Hussain <waqas20@gmail.com> Sun, 09 February 2014 15:01 UTC

Return-Path: <waqas20@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 C1E801A0325 for <xmpp@ietfa.amsl.com>; Sun, 9 Feb 2014 07:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 YhrdU9x-74bi for <xmpp@ietfa.amsl.com>; Sun, 9 Feb 2014 07:01:32 -0800 (PST)
Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 50B341A0320 for <xmpp@ietf.org>; Sun, 9 Feb 2014 07:01:32 -0800 (PST)
Received: by mail-vb0-f49.google.com with SMTP id x14so3971908vbb.22 for <xmpp@ietf.org>; Sun, 09 Feb 2014 07:01:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=m62Mu8BObcQdaizNNdnolPJ9SniVfpz2HMMgNvQ28oE=; b=PyAvq6TAxCDdM7zTZzoC5Ag4M9ynBOp29MC49N1InJhOlvIEJDd6AYh22lyzvnHWlL ksR5D7KT6pzinXvPBKEG7uL1ZmF8tWoJ6QHwB6I2Ro71WAfHD2fm+6oWOMacBZeTtQaF MIfH+lqJOWqU+FOD7UbKLtSNl+Nzar7gx0jn2Oaz6wXUuewrfuevJh8RRfdyYwIfZFGm 8Kq1swiev33ik923z5s1W8ukrTdMO+UF50RGFQcwN5knypn8Xs7WJWClm4lJ5EFkLo9J efUnTowOU8+XDbzFQouIE57C33snIuMJcPQfqBGyd+1/RMLeFO4dW9DvgPwHkTf57KlI EroA==
X-Received: by 10.52.95.233 with SMTP id dn9mr16382833vdb.3.1391958092271; Sun, 09 Feb 2014 07:01:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.74.104 with HTTP; Sun, 9 Feb 2014 07:01:12 -0800 (PST)
In-Reply-To: <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl>
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> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl>
From: Waqas Hussain <waqas20@gmail.com>
Date: Sun, 9 Feb 2014 10:01:12 -0500
Message-ID: <CALm9TZ_Bp61_C81ZB=BTc4gyR+N0=gJEnpOsLr9-H9vrEk973g@mail.gmail.com>
To: Thijs Alkemade <thijs@xnyhps.nl>
Content-Type: text/plain; charset=ISO-8859-1
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: Sun, 09 Feb 2014 15:01:33 -0000

On Sun, Feb 9, 2014 at 9:13 AM, Thijs Alkemade <thijs@xnyhps.nl> wrote:
>
>> 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.
>
> I'm trying to think of a situation where the server sends a iq 'get' to the
> client, but I don't really know any. A lot of iq 'set's, where the server
> informs the client of something (and probably doesn't really care whether that
> results in an 'error' or 'result'), but nothing where the server wants to know
> something from the client. Could you give an example?
>

disco#info requests for PEP, though in this case Prosody happily uses
a single constant id for all requests, only using the sender's JID and
subscription status.
MUC is another when it proxies IQ requests (vCards, private IQs), and
for vCards Prosody encodes a bunch of information in the id for
verification.

A quick search through prosody-modules found implementations of
XEP-0309: Service Directories and XEP-268: Incidents Handling
listening for IQ results.

--
Waqas Hussain