CVE-2023-42809 in Redisson
Summary
by MITRE • 10/25/2023
Redisson is a Java Redis client that uses the Netty framework. Prior to version 3.22.0, some of the messages received from the Redis server contain Java objects that the client deserializes without further validation. Attackers that manage to trick clients into communicating with a malicious server can include especially crafted objects in its responses that, once deserialized by the client, force it to execute arbitrary code. This can be abused to take control of the machine the client is running in. Version 3.22.0 contains a patch for this issue.
Some post-fix advice is available. Do NOT use `Kryo5Codec` as deserialization codec, as it is still vulnerable to arbitrary object deserialization due to the `setRegistrationRequired(false)` call. On the contrary, `KryoCodec` is safe to use. The fix applied to `SerializationCodec` only consists of adding an optional allowlist of class names, even though making this behavior the default is recommended. When instantiating `SerializationCodec` please use the `SerializationCodec(ClassLoader classLoader, Set allowedClasses)` constructor to restrict the allowed classes for deserialization.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/25/2023
CVE-2023-42809 represents a critical deserialization vulnerability affecting Redisson Java clients that utilize the Netty framework for communication with Redis servers. This vulnerability stems from insufficient validation of serialized objects received from Redis servers, creating a pathway for remote code execution when clients process maliciously crafted responses. The flaw exists in Redisson versions prior to 3.22.0 where the client deserializes Java objects without proper security checks, allowing attackers to exploit this weakness through man-in-the-middle attacks or compromised Redis instances. The vulnerability aligns with CWE-502, which catalogs deserialization of untrusted data as a significant security risk, and maps to ATT&CK technique T1203 for legitimate user execution and T1059 for command and scripting interpreter execution.
The technical implementation of this vulnerability occurs within Redisson's serialization mechanisms where the client receives responses from Redis servers containing serialized Java objects. When these objects are processed through the deserialization pipeline without proper validation, attackers can craft specific payloads that, upon deserialization, execute arbitrary code on the client machine. This occurs because the deserialization process accepts objects from untrusted sources without sufficient type checking or class validation, creating an attack surface where malicious actors can leverage the client's deserialization capabilities to gain remote code execution privileges. The vulnerability particularly affects applications where Redisson clients are used in environments where the Redis server communication cannot be fully trusted, such as in cloud deployments or distributed systems where network boundaries are not strictly enforced.
The operational impact of this vulnerability extends beyond simple code execution to potentially compromise entire host systems where Redisson clients operate. An attacker exploiting this vulnerability can gain complete control over the machine running the vulnerable Redisson client, potentially leading to data theft, system compromise, or further lateral movement within network environments. The severity is compounded by the fact that Redisson is widely used in enterprise applications for caching, distributed locking, and session management, making this vulnerability particularly dangerous in production environments. Organizations using Redisson in mission-critical applications face significant risk of unauthorized access and potential data breaches, especially when the client communicates with untrusted Redis instances or when network security controls are insufficient to prevent man-in-the-middle attacks.
The patch implemented in Redisson version 3.22.0 addresses this vulnerability through enhanced serialization controls that introduce an optional allowlist mechanism for deserialization operations. The fix specifically modifies the SerializationCodec implementation to require explicit class whitelisting during deserialization, which prevents the execution of unauthorized object types. Security practitioners should immediately upgrade to version 3.22.0 or later to remediate this vulnerability, as the patch provides a robust defense against the described attack vectors. Additionally, administrators should carefully review their Redisson configurations and avoid using Kryo5Codec due to its continued vulnerability despite the general patch, while KryoCodec remains a safe alternative. The recommended approach involves instantiating SerializationCodec with the explicit constructor that accepts a class loader and allowed classes set to restrict deserialization to known safe types, thereby implementing defense-in-depth principles that align with security best practices outlined in industry standards such as NIST SP 800-53 and ISO 27001 security controls.