Description
The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
Serialization and deserialization refer to the process of taking program-internal object-related data, packaging it in a way that allows the data to be externally stored or transferred (“serialization”), then extracting the serialized data to reconstruct the original object (“deserialization”).
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Related Weaknesses
Consequences
Integrity: Modify Application Data, Unexpected State
Attackers can modify unexpected objects or data that was assumed to be safe from modification.
Availability: DoS: Resource Consumption (CPU)
If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate.
Other: Varies by Context
The consequences can vary widely, because it depends on which objects or methods are being deserialized, and how they are used. Making an assumption that the code in the deserialized object is valid is dangerous and can enable exploitation.
Potential Mitigations
Phase: Architecture and Design, Implementation
Description:
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.
Phase: Implementation
Description:
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.
Phase: Implementation
Description:
Explicitly define a final object() to prevent deserialization.
Phase: Architecture and Design, Implementation
Description:
Phase: Implementation
Description:
Avoid having unnecessary types or gadgets 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.
CVE References
- CVE-2019-12799
- chain: bypass of untrusted deserialization issue (CWE-502) by using an assumed-trusted class (CWE-183)
- CVE-2015-8103
- Deserialization issue in commonly-used Java library allows remote execution.
- CVE-2015-4852
- Deserialization issue in commonly-used Java library allows remote execution.
- CVE-2013-1465
- Use of PHP unserialize function on untrusted input allows attacker to modify application configuration.
- CVE-2012-3527
- Use of PHP unserialize function on untrusted input in content management system might allow code execution.
- CVE-2012-0911
- Use of PHP unserialize function on untrusted input in content management system allows code execution using a crafted cookie value.
- CVE-2012-0911
- Content management system written in PHP allows unserialize of arbitrary objects, possibly allowing code execution.
- CVE-2011-2520
- Python script allows local users to execute code via pickled data.
- CVE-2012-4406
- Unsafe deserialization using pickle in a Python script.
- CVE-2003-0791
- Web browser allows execution of native methods via a crafted string to a JavaScript function that deserializes the string.