GHSA-rmr5-cpv2-vgjf BIT-jenkins-2021-43859 CVE-2021-43859
Denial of Service by injecting highly recursive collections or maps in XStream
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 7.93%
- Chance of exploitation in the next 30 days. Higher than 94.73% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
1.4.19- Upgrade com.thoughtworks.xstream:xstream to this version or later
Description
Impact
The vulnerability may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream.
Patches
XStream 1.4.19 monitors and accumulates the time it takes to add elements to collections and throws an exception if a set threshold is exceeded.
Workarounds
The attack uses the hash code implementation for collections and maps to force an exponential calculation time due to highly recursive structures with in the collection or map. Following types of the Java runtime are affected in Java versions available in December 2021:
- java.util.HashMap
- java.util.HashSet
- java.util.Hashtable
- java.util.LinkedHashMap
- java.util.LinkedHashSet
- java.util.Stack (older Java revisions only)
- java.util.Vector (older Java revisions only)
- Other third party collection implementations that use their element's hash code may also be affected
If your object graph does not use referenced elements at all, you may simply set the NO_REFERENCE mode:
XStream xstream = new XStream();
xstream.setMode(XStream.NO_REFERENCES);
If your object graph contains neither a Hashtable, HashMap nor a HashSet (or one of the linked variants of it) then you can use the security framework to deny the usage of these types:
XStream xstream = new XStream();
xstream.denyTypes(new Class[]{
java.util.HashMap.class, java.util.HashSet.class, java.util.Hashtable.class, java.util.LinkedHashMap.class, java.util.LinkedHashSet.class
});
Unfortunately these types are very common. If you only use HashMap or HashSet and your XML refers these only as default map or set, you may additionally change the default implementation of java.util.Map and java.util.Set at unmarshalling time::
xstream.addDefaultImplementation(java.util.TreeMap.class, java.util.Map.class);
xstream.addDefaultImplementation(java.util.TreeSet.class, java.util.Set.class);
However, this implies that your application does not care about the implementation of the map and all elements are comparable.
References
See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for CVE-2021-43859.
Credits
The vulnerability was discovered and reported by r00t4dm at Cloud-Penetrating Arrow Lab.
For more information
If you have any questions or comments about this advisory:
- Open an issue in XStream
- Contact us at XStream Google Group
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| com.thoughtworks.xstream:xstream | < 1.4.19 |
1.4.19 |
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.19
- maven
<dependency><groupId>com.thoughtworks.xstream</groupId><artifactId>xstream</artifactId><version>1.4.19</version></dependency>- gradle
implementation("com.thoughtworks.xstream:xstream:1.4.19")
Severity breakdown
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-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
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
Other links
- github.com/x-stream/xstream/security/advisories/GHSA-rmr5-cpv2-vgjf
- github.com/x-stream/xstream/commit/e8e88621ba1c85ac3b8620337dd672e0c0c3a846
- github.com/x-stream/xstream
- lists.debian.org/debian-lts-announce/2022/02/msg00018.html
- lists.debian.org/debian-lts-announce/2024/12/msg00023.html
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VAC…
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XOD…
- lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VACQY…
- lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XODFR…
- oracle.com/security-alerts/cpuapr2022.html
- oracle.com/security-alerts/cpujul2022.html
- x-stream.github.io/CVE-2021-43859.html
- openwall.com/lists/oss-security/2022/02/09/1
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-hfq9-hggm-c56q XStream is vulnerable to a Denial of Service attack due to stack overflow from a manipulated binary input stream | High | 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-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