Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Apr 2014 17:32:15 -0400 (EDT)
Subject: Re: Possible CVE Request: Uncontrolled Resource Consumption with XMPP-Layer Compression

Hash: SHA1

> Is this something which should get one CVE, or is a CVE for each
> implementation needed?

A single CVE for this cross-vendor situation seems wrong because the
specification apparently does not require implementations to have an
unrestricted decompression capability.

There could conceivably be two CVEs for a single implementation,
although we haven't yet found a reference that is reporting an
implementation's problems at that level of detail. Most likely there
would be one CVE per implementation.


The two types of CVEs would be:

> 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. 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.

Here, the root cause is that the behavior in the authenticated case
does not properly address resource consumption. Apparently multiple
vendors are characterizing this as a vulnerability.

> it has been reported that some implementations allow the use of
> compression before the authentication phase therefore opening up this
> vulnerability to unknown attackers.

Here, the root cause is a violation of a specification, resulting in a
security impact.

A hypothetical example is that a server is willing to decompress
relatively short strings in unauthenticated sessions (e.g., decompress
32 kilobytes to 32 megabytes). That same server has no restrictions on
authenticated sessions, and can produce gigabytes of uncompressed
data. In this scenario, two CVE IDs would be assigned because the two
resource-consumption issues occur for different reasons.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.