Re: [xmpp] IQ Handling vulnerabilities

Alexander Holler <holler@ahsoftware.de> Fri, 07 February 2014 11:23 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 4E4D31A0369 for <xmpp@ietfa.amsl.com>; Fri, 7 Feb 2014 03:23:37 -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 I6hQ0K1NtVqu for <xmpp@ietfa.amsl.com>; Fri, 7 Feb 2014 03:23:35 -0800 (PST)
Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 84F011A0033 for <xmpp@ietf.org>; Fri, 7 Feb 2014 03:23:35 -0800 (PST)
Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 39A34423C2A6; Fri, 7 Feb 2014 12:23:34 +0100 (CET)
Received: from eiche.ahsoftware (p57B23F62.dip0.t-ipconnect.de [87.178.63.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 33756423C256 for <xmpp@ietf.org>; Fri, 7 Feb 2014 12:23:33 +0100 (CET)
Received: by eiche.ahsoftware (Postfix, from userid 65534) id 54BF980378; Fri, 7 Feb 2014 12:23:31 +0100 (CET)
Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id 4977C7FA6C for <xmpp@ietf.org>; Fri, 7 Feb 2014 11:23:25 +0000 (UTC)
Message-ID: <52F4C22C.6080305@ahsoftware.de>
Date: Fri, 07 Feb 2014 12:23:24 +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: XMPP Working Group <xmpp@ietf.org>
References: <CAOb_FnxS-dMT85N7LHj5M9JWk3pL85=ugrDqaT7j5d28HBr0Cw@mail.gmail.com>
In-Reply-To: <CAOb_FnxS-dMT85N7LHj5M9JWk3pL85=ugrDqaT7j5d28HBr0Cw@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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 11:23:37 -0000

Am 06.02.2014 12:26, schrieb Kevin Smith:
> Hi folks,
>    Discussion in the XSF and at the recent XMPP Summit has shown that
> there are widespread issues with handling of iq responses in XMPP
> software. This is probably something we need to consider handling.
>
> The basis of this is that many libraries/clients
> a) Only check the id of an iq error/result, not the sender, to check
> it matches one they've sent (Very Wrong)
> b) Use predictably generated ids for stanzas (ill-advised, but not
> strictly wrong)
> c) Use known resource strings (bad, but not strictly wrong)

Just to make it clear, the real problem here is neither the IDs nor the 
resources, but not checking the sender of the reply.

If the sender would be checked, random IDs would only protect against 
sniffing/injecting packets into a stream or against malicious servers. 
The first (sniffing/injecting) is already protected by using encryption 
and the second (malicious servers) doesn't make much sense at all, 
because a client has to trust it's server.

One of the reasons why clients don't check the sender part seems to be 
that it wasn't clear what the sender of a reply is, if the IQ query was 
without an explicit 'to' attribute.

A simple rule for clients could be to check that the JID of IQ replies 
where the origin should be the connected server is either the JID of the 
server (no node, no resource) or the received bare JID (stripping a 
possible resource) is the bare JID of the client.

Regards,

Alexander Holler