El pasado día 17 de enero, Linus Torvalds hizo un commit para corregir una elevación de privilegios en el kernel Linux 2.6 (CVE-2012-0056). El fallo fue descubierto por Jüri Aedla y según comenta Torvalds en el
propio parche, se debe a una incorrecta comprobación de privilegios al abrir el /proc/#pid#/mem de un proceso.

Este error no pasó desapercibido a Jason A. Donenfeld que ha escrito y publicado un interesante exploit lo ha bautizado como 'Mempodipper'.

Donenfeld estudió en detalle el proceso de explotación. De partida se encontró con que efectivamente la comprobación de permisos era débil y además, que la protección contra escritura en el espacio de memoria del proceso fue eliminada del código del kernel. De hecho puede leerse en el comentario del commit correspondiente, que se eliminaba la restricción porque no se consideraba un peligro la escritura en /proc/#pid#/mem.

Esto hace virtualmente vulnerables a los núcleos con versión 2.6.39 o superior.

Cómo funciona:

Cuando se abre /proc/#pid#/mem se usa la función 'mem_open'. Dicha función almacena el 'self_exec_id' correspondiente al proceso que solicita la apertura. Esto se hace para comprobar posteriormente si son suficientes privilegios cuando se efectúan operaciones de lectura o escritura sobre el descriptor de fichero obtenido.

 static int mem_open(struct inode* inode, struct file* file)
{
file->private_data = (void*)((long)current->self_exec_id);
  

 En el caso de la operación de escritura se hace la comprobación del 'self_exec_id' además de llamar a 'check_mem_permission'. En teoría, para escribir en /proc/#pid#/mem, o se es el mismo proceso #pid# o el
proceso tiene ciertos permisos especiales relacionados con ptrace.

static ssize_t mem_write(struct file * file, const char __user *buf,
size_t count, loff_t *ppos)
{
...
...
  

Se llama a 'check_mem_permission' y si 'mm' vuelve con error no se efectúa la operación:

 

mm = check_mem_permission(task);
copied = PTR_ERR(mm);
if (IS_ERR(mm))
goto out_free;
  

'check_mem_permission' simplemente llama a '__check_mem_permission' y
como se observa dentro de su código efectúa la comprobación "task
==current":
  

static struct mm_struct *__check_mem_permission(struct task_struct
*task)
{
struct mm_struct *mm;

mm = get_task_mm(task);
if (!mm)
return ERR_PTR(-EINVAL);

if (task == current)
return mm;

...
...
  

Si no coinciden devuelve error. Luego debe ser el mismo proceso el que escriba en su propia memoria y si queremos elevar privilegios necesitaríamos un proceso con 'suid'.

Primera aproximación al exploit

Donenfeld se figuró cómo hacer esto:

$ su "yeeeee haw I am a cowboy"
Unknown id: yeeeee haw I am a cowboy

Cualquier cosa que se escriba pasa por la memoria del proceso creado por 'su' (que posee 'suid'). Parecia obvio qué hacer:

Abrimos '/proc/self/mem' y obtenemos su descriptor de archivo. Ejecutamos 'dup2' para multiplexarlo con 'stderr'. Escribimos nuestro shellcode en él y ejecutando posteriormente con exec obtendríamos root... pero no.

Esto no iba a funcionar debido a que aun queda otra restricción más:

if (file->private_data != (void *)((long)current->self_exec_id))
goto out_mm;
  

El 'self_exec_id' del proceso que va a ejecutar la escritura 'exec' ha de ser el mismo que abrió originalmente '/proc/#pid#/mem', recordad más arriba cuando se llama a 'mem_open'.

¿Por qué ha cambiado 'self_exec_id'?

Cuando se llama a 'exec' el 'self_exec_id', es aumentado en 1 impidiendo que esto ocurra:

void setup_new_exec(struct linux_binprm * bprm)
{
...
...
current->self_exec_id++;
  

Resumiendo. No podemos abrir el '/proc/#pid#/mem' de un proceso cualquiera, hacer 'dup2' con 'stderr' y luego hacer 'exec' de un proceso con 'suid' para escribir allí, ya que al hacer 'exec' no van a coincidir los 'self_exec_id'.

Donenfeld solucionó esto de manera sencilla pero ingeniosa, muy ingeniosa.

El exploit

Se hace 'fork' de un proceso y en este hijo se ejecuta 'exec' a un nuevo proceso. De este modo el 'self_exec_id', que se ha heredado del padre, ahora tiene un valor de +1 con respecto al padre.

Ahora hacemos que el padre ejecute 'exec' sobre un proceso 'suid' que va a escribir nuestro shellcode. En este momento, al ejecutar 'exec' en el padre su 'self_exec_id' acaba de aumentar a +1 coincidiendo con el del hijo.

Mientras tanto en el proceso 'exec' que ha llamado el hijo se obtiene, al abrir, el descriptor del '/pro /#parent_pid#/mem'; y es posible abrirlo porque no existe restricción en la operación de apertura. Es decir, no van a ser comprobados los privilegios del 'exec' que ha creado el hijo.

En este momento tenemos un 'exec' del padre con un proceso 'suid' dispuesto a escribir el shellcode. Un 'exec' del hijo con un descriptor del '/proc/#pid#/mem' del padre y la salida 'stderr' acoplada a ese descriptor (llamada a 'dup2') y lo más importante, tenemos los 'self_exec_id' igualados por lo tanto la restricción ha sido evadida.

Solo queda que el hijo pase el descriptor al padre y éste va a escribir el shellcode allí ya que cuando llame a 'mem_write', como hemos dicho, las comprobaciones van a ser correctas.

Pero aún queda más, averiguar "dónde" se debe escribir en memoria para poder ejecutar de manera exitosa el shellcode. Se necesita una dirección fija de memoria, algo que podría ser complicado si se usa ASLR, pero Donenfeld observó que la mayoría de binarios 'su' de las distribuciones no están compilados con 'PIE'(Position-independent executable)

Podemos observarlo si hacemos:

$ readelf -h /bin/su | grep Type
Type: EXEC (Executable file)

Como el mismo Donenfeld apunta, si el 'Type' fuera 'DYN' entonces si podría protegerse con ASLR debido a que el ejecutable permitiría ser reubicado en distintas posiciones de memoria. Al no ser el caso el desplazamiento en memoria siempre va a ser el mismo.

Buscando Donenfeld obtuvo la dirección 0x402178, correspondiente a una llamada a 'exit@plt'. Tan solo tenía que escribir en 0x402178 menos la longitud de la cadena 'Unknown id: ' y su shellcode se ejecutaría.

En definitiva, un exploit más interesante que la propia vulnerabilidad que explota y una muestra de ingenio por parte de Donenfeld al conseguir la explotación de la forma que hemos visto.

Más información:

Parche de Linus Torvalds

git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/commitdiff

Commit de la eliminación de la protección de escritura

git.kernel.org - linux/kernel/git/torvalds/linux-2.6.git/commitdiff

* Linux Local Privilege Escalation via SUID /proc/pid/mem Write

Linux Local Privilege Escalation via SUID /proc/pid/mem Write | Nerdling Sapple

El operador internacional TeliaSonera e Infinera anuncian el éxito de la primera transmisión óptica de 1 Terabit del mundo a través de supercanales de 500 Gigabits por segundo (Gb/s).

La demostración abarcó 1.105 kilómetros de fibra entre Los Ángeles and San José (California), marcando un hito en las redes ópticas y ofreciendo una visión de lo que será la red. La prueba se llevó a cabo con la nueva plataforma DTN-X de Infinera y demostró tener el doble de capacidad que en pruebas anteriores al añadir una capacidad de 1 Terabit a una ruta que transporta una capacidad de producción de 300 Gb/s.

“Nuestra visión es ofrecer a los clientes servicios de vanguardia que escalen su negocio de manera eficiente. Como los servicios de 10 Gb/s proliferan y los puertos de router de 100 Gb/s emergen, estamos probando soluciones avanzadas que escalen las redes ópticas por encima de los 100 Gb/s," dijo Erik Hallberg, presidente del operador internacional TeliaSonera. “Esta demostración de 1 Terabit con Infinera destaca nuestro compromiso para ofrecer una mejor experiencia para los clientes más exigentes."

“Estamos encantados de trabajar con el operador internacional TeliaSonera para validar la implementación de los supercanales de 500 Gb/s que son la base de esta demostración de 1 Terabit," dijo Tom Fallon, CEO de Infinera. “Compartimos una visión común de ofrecer la escalabilidad, simplicidad y agilidad necesaria para ganar un entorno altamente competitivo."

Infinera es una empresa pionera en el campo de los supercanales, y la primera en hacer una demostración de supercanales basados en circuitos fotónicos integrados (PICs) de 500 Gb/s. Un supercanal es una unidad grande de capacidad óptica creada al combinar múltiples transportes ópticos en una única entidad gestionada, de manera que las redes ópticas puedan escalar la capacidad sin escalar los costes operacionales y la complejidad. Los supercanales basados en PICs permiten a los operadores simplificar la provisión de capacidad de 500 Gb/s con una única maniobra operacional. La plataforma DTN de Infinera, la plataforma ATN y los Servicios Gestionados de Infinera son elementos del portfolio de Infinera, así como la recientemente anunciada plataforma de red de transporte óptico DTN-X que soporta supercanales de 500 Gb/s.

El operador internacional TeliaSonera es parte del 5º grupo de telecomunicaciones más grande del mundo, TeliaSonera, con 164 millones de usuarios que generan beneficios por encima de los 11.000 millones de dólares. La compañía sigue expandiendo la huella Norteamericana en su red global, causada por una fuerte demanda tanto de operadores como jugadores en el mercado de contenido para IP, DWDM, voz y servicios de móvil especialistas.

Las versiones antiguas del navegador de Microsoft, Internet Explorer, serán sustituidas automáticamente por la versión más reciente disponible para el sistema operativo instalado en el PC.

Microsoft publicó el 15 de diciembre un post en su blog de Internet Explorer, donde informa que, a partir de enero, Internet Explorer será actualizado automáticamente para los usuarios de Windows en Australia y Brasil que hayan activado la función de actualización automática de Windows Update.

En la práctica, el anuncio implica que Internet Explorer 8 sustituirá automáticamente a IE7 e IE6 en Windows XP que tengan instalado el Service Pack 3, mientras que los usuarios de Windows Vista SP2 y Windows 7 recibirán Internet Explorer 9. Windows XP no tiene soporte para IE9.

Después de Australia y Brasil, el sistema será aplicado de manera gradual a usuarios de Internet Explorer en todo el mundo.

Aparte de señalar que las versiones más recientes de IE proporcionan una mejor experiencia al usuario, Microsoft explica que el nuevo sistema es altamente relevante por razones de seguridad. En efecto, las versiones más recientes de IE incorporan funcionalidad de seguridad de la que carecen las versiones precedentes.

La razón de que Microsoft no limite el sistema a las versiones realmente antiguas de IE, sino que también en algún momento afectará a IE9, para el lanzamiento de IE10 es que, a su juicio, los usuarios sienten molestia frente a todas las notificaciones de actualizaciones. Por lo tanto, Microsoft prefiere que a partir de enero las actualizaciones sean automáticas.

Al respecto, Ryan Gavin, de Microsoft, cita un comentario del presidente de Mozilla Foundation, Mitchelle Baker, quién se refiere a la "fatiga de las actualizaciones".

La medida adoptada por Microsoft corresponde a un deseo manifestado durante varios años por desarrolladores web. En tal sentido, cabe destacar Internet Explorer 6, que 10 años después de su lanzamiento causa tal molestia y trabajo extraordinario para los desarrolladores, que muchos sencillamente han optado por desentenderse de incluir soporte para tal versión.

En mayo de 2010, Microsoft comparó a IE6 con una caja de leche descompuesta, mientras que el director de la plataforma IE declaró que su misión era destruir a Internet Explorer 6.

Posteriormente, en marzo de 2011, lanzó una campaña denominada Internet Explorer Countdown, cuyo objetivo era eliminar definitivamente el navegador.

Las empresas que utilicen soluciones centralizadas de administración de software, como WSUS (Windows Server Update Services), y que prefieran conservar IE6, no deberán impedir activamente la actualización. Microsoft ofrece además herramientas que bloquean la actualización automática. Más información en el blog de Microsoft.

Ilustración: Imagen difundida por Microsoft durante su campaña anti-IE6 en 2010: "Usted no bebería leche vencida hace 9 años"