Escuché sobre VACA sucia pero no pude encontrar ningún informe decente sobre el alcance del error. Parece que el exploit puede sobrescribir cualquier archivo no grabable, lo que me hace suponer que la raíz local es posible mediante la sustitución de programas SUID. ¿Está bien? ¿Qué más sabemos acerca de Dirty COW? ¿Es posible explotarlo de forma remota? ¿Afecta a Android?
No se puede explotar de forma remota sin otra vulnerabilidad. Necesitas poder ejecutar comandos en el sistema ya.
Un ejemplo clásico sería un shell web. Digamos que el servidor está ejecutando una aplicación web que tiene una vulnerabilidad que le permite cargar un shell web o ejecutar comandos del sistema. Estos comandos normalmente se ejecutarán como un usuario con pocos privilegios, a veces llamado www-data o similar.
Con esta vulnerabilidad, podría sobrescribir el archivo /etc/passwd para dar a www-data el UID 0. Ahora www-data tiene privilegios de raíz.
Sin embargo, probé algunas cosas y la modificación de /etc/passwd no funcionó en mi sistema. Puede establecer el UID de un usuario en 0, pero luego tendrá que volver a iniciar sesión, lo que no es realmente una opción si solo tiene un shell web. El exploit mejor armado que he visto hasta ahora sobrescribe /usr/bin/passwd , el binario que se usa para cambiar la contraseña de un usuario y tiene el bit SUID establecido, con código de shell que ejecuta /bin/bash . Algunas limitaciones de la vulnerabilidad parecen ser: Solo puede sobrescribir los bytes existentes, no agregar nada a un archivo. Tampoco pude escribir más de exactamente 4 KB en un archivo.
En cuanto a afectar a Android, busqué en Android 4.4 git repo para la función en pregunta ( follow_page_pte ) y no obtuve resultados, por lo que quiero decir "no", pero no me cites al respecto.
Editar: Android está afectado: consulte esta prueba de concepto .
La vulnerabilidad de la vaca sucia, es una vulnerabilidad de escalada de privilegios en las versiones del kernel de Linux 2.6.22 y superior; ha existido desde 2007 y se fijó el 18 de octubre de 2016.
¿Cuál es el posible impacto del error dirtyc0w?
Un usuario local sin privilegios podría usar esta falla para obtener acceso de escritura a las asignaciones de memoria de solo lectura y, por lo tanto, aumentar sus privilegios en el sistema.
Esta falla permite que un atacante con una cuenta del sistema local modifique los archivos binarios en el disco, omitiendo los mecanismos de permisos estándar que evitarían la modificación sin un conjunto de permisos adecuado.
¿Es posible explotarlo de forma remota?
no es directamente explotable de forma remota; primero necesita otra falla para darle acceso remoto al sistema , como se indica en @IMSoP en su comentar,
está clasificado como un importante error:
Impacto importante
Esta calificación se otorga a fallas que pueden comprometer fácilmente la confidencialidad, integridad o disponibilidad de los recursos. Estos son los tipos de vulnerabilidades que permiten a los usuarios locales obtener privilegios, permitir que los usuarios remotos no autenticados vean los recursos que de otra forma deberían estar protegidos por la autenticación, permitir que los usuarios remotos autenticados ejecuten código arbitrario o permitir que los usuarios remotos denieguen el servicio. / p>
¿Afecta a Android?
Sí, porque Android usa el kernel de Linux.
Si tienes algún dispositivo que ejecute un kernel de Linux superior a 2.6.22, es muy probable que seas vulnerable. Lo mismo ocurre con todas las versiones de Android, ya sean de Samsung, Google, Cyanogen, MIUI u otros proveedores porque aún no han emitido actualizaciones de seguridad.
Para aprovechar esta vulnerabilidad, el atacante debe ejecutar el código en el dispositivo afectado, que en el caso de Android se puede hacer a través del Android Debug Bridge (ADB) a través de USB o instalando una aplicación que haga uso del exploit.
Actualizar
Un buscador de seguridad describe en este blog cómo explotar la falla de forma remota
Las vulnerabilidades se pueden usar contra los proveedores de alojamiento web que proporcionan acceso a la shell, para que un cliente pueda atacar a otros clientes o incluso a los administradores de servicios. Los exploits de escalamiento de privilegios también se pueden combinar con ataques dirigidos a otras vulnerabilidades. Una debilidad de inyección de SQL en un sitio web, por ejemplo, a menudo permite que los atacantes ejecuten código malicioso solo como un usuario no confiable. Sin embargo, combinados con un exploit de escalado, tales ataques a menudo pueden alcanzar un estado de raíz altamente codiciado.
Se puede encontrar información útil aquí :
CVE-2016-5195 es un llamado exploit de escalado de privilegios. Le permite elevar el nivel de privilegio de un usuario normal de Linux a la raíz. Pero las explotaciones de escalada de privilegios suelen ser explotaciones locales (lo que significa que se ejecutan localmente en una caja), lo que significa que ya debe iniciar sesión en el sistema operativo.
El exploit público que estaba revisando permite escribir archivos que son propiedad de root y que son de solo lectura o no son accesibles para usuarios que no son root. Esto le permite sobrescribir archivos administrativos. Puedes aprovechar esto para convertirte en root. P.ej. puedes agregar una linea
hack::0:0:,,,:/home/kai:/bin/bash
a /etc/passwd . Esto agregaría un usuario root sin contraseña al cuadro.
Al menos afecta a Android 5.0.1 (versión del kernel 3.10.54+). Acabo de probar este código en un dispositivo usando Termux y editar un archivo propiedad de root funciona perfectamente. Me gusta eso, porque no hay una raíz disponible para ese dispositivo.
Por otra parte, me sorprende, ya que Android usa SELinux y pensé que SELinux evitaría escribir en /proc/self/mem .
En realidad, acabo de intentar escribir en un archivo que pertenece a un usuario llamado sdcard , que posee todos los archivos en la tarjeta SD. Termux en sí (normalmente) no está permitido escribir en la tarjeta SD. Cuando pruebo dirtyc0w en dicho archivo, el dispositivo simplemente se bloquea y se reinicia automáticamente después de unos segundos. Incluso adb logcat no genera nada durante este bloqueo. No estoy seguro de lo que está pasando allí.
En principio, una escalada de privilegios es bastante aterradora, ya que más o menos hace que todo control de acceso no tenga sentido. En la práctica, es de esperar que importe poco. Primero debes tener acceso limitado de usuarios.
Para los servidores, significará que los sistemas de servidores no tan bien mantenidos que son algo explotables ahora serán trivialmente rooteados. Sin embargo, no es como este es el primer exploit de escalado de privilegios en la historia.
Para sistemas bien mantenidos, el impacto debería ser cercano a cero (no deberían haber sido explotados hasta el momento y deberían estar actualizados hasta ahora).
Para todos los teléfonos con Android anteriores a la 7.0, desafortunadamente significa que existe una vulnerabilidad que podría permitir que una aplicación maliciosa se haga cargo del teléfono. Ese es un pensamiento extremadamente aterrador, pero no parece que haya ocurrido hasta ahora, o habría pánico, caos y asesinatos en todo el planeta. Las actualizaciones automáticas eliminarán este problema rápidamente y, mientras tanto, no instale nuevas aplicaciones (las aplicaciones ya presentes en su teléfono durante muchos meses, obviamente no secuestraron su teléfono, por lo que probablemente inofensivo) ... problema resuelto.
También hay otra forma de desbloquear tu teléfono (hasta la próxima actualización del sistema, al menos).
Obviamente, también significa que alguien con acceso físico a su computadora y una cuenta de usuario puede rootear su sistema ... pero también podrían agarrar su computadora y llevársela, robar el disco duro o usar Firewire / Thunderbolt que son básicamente acceso directo a la memoria por cable, arranque desde un CDROM, o ... 200 otras cosas, así que no creo que este sea un gran problema en general. Es solo otra cosa que alguien puede hacer.
Dado que este es el segundo incidente de larga data y de alto perfil (después de CVE-2008-0166) en el que un responsable de seguridad ha creado un problema de seguridad que podría decirse que es "¿qué me importa?" problema, espero que el mayor impacto que esto tendrá reabra una discusión sobre el proceso de ingeniería.
El mayor problema sobre esta vulnerabilidad es, en mi opinión, que se identificó y solucionó en 2005 (cuando era simplemente un problema teórico con una baja probabilidad de ocurrencia), pero luego se revertió porque causó un problema en algunos IBM Serie de mainframe de principios de la década de 1990 de la que pocas personas han oído hablar. Que, francamente, al 99% de todos los usuarios de Linux no les importaba menos, y lo que podría haber sido hecho por un parche / arreglo dependiente del sistema solo para s / 390. Pero eso no sucedió, y el problema se desvaneció hasta 11 años después.
Esto es muy similar a la introducción de 2008-0166 donde alguien editó el código (que funcionó correctamente) sin entender las implicaciones, solo porque Valgrind mostró una advertencia.
Tal vez, esto ayudará a crear más conciencia de la importancia de que los mantenedores comprendan cuáles son las implicaciones exactas de un cambio de código para la gran mayoría de los usuarios, y una evaluación general más crítica (¿con revisión por pares?) sobre los cambios de código puede evolucionar . Con suerte, eso es.
The Guardian parece decir que es un SÍ, pero parece que depende de la variante de Android en cuestión:
Eso también se aplica a Android: el sistema operativo móvil está afectado. Si bien los dispositivos Android de gama alta, como el Galaxy S7 y Pixel, reciben actualizaciones de seguridad regulares, la gran mayoría de los dispositivos Android vendidos reciben pocas actualizaciones posteriores a la venta, si es que las hay.
Google no quiso hacer comentarios, pero confirmó que Android es una de las distribuciones de Linux afectadas. La compañía ha publicado un Asesor de seguridad para socios para alertar a los socios de Android, uno de los pasos para que esos socios emitan un parche.
El error permite a un atacante que puede ejecutar código arbitrario para escribir en la memoria que es "solo lectura". Los cachés de Linux a menudo utilizan archivos en la memoria de solo lectura. Como ha adivinado, esto le permite hacer cosas como cambiar el contenido de un archivo root de setuid para ejecutar código arbitrario, como un shell, como root.
El error en sí mismo no se puede explotar de forma remota, ya que requiere que el atacante ejecute un archivo ejecutable específico creado por el atacante. Normalmente, cuando usamos las palabras "de forma remota explotable", no requiere la capacidad de ejecutar código arbitrario.
Sin embargo, hay situaciones en las que un atacante ya puede ejecutar código arbitrario por diseño que no es tan obvio como el acceso ssh. Esta puede ser la razón de la confusión, ya que no siempre es obvio que un atacante tiene privilegios de ejecución de código. Potencialmente, los entornos de compilación automatizados compartidos pueden ser vulnerables a este tipo de explotación, ya que a menudo permiten que el desarrollador ejecute código arbitrario. Un atacante en este escenario podría potencialmente obtener privilegios de root.
No creo que esté calificado para responder si este error se puede explotar en Android. Si es explotable en Android, el alcance probablemente se limitaría a que el propietario del teléfono pueda "rootear" el dispositivo, en lugar de que un atacante remoto obtenga el control del teléfono.
Lea otras preguntas en las etiquetas exploit linux known-vulnerabilities kernel dirty-cow