Desde Hispasec nos llega la importantisima noticia de que se han publicado dos exploits y una prueba de concepto para la una vulnerabilidad en el kernel Linux que podría permitir a un atacante local elevar privilegios a root.
La vulnerabilidad afecta a los kernel Linux posteriores a la versión 3.4. El error fue introducido en la función ‘compat_sys_recvmmsg’ en el archivo ‘/net/compat.c’ al agregar código para manejar estructuras de tiempo de 64 bits.
Básicamente, el fallo consiste en una ausencia de verificación en cierta estructura pasada desde el área de usuario como argumento a la función
‘__sys_recvmmsg’. Esta función terminará por usar la estructura pasada a espacio del kernel sin ningún tipo de comprobación. Si observamos el código del commit:
En primer lugar vemos como la función ‘compat_sys_recvmmsg’ recibe en uno de sus parámetros (el último) un puntero a una estructura ‘timespec’. Dicho parámetro está marcado por la macro ‘__user’ que indica que dicho parámetro procede del área de usuario.
Posteriormente vemos como si está definido ‘COMPAT_USE_64BIT_TIME’ dicho parámetro es usado en la llamada a la función ‘__sys_recvmmsg’. Ahí está
el problema, y es grave. Jamás se debería acceder a la memoria del kernel desde el espacio de usuario y no filtrar previamente dicha estructura es lo que hace precisamente la función vulnerable.
Tal y como señalan en la lista oss-security (de lectura altamente recomendable) http://seclists.org/oss-sec/2014/q1/187 uno de los parches propuestos filtra dicho parámetro a través de la llamada a la función ‘copy_from_user’ para comprobar si las referencias a memoria se están haciendo al espacio de usuario en vez de a la memoria del núcleo o si tiene capacidad para lectura/escritura. En dicho caso se provocaría un fallo y se devolvería el error -EFAULT.
Vemos parcialmente el parche aquí y observamos las llamadas a la función comentada y a su homónima ‘copy_to_user’ cuando la operación es a la inversa:
En principio la vulnerabilidad afecta a los kernel Linux desde la versión 3.4, aunque ha de estar definida la opción ‘CONFIG_X86_X32’. Esto podemos comprobarlo en el archivo de configuración de arranque (en algunas distribuciones):
/boot/config-* (donde * es la versión del kernel que podemos ver también haciendo uname -r)
Como curiosidad lo que esta opción permite es tener la capacidad de ejecutar binarios que usen punteros de 32 bits ejecutándose en arquitecturas de 64bits. (http://en.wikipedia.org/wiki/X32_ABI)
Más información:
Exploit 1
http://www.exploit-db.com/exploits/31346/
Exploit 2
http://www.exploit-db.com/exploits/31347/
PoC
http://www.exploit-db.com/exploits/31305/
Fuente: Hispasec – Una al dia
¿Te resultó interesante? Compártelo ...
La seguridad es un tema frágil en cualquier sistema.
En reiteradas ocasiones hemos visto las ventajas de un kernel al edge, pero estos son algunos de los problemas que traen andar tan «actualizados». También veo como un problema que algunos de estos no están tan actualizados 3.4-3.7(algunos tienen más de un año), creo que a Linus(sé que no es exclusivamente su trabajo) le daría un consejo parecido al que le daría a Canonical, no lancen tantas versiones y denle robustez a las que tienen, están enfermos de «versionitis» y de paso nos tienen enfermos a nosotros.
Saludos
Linus es solo el supervisor final, pero imagínate si se pone a publicar actualizaciones solo una vez al año o algo así, con la cantidad de mejoras (mejoras importantes) que hay en cada actualización del kernel. NO, la frecuencia de actualizaciones está bien, eso creo yo.
Por otro lado cuando sale una noticia sobre cierta vulnerabilidad, seguro hay alguien que está a punto de publicar la solución.
por lo general es el mismo que la detecta el que la corrige o al menos el que propone la corrección, a nadie le cuadra que haya vulnerabilidades en el kernel, pero es que estas aparecen cuando pasa el tiempo porque el código viejo queda obsoleto muy rápido. Esta vulnerabilidad que dicen en el artículo no estaba presente en sistemas de 32 bits, es al pasar a 64 bits que se convierte en vulnerabilidad. Lo bueno es que sabemos que se corrigen.
Linux R2D2 3.12.9-1-ARCH
Ese es mi Kernel en estos momentos. Dudo mucho, pero mucho, que esta vulnerabilidad ya no haya sido corregida y parcheada.
OT: R2D2? nerd! mira el mío: Linux Jarvis 3.11.0-17-generic XD
Bahhh, de seguro ya en el 3.13 ni sombra de esa vulnerabilidad
Jajaja.. Jarvis, lo pensé, pero no, demasiado gastado.. y no he visto a nadie con R2D2 😛
Igualito a como Microsft documenta sus vulnerabilidades…¿no creen?
Que viva la libertad!!!!
Compat_use_64_BIT_TIme , o sea afecta a la memoria eeprom.
https://owasp.org/index.php/Discusi%C3%B3n#Congelando_el_kernel_de_Linux_y_Windows
Tengo el 3.12-1-amd64… No sé que es una vulnerabilidad… ❓
Hola linuXgirl, una vulnerabilidad es una brecha de seguridad que puede ser explotada por: malware polimórfico, troyanos, gusanos, xploits remotos, programas de fuerza bruta. Alguna vez un amigo veterano me dijo que en la comunidad linux una vulnerabilidad o error era reparado en 48 horas.
Aunque recientemente se descubrió que tardaron 23 años en descubrir una saturación de búffer en el X11. Saludos
Gracias, Franz, por la explicación, pero mi supuesta «ignorancia» solo fue una especie de ironía de mi parte. 😉
La vulnerabilidad se repara no en 48 horas sino en menos de 24 cuendo es detectada, si no es detectada como puedes repararla???
Tu amigo sigue teniendo la razón