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...
Más
información:
·
Zip
Slip Vulnerability https://snyk.io/research/zip-slip-vulnerability
·
Zip
Slip Vulnerability (Arbitrary file write through archive extraction) https://github.com/snyk/zip-slip-vulnerability
Fuente: Hispasec.com
