Dirtycow

Cómo usar dirtycow

Un fallo en el parche original de la conocida vulnerabilidad Dirty COW podría permitir a un adversario ejecutar código local en los sistemas afectados y explotar una condición de carrera para realizar un ataque de escalada de privilegios.

El fallo en el parche Dirty COW (CVE-2016-5195), publicado en octubre de 2016, fue identificado por investigadores de la empresa de seguridad Bindecy. El miércoles, publicaron detalles de la vulnerabilidad (CVE-2017-1000405) encontrada en el parche original de Dirty COW, que afecta a varias distribuciones de Linux.

“En términos de alcance, la diferencia es solo que el fallo actual no es aplicable a Android y Red Hat Enterprise Linux. Todas las demás distribuciones – Ubuntu, Fedora, SUSE – sufren el problema. Por lo tanto, el alcance sigue siendo grande. Estimamos que millones de máquinas son vulnerables”, dijo Daniel Shapiro, investigador de Bindecy, al que se atribuye el descubrimiento del fallo junto con su colega Eylon Ben Yaakov.

Red Hat Software notificó a los clientes el parche defectuoso el jueves, señalando que el problema no afecta a los paquetes del kernel de Linux tal y como se suministran con Red Hat Enterprise Linux 5, 6, 7 y Red Hat Enterprise MRG 2, según el portal de clientes de Red Hat.

Dirtycow github

Dirty COW (CVE-2016-5195) es una vulnerabilidad de escalada de privilegios en el Kernel de Linux, que permite a un usuario local sin privilegios obtener acceso de escritura a mapeos de memoria que de otro modo serían de sólo lectura, y así aumentar sus privilegios en el sistema.

La vulnerabilidad recibe el nombre de Dirty COW porque el problema se debe a una condición de carrera en la forma en que el kernel maneja la copia en escritura (COW), una estrategia de optimización utilizada en la programación informática. La idea fundamental es que si varios llamantes piden recursos que son inicialmente indistintos, se les puede dar punteros al mismo recurso. Esta función puede mantenerse hasta que un llamante intente modificar su “copia” del recurso, momento en el que se crea una verdadera copia privada para evitar que los cambios sean visibles para todos los demás. En este caso, la implementación de copy-on-write se rompe, por lo que los programas pueden terminar en una condición de carrera y permitir que un usuario sin privilegios altere los archivos propiedad de root y los ejecutables setuid.

Una versión del kernel de Linux desde la 2.6.22 está afectada por esta vulnerabilidad. Se puede utilizar un script de detección para determinar las versiones vulnerables del kernel en Red Hat Enterprise Linux y CentOS. La vulnerabilidad se aborda en las versiones del kernel de Linux 4.8.3, 4.7.9 y 4.4.26 y Ubuntu, Redhat y Debian han publicado parches.

Ejemplo de explotación de Dirtycow

La buena noticia es que para cuando estés leyendo esto, todas las principales distribuciones de Linux tendrán parches disponibles para sus diferentes núcleos, así que es simplemente cuestión de ejecutar una actualización a través de tu gestor de paquetes y reiniciar tu servidor.

Este proceso debería durar unos minutos, pero aún no estamos fuera de peligro. Actualiza la página en unos minutos y deberías ver que ha aparecido la siguiente sección, mostrando que hay servidores que necesitan reiniciarse para utilizar el parche que acabas de aplicar:

De nuevo, selecciona los servidores que quieres reiniciar y elige en el desplegable Reboot selected now o Reboot selected at set time. Si lo haces a una hora determinada, introduce una hora y pulsa Programar reinicio para ponerlo en marcha.

Dirtycow c

La página de DirtyCOW PoC contiene una lista de pruebas de concepto de exploits, incluyendo varios que no requieren GCC. Hay uno escrito en Go e incluso uno que sólo requiere un ensamblador. También puedes analizar cómo funciona el exploit e implementarlo tú mismo en cualquier lenguaje que tengas disponible.

A menos que me esté perdiendo algo… ¿simplemente compilarlo en otra máquina y copiarlo? Aunque si no tienes acceso a un sistema con un compilador compatible entonces supongo que ESE es tu problema. No necesitas estrictamente gcc en el objetivo.