Todos sabéis que bash lleva desde los 80 "casado" con Unix/Linux y todavía se utiliza ampliamente para muchas cosas, entre ellas proveer un shell a un usuario remoto (telnet o ssh por ejemplo), como parser para scripts CGI (Apache, etc.) e incluso para facilitar soporte a la ejecución de comandos como se hace con Git...
#14 que tonteria, pero si Linux dispone de muchos Shells (ZSH, TCSH, etc...). Con usar otra distinta ya se soluciona (además de que existe el parche hace rato).
Según comentan en ars technica están afectadas (y con parche distribuido) al menos: Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
CentOS (versions 5 through 7)
Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
Debian
además de Mac OS X 10.9.4 ("Mavericks") y por lo que he leido también yosemite
¿ Hay algún ambiente en que se pueda definir una función que se ejecute en un sitio donde no se tienen ya permisos ? Si es así, poder ejecutar un programa malicioso es el menor de los problemas.
#1 ¿ en qué sentido ? Este bug parece que es muy difícil de explotar. Si lo comparas con un virus, será como comparar una gota de agua con un pantano. No perdamos la perspectiva, en cuestión de seguridad, están en ligas separadas.
- Los clientes DHCP invocan scripts de shell para configurar el sistema, con valores tomados de un servidor potencialmente malicioso. Esto permitiría ejecutar arbitrariamente comandos, normalmente como root, en el equipo cliente DHCP.
[...]
#3 Si leída está. Pero no creo yo que a día de hoy ningún sistema dhcp lea variables de nada invocando a una shell. Lo mismo para lo que dice del apache. Si me dices que en los 80 había cgi's así, te creo, pero a día de hoy nadie usará eso.Y lo mismo para las que tienen suid. Lo de las que "hookean" no es vulnerabilidad, evidentemente, por lo que decía. No sé por qué lo habrá incluido el autor. El arreglo es más teórico que por problema real. Yo creo que han descubierto el error, lo han resuelto y para buscar algún sistema donde se pueda explotar han debido tirar de imaginación e historia.
#4 En la noticia comentan que ya hay parche publicado. Cuando ocurre un fallo de tal gravedad se suele publicar la noticia cuando el arreglo ya está en marcha, como paso con Heartbleed.
Comentarios
#6 En efecto.
Chet Ramey, the GNU bash upstream maintainer, will soon release official upstream patches.
http://ftp.gnu.org/pub/gnu/bash/bash-3.0-patches/bash30-017
http://ftp.gnu.org/pub/gnu/bash/bash-3.1-patches/bash31-018
http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052
http://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-039
http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012
http://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-048
http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025
http://seclists.org/oss-sec/2014/q3/650
#20 Irrelevante. Busybox + µlibc (por tamaño y espacio sobre todo) es la mas usada de lejos, ya que implementa un huevo de herramientas.
http://www.busybox.net/products.html
#14 que tonteria, pero si Linux dispone de muchos Shells (ZSH, TCSH, etc...). Con usar otra distinta ya se soluciona (además de que existe el parche hace rato).
#15 bash es el más utilizado
llora
Según comentan en ars technica están afectadas (y con parche distribuido) al menos:
Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution
CentOS (versions 5 through 7)
Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
Debian
además de Mac OS X 10.9.4 ("Mavericks") y por lo que he leido también yosemite
http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/
Es un bug muy gordo
#13 Calla! no vaya a ser que los talibanes de linux se enfaden
otro palo para linux
¿ Hay algún ambiente en que se pueda definir una función que se ejecute en un sitio donde no se tienen ya permisos ? Si es así, poder ejecutar un programa malicioso es el menor de los problemas.
#1 ¿ en qué sentido ? Este bug parece que es muy difícil de explotar. Si lo comparas con un virus, será como comparar una gota de agua con un pantano. No perdamos la perspectiva, en cuestión de seguridad, están en ligas separadas.
#2 El resultado afecta a numerosos contextos:
- Los clientes DHCP invocan scripts de shell para configurar el sistema, con valores tomados de un servidor potencialmente malicioso. Esto permitiría ejecutar arbitrariamente comandos, normalmente como root, en el equipo cliente DHCP.
[...]
Hay que leerse las noticias
#3 Si leída está. Pero no creo yo que a día de hoy ningún sistema dhcp lea variables de nada invocando a una shell. Lo mismo para lo que dice del apache. Si me dices que en los 80 había cgi's así, te creo, pero a día de hoy nadie usará eso.Y lo mismo para las que tienen suid. Lo de las que "hookean" no es vulnerabilidad, evidentemente, por lo que decía. No sé por qué lo habrá incluido el autor. El arreglo es más teórico que por problema real. Yo creo que han descubierto el error, lo han resuelto y para buscar algún sistema donde se pueda explotar han debido tirar de imaginación e historia.
#1 Me juego la vida contra una raja de chorizo a que en unos días estará parcheada, no como pasa en otros OS's
Chet Ramey, the GNU bash upstream maintainer, will soon release
official upstream patches.
http://seclists.org/oss-sec/2014/q3/649
#4 En la noticia comentan que ya hay parche publicado. Cuando ocurre un fallo de tal gravedad se suele publicar la noticia cuando el arreglo ya está en marcha, como paso con Heartbleed.
#1 OS X también usa bash, aunque es una versión antigua y puede que no este afectada.
La cierran porque Menémane es pro-linux, pro-censura y pro-mafia
#9 pero si la has cerrado tú
#10 ???? yo no lo he cerrado. Si acaso habrá sido Carme
¿Que han cerrado qué? Yo acabo de menear
Puff heartbleed es un juego de niños comparado con esto, la que se va a liar en la red es parda
Shell remotas en firewalls,servers,dispotivos
#17 ¿Bash en firewalls y dispositivos? Iluso.
#19 https://techlib.barracuda.com/display/bngv54/basic+linux+command+line+interface+guide