Don't send error stanza as reply to error stanza (EJAB-930)

Reported in Debian as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585832

I think there's no need to take special actions for 2.1.3: we will upload 2.1.4 quite soon which has this issue fixed.

Will the 2.1.4 be available for Ubuntu 10.04, too?
Otherwise the 2.1.2-2 should be patched.

Hmm, if I read https://support.process-one.net/browse/EJAB-930 correctly, this issue affects ejabberd versions since 2.0.1; this even means Debian Lenny (current stable). I've no idea about Ubuntu versions affected as I have no idea about what's considered "supported" at the moment.
Consequently, I'm gonna prepare a secutity update for Debian Lenny's 2.0.1.
Upload of 2.1.4 to Debian Sid/Squeeze will make it into Maverick (right)?
So what's the plan to fix 2.1.2 in 10.04? (If I read ubuntu.com correctly, 10.04 is the current Ubuntu release, Lucid).

Well, I failed to reply the "Will the 2.1.4 be available for Ubuntu 10.04, too?" question, MiGri, sorry.
The answer is: I have no idea how to make 2.1.4 available for specific Ubuntu release as I do not use Ubuntu.
Also, in Debian, we would not upload 2.1.4 to already-released version, but this is Debian's policy, I, again, have no idea about Ubuntu's.

After consulting with one of upstream developers, it became clear this bug cannot be exploited from the outside and so it's not really that serious as it might sound because it does not introduce a vulnerability.
To exploit this bug, a hostile party should convince the server administrator to misconfigure one or more of their xmpp components; clearly, such an attacker could as well convince her to run `rm -rf /` as root.

If I understand the bug correctly, that's only half the story.
Badlop give an example for an exploit on 15/May/09 (sic!) at https://support.process-one.net/browse/EJAB-930.
The restriction of a service - like the MUC-service in the example - is not a misconfiguration but can be set very deliberately.

I disagree: Badlop connected to a muc service and sent it an error stanza, in reply, the muc service sent his client another stanza; this violates RFC but what else? This does not result in any loop just by itself because well-behaving clients won't send their own error stanza back. So to DoS the server, there should be used a specially crafted client which would respond to any error coming from the server with another error, but this is nothing new -- such a client could just send certain IQ requests to the server as fast as it is able to.

I see 2.1.5-1 is in Maverick so this bug should possibly be closed now.

This one gets urgend now. In combination with spectrum (http://spectrum.im) the ejabberd beam process used 100% of the cpu and the load of the server increased to 1.00.
This behavior is described in https://support.process-one.net/browse/EJAB-1213

Please update ejabberd asap for lucid!

Agreed, should be fixed since Maverick. If you want to backport a fix of this to Lucid, please follow the SRU process: http://wiki.ubuntu.com/SRU

I have prepared a backport for Lucid about two months ago [1] and getting a working package is just a matter of running git-buildpackage on the checkout of that branch. I have prepared that fix to help MiGri get this fix into his distro, but I can't do anything beyond that as I'm not affiliated with Ubuntu in any way except for being the downstream maintainer for this particular package it makes available.

It occurs to me that crying out "Please update ejabberd asap for lucid!" simply won't work for an unmaintained package, so there should be some other way to push the fix. Is there anything resembling the Debian's "debian-devel" mailing list to raise this question there?

1. http://git.deb.at/w/pkg/ejabberd.git/shortlog/refs/heads/lucid