CVE-2018-10237

[sourabhsparkala]

CVE-2018-10237

During deserialization, two Guava classes accept a caller-specified size parameter and eagerly allocate an array of that size:

• AtomicDoubleArray (when serialized with Java serialization)
• CompoundOrdering (when serialized with GWT serialization)

If a server deserializes instances sent by an attacker, the attacker can quickly force the server to allocate all its memory, without even sending the promised number of elements. Note that most servers that accept serialized data will deserialize objects of these types as long as they are on the classpath, even if they are not used by the server. (It is possible to set up an allow or denylist for Java serialization, but few service owners do. GWT serialization does operate with an allowlist by default, but it is usually a large, automatically generated list that often includes the problem class.)

Attack Vectors

To be affected, a server running Guava must deserialize data sent by an attacker (either Java serialization or GWT-RPC).

To avoid this

• Fixed in guava versions 24.1.1 and 25.0
• If not updating, then when using AtomicDoubleArray , CompoundOrdering the owners who are concerned about this problem should set a limit on the size of the object graph that their servers will accept.

More information on this can be found here

Things to do

• Update to safer version of google guava 24.1.1 or 25.0

[dweiss]

This library dependency is no longer present in Carrot2 4.x.