[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 7 Apr 2014 17:32:15 -0400 (EDT)
From: cve-assign@...re.org
To: carnil@...ian.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Possible CVE Request: Uncontrolled Resource Consumption with XMPP-Layer Compression
-----BEGIN PGP SIGNED MESSAGE-----
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.
> http://xmpp.org/resources/security-notices/uncontrolled-resource-consumption-with-highly-compressed-xmpp-stanzas/
The two types of CVEs would be:
(1)
> 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.
(2)
> 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTQxkWAAoJEKllVAevmvmsBs4H/RbrYMIZK+/VDh//wVFXySou
dIeEeguVFWqs5YMAp6GCsXbQoZYhCpGmENTuu5hXst8KhxLvnCmQ4XuRVWedaGdQ
qVwI1ip5EOgi3Ij1V7ML6KiPlcx8FhPLxWOE5O/xH6e4vX3qQHiEynWNVOgEP/zq
nIjrgivTQygJwHZQp6FevGiD/S5lSeyaKlP82E0mCaRHPo1ZDnlPqoVux8O0TlND
oysVbHsCcdXBGAusoUPANvtmQrSN6UHC3H9Zy/vV2Vc029ew5Zr/AgGwiR4Je5d5
+0XnH/6sJoVzGWTah5e5vQhFV24h9w5kXBu/Sr8zWzwjsYOby1Y7dh2evLdN1qk=
=58gv
-----END PGP SIGNATURE-----
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.
