Cuando descomprimimos un archivo debemos llevar cuidado, ya que el resultado suele ocupar bastante más y puede dejarnos sin espacio en el ordenador. El ratio máximo de compresión de la mayoría de zips está marcado en 1032 a uno, aunque en muchas ocasiones tampoco se alcanza. Sin embargo, desde 1996 se tiene constancia de la existencia de las llamadas "bombas zip" o lo que se conoce popularmente como "el zip de la muerte". Un archivo que sobrepasa este límite de descompresión e inunda nuestro ordenador con miles de millones de bytes.
¿Cómo funcionan estos zips? ¿Por qué explotan a estos niveles y en qué se basan para que haya tanta diferencia? La respuesta la debemos obtener en la recursividad y superposición de archivos.
42.zip, un archivo de aparentemente solo 42 KB
Una bomba zip es un archivo comprimido como cualquier otro. Su potencial peligro está en que es muy fácil de esconder y compartir. Pero al descomprimir es cuando colapsa el ordenador al liberar una gran cantidad de datos.
El zip de la muerte más conocido es 42.zip, un archivo con un récord de compresión de 106.000 millones a uno. Su autor es desconocido, pero el ratio es impresionante. Estamos hablando de un archivo que pesa únicamente 42 kilobytes (de ahí el nombre) y que al descomprimirse puede alcanzar los 4.3 gigabytes. Pero la clave está en que el archivo contiene cinco capas, cada una con 16 archivos. Lo que en total una vez liberados todos ocupan un total de 4.5 petabytes.
Tal que así:
- 16 x 4294967295 = 68.719.476.720 (68GB)
- x 16 = 1.099.511.627.520 (1TB)
- x 16 = 17.592.186.040.320 (17TB)
- x 16 = 281.474.976.645.120 (281TB)
- x 16 = 4.503.599.626.321.920 (4,5PB)
El famoso archivo está disponible para descargar desde la página web del autor. Aunque no recomendamos a nadie que lo haga, salvo que dispongáis de los conocimientos necesarios para tratarlo con seguridad.
El formato zip tiene muchas variantes aunque con el paso del tiempo se ha convertido en habitual en sistemas operativos como Windows o MacOS. Parte de la razón de la existencia de estas bombas zip es debido al algoritmo que rige la descomprensión, que permite cambios tan grandes en el tamaño. Para hacernos una idea: un archivo comprimido sería por ejemplo "LOL x 10^12", pero al descomprimir sería "LOL, LOL, LOL...".
Nuevas bombas zip: de 46MB a 4.5PB
Durante años, estos zips de la muerte se han utilizado básicamente como una forma de malware, como por ejemplo para atacar sitios basados en Wordpress. Pero recientemente hemos visto nuevos estilos, más avanzados. Uno de ellos es la "bomba zip infinita", donde lo que hace el archivo es replicarse y crear copias de sí mismo. Otro de ellos, tal y como informa Vice, ha sido publicado recientemente por David Fifield.
El trabajo de Fifield es interesante porque ha creado un zip de la muerte con una filosofía diferente al de 42.zip. Mientras que el anterior logra un ratio impresionante a base de múltiples capas, en este caso tenemos únicamente un único archivo que al descomprimir explota. Una bomba zip no recursiva que establece el ratio en 28 millones a uno.
El autor nos ofrece tres archivos de ejemplo. El primero donde pasamos de 42kB a 5.5GB, un segundo de 10MB a 281TB y un tercero de 46MB a 4.5 Petabytes, este último únicamente compatible con el formato Zip64.
Pongámonos en el caso que descargamos el archivo de 46MB. Con 42.zip teníamos que descomprimir varias veces, pero aquí es solo una vez. Un simple proceso para colapsar por completo el ordenador. ¿Cuál es la diferencia? Fifield explica que en vez de apostar por la recursividad lo que ha hecho es solapar archivos.
Los antivirus sí las detectan
Afortunadamente para la seguridad de los usuarios, esta técnica de la bomba zip es bastante conocida desde hace muchos años. Pese a que el archivo comprimido pasa desapercibido en el sistema, una vez vamos a descomprimirlo es cuando los antivirus lo detectan como un posible peligro y nos advierten antes de iniciar el proceso.
El zip de la muerte no está catalogado como un malware propiamente dicho. Pese a eso, en el caso de 42.zip detectan que hay múltiples capas por lo que puede ser dañino. Adicionalmente, como explica el investigador de seguridad de Google, Tavis Ormandy, las nuevas bombas zip no recursivas también son detectadas.
Otros ataques que colapsan el sistema con explosiones de datos
La idea detrás del zip de la muerte es similar al de otros ataques. Se trata de colapsar al sistema u ordenador en base a una gran cantidad de datos que no pueden procesar. Algunos ejemplos de este tipo de ataques serían por ejemplo los DDoS (Distributed Denial of Service). Uno muy conocido y similar en concepto sería el de "Mil millones de risas", basado en XML y donde se repite exponencialmente el uso de la palabra "LOL" al cargar el código.
Sin tratarse de ningún gusano o virus, otro ataque similar es la 'bomba fork' o 'wabbit'. En este caso, es un archivo que crea copias de sí mismo (como conejos). Una técnica de la que los usuarios de Linux tampoco se libran, ya que también funciona con archivos TAR.
En Xataka | Cómo evitar que los ZIP se muestren como carpetas en Windows
Ver 25 comentarios
25 comentarios
black_ice
Aclarando las dudas que comenta la gente:
"antes de descomprimir ves el tamaño del archivo comprimido o el número de ficheros que hay. En este caso no es así? "
La información del tamaño sin comprimir viene en los metadatos del archivo ZIP, y la introduce el sistema que comprimió el archivo originalmente. Por lo que es trivial que tu hagas tu propio programita que comprima un archivo pero introduzca metadatos falsos con valores incorrectos. Así que el receptor abrirá el archivo, te mostrará que pesa X bytes descomprimido, y al descomprimirlo en realidad pesará mucho mas.
"Tampoco te salta un aviso que no hay suficiente espacio en el disco duro?"
Puede que haya una alarma que le indique a un usuario que el disco se está llenando (si hablamos de un ordenador portátil o de sobremesa), pero eso no impide que se llene pues el proceso de descompresión seguirá adelante igualmente.
"porque yo pensaba que para comprimir un archivo se debían disponer de los datos a comprimir. "
No necesariamente. Imagínate que tienes un formato de compresión que comprime las letras que encuentra consecutivamente, y funciona así: En lugar de guardar las letras, guarda una letra y un número al lado, de tal manera que:
- Esto -> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", se convertirá en "a30"
- Esto -> "bbbbbbbbbbbb". se convertirá en : "b12"
- Esto -> "ccc" se convertirá en "c3"
etc.
Así que si sabes como funciona el algoritmo, para crear un fichero que tenga un millón de 'A', no hace falta tener el fichero original, simplemente creas un fichero con la extensión de comprimido (.zip, .tar o en este caso el del hipotético algoritmo), y dentro pones "A1000000", con lo que el programa receptor recreará el fichero "original" con un millón de letras 'A'.
En el caso de ZIP el algoritmo es evidentemente mas sofisticado, pero el principio es el mismo: creas directamente el formato comprimido que sabes que producirá un fichero descomunal en la salida.
biturrizar
He entrado al bloc de notas, he escrito la letra A y a base de copiar y pegar, en varias etapas he alcanzado un tamaño de 2 GB. Al comprimir con 7zip ha quedado en 300 KB. O sea el factor ha sido de 7000.
Djinn Hache
Hace unos días llené de datos un servidor en producción y, obviamente, dejó de funciar. Sólo podía acceder por consola y averiguar dónde estaba todo ese espacio. El problema es que cuando no hay ni un byte libre, hay, comandos que no puedes ejecutar. Nisiquiera puedes darle al tabulador para completar rutas...
En fin, que al final era una consulta SQL mal hecha que había generado un archivo "temporal" de 120GB (no era más grande porque se quedó sin espacio xD)
rennoib.tg
Me recuerda a cuando me aburría en programación y me dio por aprender a hacer un programa que generada documentos de texto, entonces vino la pregunta de y si en vez de cerrar el programa lo vuelvo a abrir y reescribir. Hoy en día un ordenador no se vería muy afectado pero los de clase cuando tras 5m minutos de estar ejecutado llevaban archivos de varios gb, si que se petaban jajaja. Por fortuna, se encendían ejecutando una misma imagen protegida , luego te podías cargar cualquier cosa y volverlos a encender como si nada, algo que debería ser obligatorio en los colegios e institutos.
Akenatón 2013
No sé dónde está el peligro, al ordenador no le va a pasar nada, solo se va a llenar el disco duro al máximo. Cosa que me parece interesante cuando quieres estar seguro de borrar para siempre archivos que ya fueron eliminados, y que de esta forma te aseguras de que se sobreescriban. Me lo voy a bajar porque me puede ir bien en un momento determinado.
tecnoman
Pero, ¿que tipo de archivos hay dentro, texto, imágenes...?
OrangeMg
Para probarlo en una máquina virtual con almacenamiento fijo; "a ver qué sucede".
Guybrushh
Si es tan sencillo generar archivos tan grandes porque muchos videojuegos o películas no vienen comprimidos en varias capas?
osesno89
Desde la ignorancia, antes de descomprimir ves el tamaño del archivo comprimido o el número de ficheros que hay. En este caso no es así? Tampoco te salta un aviso que no hay suficiente espacio en el disco duro?
andrusdiaz1
Mi ManjaroKDE amo este archivo, no se inmuta. Pero Llene mi disco d e respaldo :( . Claro no pude descomprimir todo solo lo que entraba
robertgarcia2
Las bombas fork...es fácil de escribir una para Windows o Linux
nessness
Voy a tener más cuidado al bajar subtitulos....
Me recuerda a los Snapcraft de Linux, un simple programa te ocupa varios gigas.
rubencardenalnino1
Los archivos no "pesan", los archivos "ocupan". El byte no es una unidad de masa.