Tavis Ormandi, conocido investigador de seguridad del equipo de seguridad de Google, ha publicado en su blog una interesante prueba de concepto sobre un problema de seguridad que afecta a Debian y distribuciones derivadas como Ubuntu.
Desde la publicación de Debian Squeeze en febrero de 2011 los desarrolladores cambiaron el intérprete de comandos por defecto, que era “bash“, por “dash” (Debian Almquist Shell) creado por Herbert Xu. Este cambio suponía una mejora en el tamaño, las dependencias y supuestamente, según Debian, mejora la velocidad de ejecución de los shell scripts. Como contrapartida dash perdía ciertas funcionalidades respecto a bash. Tampoco faltaron los problemas de compatibilidad al ejecutar scripts que en principio estaban diseñados para ejecutarse en bash.
Ormandy, observó que dash tiene un comportamiento diferente a bash cuando ha de relajar los permisos con los que corre cuando detecta que está siendo invocada como “sh“.
Normalmente, bash invocará la función “disable_priv_mode” si detecta que el “uid” del usuario es distinto del UID efectivo.
La función “disable_priv_mode” está definida de la siguiente forma:
void
disable_priv_mode ()
{
setuid (current_user.uid);
setgid (current_user.gid);
current_user.euid = current_user.uid;
current_user.egid = current_user.gid;
}
Es decir, a todos los efectos, el UID efectivo será el del usuario (y no uno privilegiado) y el mismo proceso rebajará sus privilegios (mediante la llamada a “setuid” y “setgid“) a los del usuario igualmente.
Esto es una efectiva medida para minimizar el riesgo de vulnerabilidades en aquellos ejecutables que tienen el bit “setuid” activado y que por lo tanto adquirirán los privilegios del propietario del archivo cuando se conviertan en un proceso.
Ormandy hace una sencilla prueba de concepto con un ejecutable privilegiado perteneciente a las utilidades de VMware que invoca a “lsb_release” para obtener información del sistema:
cc -xc – -olsb_release<<<‘main(){system(“sh>`tty` 2>&1”);}’;PATH=.:$PATH vmware-mount
Este trozo de código compila un ejecutable con nombre “lsb_release” y añade el directorio actual “.” a la variable de entorno PATH. Cuando se ejecute el programa de las utilidades de VMware, vmware-mount, este abrirá un proceso con la llamada al sistema “popen” llamando al ejecutable “lsb-release“. Como nuestro directorio de trabajo o “.” está antes en la variable PATH el ejecutable que utilizará será el código que acabamos de compilar.
Respecto al código del ejecutable este contiene una llamada a “system” donde ejecutamos “sh“. En bash este código no supondría una shell con privilegios de root ya que al ejecutar “sh” se rebajarían los privilegios gracias al “privmode“, sin embargo, en dash no existe un mecanismo que prevenga esta situación y se nos abrirá una shell con los máximos privilegios.
Curiosamente, según comenta Ormandi, Debian ya desechó el “privmode“, que impedía este problema, porque rompía la compatibilidad con UUCP (Unix to Unix CoPy) un programa, prácticamente ya en desuso, para transferir archivos entre sistemas UNIX de manera remota.
VMware ya ha publicado un parche que soluciona esta vulnerabilidad de elevación de privilegios, a la que le ha sido asignado el CVE-2013-1662.
Tavis ha enviado un parche a los desarrolladores de “dash” para agregar el “privmode“. Podemos ver la conversación en la lista de oss-security desde aquí
De momento todas las máquinas virtuales Debian (a partir de Squeeze) con el script de VMware mencionado son vulnerables a elevación de privilegios. Aunque no solo se restringe a dicho componente, si existiese un programa en el sistema con la misma funcionalidad y con el bit setuid activado tendríamos el mismo problema y por supuesto no es necesario que sea una máquina virtual.
Más información:
Security Debianisms
David García
Twitter: @dgn1729
Deja un comentario