GHSA-hfq9-hggm-c56q CVE-2024-47072
XStream is vulnerable to a Denial of Service attack due to stack overflow from a manipulated binary input stream
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 2.00%
- Chance of exploitation in the next 30 days. Higher than 80.77% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
1.4.21- Upgrade com.thoughtworks.xstream:xstream to this version or later
Description
Impact
The vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream when XStream is configured to use the BinaryStreamDriver.
Patches
XStream 1.4.21 detects the manipulation in the binary input stream causing the the stack overflow and raises an InputManipulationException instead.
Workarounds
The only solution is to catch the StackOverflowError in the client code calling XStream if XStream is configured to use the BinaryStreamDriver.
References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for CVE-2024-47072.
Credits
Alexis Challande of Trail Of Bits found and reported the issue to XStream and provided the required information to reproduce it.
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| com.thoughtworks.xstream:xstream | < 1.4.21 |
1.4.21 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
com.thoughtworks.xstream:xstream Maven → 1.4.21
- maven
<dependency><groupId>com.thoughtworks.xstream</groupId><artifactId>xstream</artifactId><version>1.4.21</version></dependency>- gradle
implementation("com.thoughtworks.xstream:xstream:1.4.21")
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
- Exploit maturity
- Proof of concept
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-121: Stack-based Buffer Overflow
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
How to prevent it
- Operation, Build and Compilation: Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.
- Architecture and Design: Use an abstraction library to abstract away risky APIs. Not a complete solution.
- Implementation: Implement and perform bounds checking on input.
- Implementation: Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.
- Operation, Build and Compilation: Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code. Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking. For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
CWE-502: Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
How to prevent it
- Architecture and Design, Implementation: If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
- Implementation: Explicitly define a final object() to prevent deserialization.
- Architecture and Design, Implementation: Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
- Implementation: Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
- Architecture and Design, Implementation: Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
- Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
References
Advisories
Packages
Other links
- github.com/x-stream/xstream/security/advisories/GHSA-hfq9-hggm-c56q
- github.com/x-stream/xstream/commit/bb838ce2269cac47433e31c77b2b236466e9f266
- github.com/x-stream/xstream/commit/fdd9f7d3de0d7ccf2f9979bcd09fbf3e6a0c881a
- lists.debian.org/debian-lts-announce/2024/12/msg00023.html
- x-stream.github.io/CVE-2024-47072.html
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| CVE-2021-39144 XStream is vulnerable to a Remote Command Execution attack | High Known exploited | Also affects com.thoughtworks.xstream:xstream |
| GHSA-f8cc-g7j8-xxpm XStream can cause a Denial of Service by injecting deeply nested objects raising a stack overflow | High | Also affects com.thoughtworks.xstream:xstream |
| GHSA-j563-grx4-pjpv XStream can cause Denial of Service via stack overflow | High | Also affects com.thoughtworks.xstream:xstream |
| GHSA-rmr5-cpv2-vgjf Denial of Service by injecting highly recursive collections or maps in XStream | High | Also affects com.thoughtworks.xstream:xstream |
| GHSA-64xx-cq4q-mf44 XStream is vulnerable to an Arbitrary Code Execution attack | High | Also affects com.thoughtworks.xstream:xstream |
| GHSA-6wf9-jmg9-vxcc XStream can cause a Denial of Service | Medium | Also affects com.thoughtworks.xstream:xstream |
| GHSA-g5w6-mrj7-75h2 XStream is vulnerable to an Arbitrary Code Execution attack | High | Also affects com.thoughtworks.xstream:xstream |
| GHSA-8jrj-525p-826v XStream is vulnerable to an Arbitrary Code Execution attack | High | Also affects com.thoughtworks.xstream:xstream |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor