Zip Slip, oportuno rebranding de una vieja vulnerabilidad

Se ha detectado la posibilidad de sobreescribir archivos arbitrarios, que suele permitir ejecutar código arbitrario, en múltiples proyectos software de envergadura

Sobreescritura de archivos arbitrarios al descomprimir un archivo conteniendo nombres de archivo que escalan directorios. Eso es todo. Pero ya sabemos que cualquier cosa vende más con un nombre pegadizo y un logo bonito. En este caso, los responsables de localizar esta vieja vulnerabilidad en múltiples proyectos importantes fueron los componentes del equipo de seguridad de Snyk, una empresa dedicada a encontrar y arreglar vulnerabilidades en dependencias software.

Técnicamente, la vulnerabilidad no es ninguna obra maestra, ni siquiera es nueva. Tiene gracia buscar ‘zip directory traversal’ en Google y encontrarse como primer resultado un repositorio de GitHub que permite generar un archivo para explotar esta vulnerabilidad. Actualizado por última vez hace 7 años. Y cuya descripción reza así (traducida del inglés):

La mayoría de los programas comerciales para zip (winzip, etc) impedirán la extracción de archivos zip cuyos archivos internos contengan rutas con caracteres que escalen directorios. Sin embargo, algunas librerías de desarrollo software no incluyen estos mismos mecanismos de protección (ej. Java, PHP, etc).

Volviendo al apartado técnico, la vulnerabilidad es bastante fácil de comprender si analizamos una de las líneas de código vulnerables en Apache Storm:

File file = new File(unzipDir, entry.getName());

Esta línea forma parte del código encargado de descomprimir un archivo ZIP. ‘file’ será un objeto que representa el archivo interno que está siendo extraído, pero tras la extracción, ‘unzipDir’ el directorio de destino para la extracción, y ‘entry.getName()’ devuelve la ruta dentro del ZIP del archivo que está siendo extraído. El constructor de la clase ‘File’ en Java (que es lo que se ejecuta con ‘new’ ahí) acepta dos parámetros en una de sus versiones: el primero es una ruta madre, y la segunda una ruta hija. Si leemos la documentación, simplemente dice que une la ruta madre y la ruta hija para crear el archivo, sin hacer referencia a validaciones de seguridad. Por tanto, ¿qué pasa si las rutas son las siguientes?

Madre: /tmp/decompressed_file/
Hija: ../../etc/passwd

Como recordamos, dos puntos seguidos en una ruta significa que retrocedemos un directorio, con lo que uniendo esas dos rutas terminaríamos extrayendo el archivo en ‘/etc/passwd’… El escenario de explotación más sencillo: un sistema que acepte y procese archivos ZIP, que los descomprima en un directorio temporal. No tiene que ser un único archivo, de hecho es un vector de ataque bastante bueno si no conoces el sistema, ya que puedes especificar múltiples archivos que afecten a distintas configuraciones.

Ahora que conocemos de qué va la cosa, pasamos a ver el por qué se da esto ahora. Tiene una explicación simple: hay múltiples lenguajes como JavaScript, Ruby, .NET, Go… pero especialmente Java, para los que no existen librerías estándares de manipulación de archivos comprimidos a alto nivel. Esto ocasiona que los interesados en disponer de esta funcionalidad terminen programándola ellos, de forma despreocupada por no ser un trozo de código especialmente divertido, introduciendo esta vulnerabilidad. Normalmente, si eres un programador de algo tan específico como una librería, conoces bastante bien el dominio del problema y contemplas este tipo de errores.

Uno de los imperativos en programación es “escribe tan poco código como puedas”, es decir, intenta tirar lo máximo posible de código existente, librerías, frameworks… Básicamente, “quien mucho habla, mucho yerra”, pero en el ámbito de la programación. Y además, si falla siempre puedes echarle la culpa a otro…

Ver información original al respecto en Fuente: