Re: [xmpp] IQ Handling vulnerabilities

Kevin Smith <> Fri, 07 February 2014 12:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51F611A1DBE for <>; Fri, 7 Feb 2014 04:21:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1k2dPyOh8qy7 for <>; Fri, 7 Feb 2014 04:21:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::22d]) by (Postfix) with ESMTP id D4A571A0398 for <>; Fri, 7 Feb 2014 04:21:09 -0800 (PST)
Received: by with SMTP id ld13so2592127vcb.32 for <>; Fri, 07 Feb 2014 04:21:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WrKpSsDeq82WFJD8T+uKqe3NdNRlOlwPSZhoaZ/WyHM=; b=TXXi8AterrX370oYxJlHtYX7sOzXjwcFEYvGV3QgkApH6yNt+vT2KUmqc+48rWVwbu widsduqsj5jCzAxjOhBuewE1dEcRtd+pBch8KW4xhucexXpsKVL89r5vHYFwsUUFkC9c nHvK6dZ8rjzODN5hQQKzuTuzGofgxdbmSOLjyrQyRS+U5tYYv+u1J+XiBUIA9y14Hca4 1JWZF7QIri4teMeXSRK+2eTZiqtkJI6JOL8Gq0/gWfeYZiBSa3uexcHRY2BUxInlvkKL sq1uOUcDNJNgm0z2kvPjLqf4hnAz3EYlcs6on9onBnjcC84a7M7TyWzq1barXBdVfOUd QtxA==
MIME-Version: 1.0
X-Received: by with SMTP id at9mr10423352ved.20.1391775669675; Fri, 07 Feb 2014 04:21:09 -0800 (PST)
Received: by with HTTP; Fri, 7 Feb 2014 04:21:09 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Fri, 7 Feb 2014 12:21:09 +0000
X-Google-Sender-Auth: KviLIJFa7cgF6pA4z3JPNWpAyJU
Message-ID: <>
From: Kevin Smith <>
To: Alexander Holler <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: XMPP Working Group <>
Subject: Re: [xmpp] IQ Handling vulnerabilities
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2014 12:21:11 -0000

On Fri, Feb 7, 2014 at 11:23 AM, Alexander Holler <> wrote:
> 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.

There are three issues here. They have different severities, as I
noted initially, and not checking the sender of a reply is the one
that is completely and fundamentally broken. That doesn't preclude
that the other two are also issues (which we may or may not decide
need addressing right now - although I'm of the opinion that while
writing a document explaining the issues, explaining all three would
be worthwhile).  The most egregious of the vulnerabilities involve
having all three present.

We've known the from checking to be an issue for at least three years
(that's the first record I could easily find of discussing the
problem), but how widespread that problem is is news. Using
predictable ids and resources is well known.

(There's an additional point to be made about checking the from of
roster pushes, although I believe this to be a less widespread

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

I'd assert that the correct handling is clear, just that it seems to
go unnoticed for some reason - but why we're in the state of needing
to say something about this seems less important than what we now say.

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

The rules here are clear. If a client sends a stanza without a 'to',
the server is to handle it as if it was sent to the bare JID of the
client's session. The server replying with the server JID is a bug.