CVE-2017-4995 in Spring Security
Summary
by MITRE
An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known "deserialization gadgets." Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security's Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) "deserialization gadget" that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown "deserialization gadgets" when Spring Security enables default typing.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 12/10/2019
The vulnerability described in CVE-2017-4995 represents a critical deserialization flaw within Pivotal Spring Security versions 4.2.0.RELEASE through 4.2.2.RELEASE and Spring Security 5.0.0.M1. This issue stems from the improper configuration of Jackson's deserialization mechanism, specifically when default typing is enabled. The vulnerability operates at the intersection of application security and serialization frameworks, creating a pathway for remote code execution through maliciously crafted data. The flaw is particularly concerning because it leverages the Jackson library's default typing feature, which allows for automatic type resolution during deserialization, creating an attack surface that can be exploited by adversaries who control serialized data.
The technical implementation of this vulnerability involves Jackson's default typing mechanism being enabled within Spring Security's configuration, which creates an environment where untrusted data can be deserialized with full type information. This configuration allows attackers to specify arbitrary classes during deserialization, potentially leading to code execution when combined with malicious payloads. The vulnerability is classified under CWE-502 as Deserialization of Untrusted Data, which specifically addresses the risks associated with deserializing data from untrusted sources. When Jackson's default typing is enabled, it effectively removes the sandboxing that would normally prevent arbitrary class loading, making the system susceptible to exploitation through known deserialization gadgets that can be found on the classpath.
The operational impact of this vulnerability extends beyond simple code execution, as it can enable attackers to perform complete system compromise through various attack vectors. The vulnerability requires specific conditions to be exploited, including the explicit use of Spring Security's Jackson support modules and the presence of untrusted data being deserialized through Jackson. This means that the vulnerability is not automatically exploitable but requires an attacker to have control over the data being deserialized and to be able to influence the application's configuration. The attack chain typically involves identifying a deserialization gadget that can be loaded through the classpath, which then executes arbitrary code when the malicious payload is processed by Jackson's deserialization mechanism.
From an ATT&CK framework perspective, this vulnerability maps to several techniques including T1059.007 for command and script interpreter execution and T1133 for external remote services. The attack surface is particularly dangerous because it allows for privilege escalation and lateral movement within the application environment. Organizations using affected Spring Security versions are at risk of complete system compromise when untrusted data is processed through Jackson deserialization, especially in applications that handle user input or external data feeds. The vulnerability demonstrates the importance of secure coding practices around serialization and deserialization, particularly when dealing with third-party libraries that have complex type resolution mechanisms.
The recommended mitigations for this vulnerability include disabling default typing in Jackson when it's not explicitly required, implementing proper input validation and sanitization for all deserialization operations, and ensuring that only trusted data is processed through Jackson's deserialization mechanisms. Organizations should also consider implementing additional security controls such as classloader restrictions and monitoring for suspicious deserialization patterns. The fix requires explicit configuration changes in Spring Security to disable default typing or to properly configure Jackson's security settings, which aligns with the principle of least privilege in security design. Additionally, regular security assessments should be conducted to identify and remove potential deserialization gadgets from application classpaths, as this vulnerability highlights the need for proactive security measures rather than reactive patching approaches.