Buenas lista,  comparto esta info

Elevación de privilegios en Debian y distribuciones 
derivadas-------------------------------------------------------------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
 enbash. https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/141481Ormandy, 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 "seguid" 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-mountEste trozo de código compila un ejecutable con nombre "lsb_release" 
yañ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. El parche esta disponible desde: 
http://www.vmware.com/security/advisories/VMSA-2013-0010.htmlTavis 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: http://thread.gmane.org/gmane.comp.shells.dash/841De 
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.Opina sobre esta 
noticia: 
http://unaaldia.hispasec.com/2013/08/elevacion-de-privilegios-en-debian-y.html#commentsMás
 información:Security 
Debianismshttp://blog.cmpxchg8b.com/2013/08/security-debianisms.html

Responder a