Me pasa mi amigo Pas la dirección a la página de picotux, un servidor web que tiene prácticamente el tamaño de un conector RJ-45, y que lleva embebido un kernel Linux 2.4.27.

Es curioso que cuando alguien se plantea prescindir de lo superfluo al diseñar un ordenador no prescinda de Ethernet, de hecho, ¡casi ocupa tanto espacio la etiqueta que indica la dirección MAC que la propia máquina!

No se si se han dado cuenta, pero Ethernet es la red universal desde hace mucho tiempo. TCP/IP se está convirtiendo gradualmente en un nivel de abstracción, casi en una ficción, que permite pedir servicios a la red subyacente, que siempre es Ethernet. Los "cores" de las redes de las operadoras hace tiempo que no son un conjunto de routers de nivel 3 que encaminen paquetes, sino un conjunto de switches que conmutan tramas de nivel 2. El problema es que aún conmutan usando el clásico algoritmo transparent bridging, que se basa en tablas en memoria, pero cuando se dé el paso definitivo hacia una ethernet de direcciones jerárquicas y las tramas de nivel 2 puedan viajar por sí mismas de un lado a otro del planeta sin depender de un routing de nivel 3, TCP/IP habrá muerto definitivamente como protocolo de red de nivel 3/4 y se habrá convertido en lo que es su sitio natural en la actualidad, en un API de servicios de red para aplicaciones.

En este escenario que acabo de describir, un usuario pediría un servicio al API de TCP/IP, por ejemplo, una página web, y dicha petición se materializaría en un paquete que se encapsularía en una trama Ethernet que viajaría al destino mediante switching y que sería interpretada en destino mediante eliminar los cabeceros de nivel 2 para que vuelva a aparecer la petición al servicio web que estaría, como es natural, en el socket con puerta 80 de la máquina destino. El funcionamiento, por tanto, sería el mismo que actualmente, con la diferencia de que TCP no habría hecho ningún control de integridad del paquete ni ninguna retransmisión caso de ser necesaria, e IP no habría hecho ningún trabajo de encaminamiento. Dado que hemos eliminado todo ese trabajo innecesario, la trama se habría podido desplazar por la red a la velocidad que marque el medio físico, y no a la velocidad que impone el control por software que actualmente estrangula los anchos de banda.

Las consecuencias de mantener actualmente a TCP/IP como protocolo de comunicaciones es que el rendimiento de las máquinas no escala tanto como el ancho de banda que Ethernet les hace disponibles. Pronto tendremos Ethernet a 100 Gbps y TCP/IP sigue sin poder subir de un rendimiento de 1Gbps, o lo hace a costa de múltiples CPUs y de más consumo energético, algo ilógico cuando se piensa que lo mismo se hace con mucha más eficacia y economía por hardware.

Cito literalmente del la revista IEEE Computer de Noviembre de 2004:

Our recent measurements on state-of-the-art platforms show that TCP/IP 
processing of application data (a full frame payload size of 1,460 bytes) 
consumes one entire current generation CPU to achieve roughly 750 Mbps of 
throughput while receiving data and around 1 Gbps of throughput while 
transmitting data. Clearly, it currently is not possible to achieve a 
tenfold increase in TCP/IP throughput. 

The major impediment to achieving 10-Gbps throughput is that CPU and 
memory speeds are not expected to improve as dramatically as Ethernet 
technologies.

El gran coste que tiene evaluar una ruta IP por software con las tablas de enrutamiento en comparación con el mínimo coste de evaluar una ruta por hardware que es posible hacer en una Ethernet que use direcciones jerárquicas, sumado al hecho de que comprobar la integridad de un paquete TCP con checksum es muchísimo más costoso que hacer un CRC por hardware de una trama Ethernet debería de ser un argumento más que convincente para plantearse en serio la transformación de TCP/IP en un API.

No mucha gente se lo plantea, pero ya hace tiempo que no se comprende que TCP/IP siga siendo un protocolo de comunicaciones, con sus controles de errores y restransisiones, en lugar de convertirse en lo que NetBIOS fue para NetBEUI, un nivel de abstracción que pide servicios a un protocolo de red subyacente, y así dejar que sea Ethernet quien haga la verificación de la integridad de los datos, e incluso los servicios de circuito virtual permanente que hace TCP en la actualidad. Desgraciadamente hay tan poco conocimiento sobre Ethernet que casi nadie (excepto el Ethernet Forum liderado por José Morales) se ha dado cuenta de que Ethernet debería de ser el protocolo de red y TCP/IP está ya en un lugar donde estorba más de lo que ayuda.

Y otro problema más: en los "cores" de la red que manejan las operadoras ya estamos llegando al punto en el que las tablas de switching que tienen los conmutadores son un lastre, porque el tiempo de acceso a la memoria para consultar por dónde soltar una trama es demasiado grande en comparación con el tiempo que el conmutador tiene para despachar la trama, que es cada vez mayor al aumentar la velocidad del medio físico.

Cualdo alguien escucha esto por primera vez suele comentar: "pero si no se puede enrutar Ethernet, porque es un protocolo que solo sirve para redes de área local, ¿cómo vamos a poder sustituirlo con TCP/IP, que está diseñado específicamente para ser enrutado e interconectar equipos separados por routers?".

Pues aquí es donde entra UETS, la red Ethernet de direcciones jerárquicas, conmutable por hardware, sin tablas en memoria. Pero de esto ya escribiré otro día.

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

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!

Después de que Linus Torvalds llamara incompetent idiots a la gente de FreeBSD por no implementar vmsplice() en su kernel y hacerlo mediante COW (copy-on-write), ahora parece que tendrá que morderse la lengua por haber introducido en todos los kernel superiores a 2.6.17 junto con vmsplice() un bug muy fácil de explotar, tanto que ya está el fuente del exploit (en Kriptópolis, por ejemplo) que cualquiera puede bajarse y compilar.

Este bug permite a un usuario hacerse root sin tener que dar ninguna contraseña. La versión del kernel 2.6.24.2, disponible en kernel.org ya tiene resuelto este problema.

La lista completa de versiones del kernel vulnerables la ha publicado Security Focus.

Para saber si tu máquina es vulnerable:

1. Accede a la página web del exploit y copialo 
   a un fichero local, por ejemplo, exploit.c 

2. Compílalo con la orden
   $ gcc exploit.c

3. Esto genera un fichero binario llamado a.out que puedes ejecutar directamente
   $ ./a.out

Descarga del exploit

El código fuente del exploit lo tienes en http://www.milw0rm.com/exploits/5092

Copialo al portapapeles y lo pegas en tu terminal en un fichero vacío.

Pruebas de vulnerabilidad

Ubuntu 6.06 LTS Dapper Drake, kernel 2.6.15-51-386

No está afectado, al ser un kernel anterior al 2.6.17

$ uname -a
Linux jhp1 2.6.15-51-386 #1 PREEMPT Thu Dec 6 20:20:49 UTC 2007 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 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: 0xb7dc2000 .. 0xb7df4000
[-] vmsplice: Function not implemented
$

Ubuntu 6.10 Edgy - Server Edition, kernel 2.6.17-10-server

Vulnerable.

$ uname -a
Linux srv1 2.6.17-10-server #2 SMP Tue Dec 5 22:29:32 UTC 2006 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 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: 0xb7e5a000 .. 0xb7e8c000
[+] root
# 

Ubuntu 7.04 Feisty Fawn, kernel 2.6.20.16-386

No parece estar afectado: el exploit se compila pero la ejecución da un fallo de segmentación al intentar llamar a vsplice. Al parecer algunos de los kernel de Ubuntu no ponen vmsplice en enable a no ser que se haga deliberadamente, esa podría ser la razón de que el exploit termine con un fallo de segmentación.

$ uname -a
Linux jhp2 2.6.20-16-386 #2 Tue Dec 18 05:41:44 UTC 2007 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 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: 0xb7e2c000 .. 0xb7e5e000
Fallo de segmentación (core dumped)
$

Ubuntu 7.10 Gutsy Gibbon, kernel 2.6.22-14-generic

Vulnerable

$ uname -a
Linux panic 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 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: 0xb7ddb000 .. 0xb7e0d000
[+] root
#

Debian Etch, kernel 2.6.18-5-686

Vulnerable

  
$ uname -a   
Linux maiky 2.6.18-5-686 #1 SMP Wed Oct 3 00:12:50 UTC 2007 i686 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 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: 0xb7d81000 .. 0xb7db3000
[+] root
#

Open SuSE 10.2, kernel 2.6.18.2-34-default

Vulnerable

$ uname -a
Linux lumi 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 i686 i686 i386 GNU/Linux
$ gcc exploit.c
$ ./a.out
-----------------------------------
 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: 0xb7da2000 .. 0xb7dd4000
[+] root
#

Gracias a Sergio y Maseda por aportar los resultados en sus máquinas

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