ejabberd: CVE-2010-0305 remote denial of service via too many client2server messages

Debian Bug report logs - #568383
ejabberd: CVE-2010-0305 remote denial of service via too many client2server messages

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ejabberd: CVE-2010-0305 remote denial of service via too many client2server messages

Date: Thu, 4 Feb 2010 13:55:49 +0100

[Message part 1 (text/plain, inline)]

Package: ejabberd
Severity: grave
Tags: patch security

A remotely exploitable denial of service vulnerability has been found in ejabberd
which allows an attacker to crash because of a message queue overload when
sending too many client2server message to the server (e.g. via a rogue client).

Patches are available at:
https://support.process-one.net/browse/EJAB-1173;jsessionid=CC9A1D875A20197DD4571444DA8C1EFB?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel

CVE-2010-0305 has been assigned to this issue. Please mention this CVE id in the
changelog when fixing this bug.

Cheers
Nico

-- 
Nico Golde - http://www.ngolde.de - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[signature.asc (application/pgp-signature, inline)]

Message #12 received at 568383-close@bugs.debian.org (full text, mbox, reply):

From: Konstantin Khomoutov <flatworm@users.sourceforge.net>

To: 568383-close@bugs.debian.org

Subject: Bug#568383: fixed in ejabberd 2.1.2-2

Date: Tue, 09 Feb 2010 22:47:54 +0000

Source: ejabberd
Source-Version: 2.1.2-2

We believe that the bug you reported is fixed in the latest version of
ejabberd, which is due to be installed in the Debian FTP archive:

ejabberd_2.1.2-2.diff.gz
  to main/e/ejabberd/ejabberd_2.1.2-2.diff.gz
ejabberd_2.1.2-2.dsc
  to main/e/ejabberd/ejabberd_2.1.2-2.dsc
ejabberd_2.1.2-2_powerpc.deb
  to main/e/ejabberd/ejabberd_2.1.2-2_powerpc.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 568383@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Konstantin Khomoutov <flatworm@users.sourceforge.net> (supplier of updated ejabberd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 04 Feb 2010 03:38:02 +0300
Source: ejabberd
Binary: ejabberd
Architecture: source powerpc
Version: 2.1.2-2
Distribution: unstable
Urgency: high
Maintainer: Torsten Werner <twerner@debian.org>
Changed-By: Konstantin Khomoutov <flatworm@users.sourceforge.net>
Description: 
 ejabberd   - distributed, fault-tolerant Jabber/XMPP server written in Erlang
Closes: 568383
Changes: 
 ejabberd (2.1.2-2) unstable; urgency=high
 .
   * Integrate upstream patches for EJAB-1173,
     fixing CVE-2010-0305 (closes: #568383).
Checksums-Sha1: 
 0457c8fcde32c99f9f35ac72e31b482c36c80ea2 1357 ejabberd_2.1.2-2.dsc
 0d75d9111a1bf5a020dce4d8f100c271da64e669 67911 ejabberd_2.1.2-2.diff.gz
 632bdcd17e0d65252d68307d2fcac883d3800eb5 1333854 ejabberd_2.1.2-2_powerpc.deb
Checksums-Sha256: 
 f9980c2eb8dfe8b6fa02ad66d62fb3dda7d66f57cd2c74bad89678315173f920 1357 ejabberd_2.1.2-2.dsc
 5e6b702b99d1440a0ff29e070db5c011597b42d4a1a212ba1b21846cd3148634 67911 ejabberd_2.1.2-2.diff.gz
 edc48a4f53baa41f572c3d7a1ce4d80c13b8d72d170c140de1420edd9505547a 1333854 ejabberd_2.1.2-2_powerpc.deb
Files: 
 c0e52e46035257335d203f4a17d67069 1357 net optional ejabberd_2.1.2-2.dsc
 57942779de587ea2e85a061937cbd61e 67911 net optional ejabberd_2.1.2-2.diff.gz
 f2d2a6bf0c19a986835d272603185a9e 1333854 net optional ejabberd_2.1.2-2_powerpc.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktx4+IACgkQELuA/Ba9d8Z2qwCgzJc2uQqvkxOGy92fS2y/DZHp
Z9QAnR1n4Dzr8JBsDEVEfN4xjk/Z91/I
=G6aZ
-----END PGP SIGNATURE-----

Message #17 received at 568383@bugs.debian.org (full text, mbox, reply):

From: Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>

To: 568383@bugs.debian.org

Cc: twerner@debian.org

Subject: more information

Date: Tue, 16 Feb 2010 03:39:26 +0100

Hi.

I think it would be a good idea if you give more information on this hole.
What it is about (break in or "just" DoS),... and perhaps some  
reasonable defaults for that config option.

btw: In the news file you talk about "outgoing connections" IIRC, but  
I think it's about incomming connections, isn't it?


Cheers,
Chris.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Message #22 received at 568383@bugs.debian.org (full text, mbox, reply):

From: Konstantin Khomoutov <flatworm@users.sourceforge.net>

To: Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de>, 568383@bugs.debian.org

Subject: Re: Bug#568383: more information

Date: Tue, 16 Feb 2010 15:24:19 +0300

On Tue, 16 Feb 2010 03:39:26 +0100
Christoph Anton Mitterer <christoph.anton.mitterer@physik.uni-muenchen.de> wrote:

> I think it would be a good idea if you give more information on this hole.
> What it is about (break in or "just" DoS),... and perhaps some  
> reasonable defaults for that config option.
> btw: In the news file you talk about "outgoing connections" IIRC, but  
> I think it's about incomming connections, isn't it?

It's a DoS and it's about outgoing streams of incoming connections.

In fact, no one among both ejabberd Debian packagers and ejabberd upstream
has any relation to issuing the CVE being discussed,
and upstream thinks the whole issue appears to be exaggregated.

Below are some details to make the issue more clear.

Ejabberd, being an Erlang program, consists of a (vast) number of
light-weight concurrent processes (not in OS sense, and not in OS threads'
sense, -- think of "green threads" if you like). Processes communicate by
"sending messages" to each other; each process has its "mailbox", in which
messages destined to it are queued. Roughly speaking, a continuously run
process just endlessly fetches messages from its mailbox and processes them.
Putting messages in a process's mailbox is asynchronous to the process
itself, that is, a process can be blocked in some syscall but this won't
prevent the runtime from appending messages to its mailbox.

Each connected user (each c2s session to be strict) in ejabberd
is controlled by an Erlang process which is responsible for:
1) Receiving an input XML stream from a corresponding TCP socket,
   parsing its stanzas, converting them into appropriate internal
   datagrams and sending them to a "router" process.
2) Receiving datagrams representing XML stanzas from the router process,
   converting them into XML stanzas and sending them to the TCP socket.
As can be seen, outgoing datagrams land into the c2s process's mailbox
before being pushed to the outgoing TCP stream controlled by that
process.

Now, imagine a situation:
1) We have a c2s session on a very slow link (or a link articifally
   slowed down using some sort of a shaper).
2) We have another c2s session with a link fast enough to keep up with
   the c2s shaper limit set in the server (if any).
3) Now the second session starts sending a series of any stanzas to
   the first one as fast as it can. This will end up in a series
   of messages being sent to a c2s process responsible for the session
   on a slow link. Several of them will be successfully streamed,
   but then the TCP stack will fill up its outgoing buffer and will
   start to block; since then the messages will start to accumulate
   in the process's mailbox because they won't be fetched by a blocked
   process. That is, a process will send its data out slower than it will
   receive the data to be sent.
Queueing messages means growing the system process's heap;
hence, there is a possibibity to make ejabberd process run out of heap
because message queues are unconstrained by default.

The fix implemented by upstream allows to set a hard limit on the number
of queued messages for certain ejabberd processes such as c2s and service
listeners as well as s2s stream controllers. If the limit is set,
then when it is reached the process is killed, its TCP streams are
teared down and an ERROR message is logged.

The real-world possibility of this exploit is questionable.
It was seen exactly once on jabber.ru (which has a typical workload
of ~20k online users); after which the original ejabberd bug was filed.
Most if not any servers which allow connections from potentially
hostile users, have rather tight configurations for c2s shapers
which makes such kind of exploit a quite time-consuming thing.

Send a report that this bug log contains spam.