Skip to content

Remote Code Execution Vulnerability in Session Storage

Critical severity GitHub Reviewed Published Jun 29, 2021 in ratpack/ratpack • Updated Feb 1, 2023

Package

maven io.ratpack:ratpack-core (Maven)

Affected versions

< 1.9.0

Patched versions

1.9.0

Description

Impact

A malicious attacker can achieve Remote Code Execution (RCE) via a maliciously crafted Java deserialization gadget chain leveraged against the Ratpack session store.

If your application does not use Ratpack's session mechanism, it is not vulnerable.

Details

Attackers with the ability to write to session data, can potentially craft payloads that deserialize unsafe objects, leading to the ability to remotely execute arbitrary code.
This is known as an “insecure deserialization” vulnerability, or “gadget vulnerability”.

Ratpack allows session data to be stored server side in an external system such as a relational database, or client side via user cookies.
When using server side storage, the attacker would need to obtain the ability to write to the session data store.
When using client side storage, the attacker would need to obtain the secrets used to encrypt and/or sign the session data stored in user cookies.

Ratpack's session mechanism allows storing serialized objects, of arbitrary types.
The type must be specified when writing the data and when reading, with data only deserialized when there is an exact type match.
However, in the process of deserializing an object of a known/trusted/deserialization-safe type, it may attempt to deserialize unsafe types.

By default Ratpack uses Java's built-in serialization mechanism, though other serialization providers can be used.
The exact types of payloads required to enable an exploit depend on the exact serialization mechanism used.

To mitigate this vulnerability, Ratpack now employs a “strict allow-list” when deserializing (and serializing) objects to session data.
All concrete types of objects serialized must be explicitly declared as safe.
Some standard well known JDK types are registered by default.

Serialization is provided by implementations of SessionSerializer.
Its existing methods have been deprecated, and replaced with a new methods that accept a SessionTypeFilter that can be used to assert whether a type is allowed when serializing and deserializing.

The default serializer implementation has been updated to use this mechanism.
Any proprietary implementations should also be updated to consult the type filter before serializing or deserializing data.
Warnings will be logged any time an implementation that does not implement the new methods is used.

Upon upgrading to Ratpack 1.9, users of the built-in serialization mechanism will need to change their application to declare all types currently being serialized as being safe. This can be done using the new SessionModule.allowTypes() method. Please see its documentation for details...))

Patches

Ratpack 1.9.0 introduces a strict allow-list mechanism that mitigates this vulnerability when used.

Workarounds

The simplest mitigation for users of earlier versions is to reduce the likelihood of attackers being able to write to the session data store.

Alternatively or additionally, the allow-list mechanism could be manually back ported by providing an alternative implementation of SessionSerializer that uses an allow-list.

References

References

@ldaley ldaley published to ratpack/ratpack Jun 29, 2021
Published by the National Vulnerability Database Jun 29, 2021
Reviewed Jun 30, 2021
Published to the GitHub Advisory Database Jul 1, 2021
Last updated Feb 1, 2023

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

EPSS score

0.234%
(62nd percentile)

Weaknesses

CVE ID

CVE-2021-29485

GHSA ID

GHSA-hc33-32vw-rpp9

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.