On Tue, 16 Feb 2010 03:39:26 +0100 Christoph Anton Mitterer <christoph.anton.mitte...@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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216152419.00609ebe.kos...@domain007.com
