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