Hi to everybody,

As Peter anticipated, I have found an uncontrolled resource consumption vulnerability in multiple XMPP servers when using deflate stream compression. All these vulnerabilities can be remotely exploited by attackers to mount CPU or memory-based DoS attacks by sending highly-compressed XMPP messages (xmppbombs).

The affected servers are Prosody 0.9.3, Openfire 3.9.1, Tigase server 5.2.0, and possible older versions. Other servers may be vulnerable as well, if you would like to test your own implementation, you can use the proof-of-concepts that I wrote available here http://trouge.net/misc/xmppbomb_exploit.tar.bz2. More details on the usage are included in the README file. If you may need further details or help, please let me know.

We verified the presence of the vulnerabilities in a black-box setting and monitoring the system resource consumption on our own servers. We monitored CPU usage, RSS/VSZ memory, disk I/O, and, in certain cases, also the availability of the service.

Payload: xmppbomb

A xmppbomb is created starting from a valid XMPP message and pumping in a huge number of white spaces, for example:

<?xml version='1.0' ?><stream:stream $SPACES to='$SERVER' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

where $SPACES is replaced with 4GB of spaces and $SERVER is the server domain name. You can generate xmppbombs with XMPPBombGen.java. In all our tests, we used xmppbombs of the size of 4MB that amounts to 4GB of uncompressed XMPP message each.

We created two attacks, respectively before and after the user authentication. Below, I am going to give you all the explanations.

Attack #1: xmppbomb before authentication

An example of this attack is in XMPPBombNoAuth.java. The attack is the following:

1. the attacker prepares offline a xmppbomb

2. the attacker then starts the XMPP protocol with the target by sending:

<?xml version='1.0'?><stream:stream to='server' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

3. afterwards, the attacker requests to enable on the DEFLATE compression:

zlib

4. finally, the attacker sends the xmppbomb

The steps 2-4 can be executed concurrently (e.g., by colluded attackers, or with a botnet).

We found out that Prosody and Openfire are vulnerable to this attack. Prosody allocates up to 7GB of physical memory (resident set size memory) with a single xmppbomb with 4GB of payload. The process is finally killed by the kernel due to an out of memory. Openfire uses instead 100% of the CPU and a bit less memory than Prosody (3GB) plus it writes to disk about 400 MB of data. We monitored delays on the availability of the service from x100 times to x10000 with parallel xmppbombs.

Attack #2: xmppbomb after authentication:

An example of this attack is in XMPPBombAuth.java. The attack is the following:

1. the attacker prepares offline an xmppbomb

2. the attacker then starts the XMPP protocol (see step 2 in Attack #1)

3. the attacker logs in:

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN' client-uses-full-bind-result='true'>$TOKEN</auth>

where $TOKEN is the base 64 of the user name and password.

The attack then continues with step 3 and 4 of the attack #1.

Tigase is vulnerable to this attack and a single 4GB of xmppbomb pushes the CPU usage up to 100% for about 10 minutes.

Solutions

My first personal advice would be to not use data compression until the problem is fixed. While Prosody allows to disable compression (to be precise compression is not enabled by by default), I couldn't find a way to disable it on Openfire and Tigase. Honestly, I haven't played that much with their configurations and I would kindly ask the developers to say something about that.

Second, servers should enable to limit the maximum size of stanzas and the maximum bandwidth of data sent to the server per connection. These two solutions are already in RFC 6120 (http://tools.ietf.org/html/rfc6120#section-13.12). It should be paid attention how these limits are implemented when data decompression is enabled. I would suggest to use the maximum size of stanzas as the size of the buffer passed to the zlib to store the uncompressed data. Then, the bandwidth can be implemented as number of bytes uncompressed per second.

Third, I think that also the specs may warn developers on the risk of DoS via xmppbombs. The points 4 and 6 of Section 13.12 of RFC 6120 are SHOULDs rather than MUSTs and they refer only to uncompressed data. Then, XEP-0138 doesn't mention any XMPP-specific security consideration and it refers to the security consideration of TLS (See https://tools.ietf.org/html/rfc3749#page-5) that addresses (1) a binary-oriented protocol (2) concerns when combining compression and encryption and (3) risk of data size expansion. I think that this left a grey area in which developers took different decisions leading to these vulnerabilities. IMHO, XEP-0138 should be amended with a subsection inside Section 7 saying that if points 4 and 6 of Section 13.12 of RFC 6120 are not implemented then the implementation may be vulnerable to DoS via xmppbombs.

I think that from my side this is pretty much it.

Cheers,

Giancarlo