Uncontrolled Resource Consumption with XMPP-Layer Compression
Original Release Date: 2014-04-04
Last Updated: 2014-04-04
Overview
Several XMPP server implementations that support application-layer compression (XEP-0138) suffer from an uncontrolled resource consumption vulnerability (CWE-400). This vulnerability can be remotely exploited by attackers to mount Denial-of-Service attacks by sending highly-compressed XML elements over XMPP streams.
Description
XMPP stream compression is a desirable feature that reduces the amount of data transferred between the protocol principals. In XMPP, compression can be negotiated at the TLS layer (as described in RFC 6120) or at the application layer (as described in XEP-0138). The vulnerability that has been discovered applies specifically to application-layer compression; such compression is negotiated between an XMPP client and server (or two servers) as follows:
An XMPP server supporting application-layer compression advertises it in the stream feature message:
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<compression xmlns='http://jabber.org/features/compress'>
<method>zlib</method>
<method>lzw</method>
</compression>
</stream:features>
The client selects one of the advertised compression algorithms:
<compress xmlns='http://jabber.org/protocol/compress'>
<method>zlib</method>
</compress>
If no errors occur, the server agrees on the choice with the following message:
<compressed xmlns='http://jabber.org/protocol/compress'/>
After a successful negotiation, all the subsequent protocol messages are compressed.
When decompressing XMPP stanzas, an XMPP server must limit the resources allocated to this task. If the server fails to do that, it can monopolize the CPU usage and allocate all the available memory. As a result, remote attackers can exploit this vulnerability to mount a Denial of Service attack (DoS) by submitting highly-compressed XML elements over an XMPP stream (we call these “xmppbombs” for short).
An “xmppbomb” is a valid XML element sent over an XML stream but containing a huge number of white spaces. See for example the following element sent during stream negotiation (e.g., on a stream restart after TLS negotiation):
<?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 a 4GB long string of spaces and $SERVER is the server domain name. By using the zlib compression algorithm, it is possible to compress the above message to 4MB (compression ratio of ~1:1000).
XEP-0170 on “Recommended Order of Stream Feature Negotiation” suggests to negotiate stream compression after the authentication of the principals. This suggests that xmppbombs can be used only after the user authentication. However, it has been reported that some implementations allow the use of compression before the authentication phase therefore opening up this vulnerability to unknown attackers.
Impact
Affected servers are reported to:
Consume the virtual memory; in certain cases, it has been reported that servers are terminated by the operating system for out of memory conditions;
Monopolize the use of the CPU;
In certain cases, not allow administrators to disable stream compression.
Solution
It is best to upgrade to corrected server code. An alternative, temporary workaround is to disable XMPP-level compression.
Vendor Information
The following table provides information about existing XMPP server implementations. To the best of our knowledge it is accurate and complete, but server administrators are advised to check with the developers of their preferred server software to verify the information provided here.
Vendor Product Status Contacted Updated
Apache Vysper Unknown 2014-03-12, 2014-04-03 Unknown
Apple Inc. iChat Server Unaffected 2014-03-12 N/A
Cisco Systems, Inc. Jabber XCP Unaffected 2014-03-12 N/A
Citadel Citadel Unaffected 2014-03-12, 2014-04-03 N/A
CommuniGate CommuniGate Pro Unaffected 2014-03-12 N/A
Coversant SoapBox Server Unknown 2014-03-12, 2014-04-03 Unknown
djabberd djabberd Unknown 2014-03-12, 2014-04-03 Unknown
Erlang Solutions MongooseIM Under Investigation 2014-04-03 Unknown
Google Google Talk Unknown 2014-03-12, 2014-04-03 Unknown
IBM Lotus Sametime Gateway Unaffected 2014-03-12, 2014-04-03 N/A
IceWarp IceWarp Instant Messaging Server Unknown 2014-03-12, 2014-04-03 Unknown
igniterealtime.org Openfire Fixed in 3.9.2 2014-03-12 2014-04-03
inetdextra in.jabberd Unknown 2014-03-12, 2014-04-03 Unknown
Isode Ltd. M-Link Fixed in 16.0v7 2014-03-12 2014-03-31
jabberd 1.x jabberd 1.x Unaffected 2014-03-12, 2014-04-03 N/A
jabberd 2.x jabberd 2.x Unaffected 2014-03-12 N/A
j-livesupport Jerry Messenger Unknown 2014-03-12, 2014-04-03 Unknown
Kwickserver Kwickserver Unaffected 2014-03-12, 2014-04-03 N/A
lightwitch.org Metronome Fix in progress 2014-04-03 TBD
ProcessOne ejabberd Unaffected 2014-03-12 N/A
Prosody Prosody Fixed in 0.9.4 2014-03-12 2014-04-02
psyced psyced Unaffected 2014-03-12, 2014-04-03 N/A
Siemens Siemens OpenScape Unaffected 2014-03-12, 2014-04-03 N/A
Tigase Tigase Fixed in 5.2.1 2014-03-12 2014-03-30
Vines Vines Unaffected 2014-03-12, 2014-04-03 N/A
Wokkel Wokkel Unknown 2014-03-12, 2014-04-03 Unknown
Note: Although it is likely that a number of the servers with a status of “unknown” do not support XMPP-layer compression and therefore are not vulnerable to this uncontrolled resource consumption vulnerability, we have not heard from the developers of such servers and therefore cannot provide definitive information.
References
CWE-400: Uncontrolled Resource Consumption (‘Resource Exhaustion’)
RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core
XEP-0138: Stream Compression
XEP-0170: Recommended Order of Stream Feature Negotiation
Credits
The vulnerability was reported by Giancarlo Pellegrino. This report was written by Giancarlo Pellegrino with assistance from Peter Saint-Andre.
Feedback
If you have feedback, comments, or additional information about this vulnerability, please send email to the security@xmpp.org discussion list.
Polish
English