En http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c, el mismo paisano que ha programado el exploit ha programado la forma de deshabilitar vmsplice en el código del kernel que se está ejecutando en memoria, y así eliminamos la vulnerabilidad de momento, hasta que cambiemos nuestro kernel a uno nuevo que no tenga esta vulnerabilidad.

$ wget http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c
$ gcc disable-vmsplice-if-exploitable.c -o disable-vmsplice-if-exploitable
$ sudo ./disable-vmsplice-if-exploitable
Password:
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
Exploit gone!
$

Ejecutamos ahora de nuevo el exploit (cuyo fuente lo he llamado exploit-vmslice.c y el binario exploit-vmslice) y comprobamos que ya no conseguimos acceso root

$ ./exploit-vmsplice 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e3c000 .. 0xb7e6e000
[-] vmsplice
$

Como comenté arriba, este parche actúa sobre la memoria, no sobre el código que se carga cuando el sistema se inicia, por tanto al reiniciar la máquina vuelve a ser vulnerable. La solución temporal es ejecutar este parche en el script de inicio del sistema.

Otra opción es parchear el fuente de splice.c (que es donde está el fallo) con el diff publicado en http://www.alu.ua.es/j/jgl14/patch-vmsplice-2.6.24.1.diff.gz y recompilar e instalar el nuevo kernel.

¿Te ha gustado? - Digg Me! | Add to del.icio.us! | reddit this!