Portada
mis comunidades
otras secciones
#42:
#12 Joder, cómo sois algunos de exquisitos cuando se trata de vulnerabilidades relacionadas con sistemas operativos Linux... ¿Te imaginas que se descubre una vulnerabilidad grave que afecta al Administrador de Tareas de Windows y alguien lo vota negativo porque "la vulnerabilidad no es de Windows sino del Administrador de Tareas"? Bash es una parte importante de Linux, por tanto una vulnerabilidad en bash compromete a una cantidad enorme de sistemas Linux. Sólo se librarían aquellos que no hagan uso de él, y estate tú mirando a ver si no hay ningún proceso en segundo plano haciendo uso de bash para alguna de sus funciones...
Y respecto a lo de #7, es evidentemente obvio pero eso no cambia nada. Además es una excusa malísima, es como si yo digo que una vulnerabilidad en Windows también afecta a Linux si estás usando una máquina virtual con el Windows 7 en el VirtualBox que tienes instalado en tu Ubuntu.
Lo mejor del software libre es la continua capacidad de detectar vulnerabilidades y corregirlas, cosa que se lleva a cabo por parte de toda la comunidad debido a que es un proyecto libre y abierto. Para que esto siga siendo así, hace falta una gran capacidad autocrítica para seguir buscando y corrigiendo errores, y lo primero para eso es no menospreciarlos y admitir su importancia. Tu actitud es justo la opuesta: no sólo quitarles importancia sino tratar de quitar a Linux de en medio para que no le salpique la mierda. Esa actitud es propia de muchos defensores de Linux y así lo único que se consigue en mi opinión es perjudicar al proyecto.
Y respecto a lo de #7, es evidentemente obvio pero eso no cambia nada. Además es una excusa malísima, es como si yo digo que una vulnerabilidad en Windows también afecta a Linux si estás usando una máquina virtual con el Windows 7 en el VirtualBox que tienes instalado en tu Ubuntu.
Lo mejor del software libre es la continua capacidad de detectar vulnerabilidades y corregirlas, cosa que se lleva a cabo por parte de toda la comunidad debido a que es un proyecto libre y abierto. Para que esto siga siendo así, hace falta una gran capacidad autocrítica para seguir buscando y corrigiendo errores, y lo primero para eso es no menospreciarlos y admitir su importancia. Tu actitud es justo la opuesta: no sólo quitarles importancia sino tratar de quitar a Linux de en medio para que no le salpique la mierda. Esa actitud es propia de muchos defensores de Linux y así lo único que se consigue en mi opinión es perjudicar al proyecto.
#213:
#207 a mí no hace falta que me des explicaciones. Yo soy administrador de sistemas y conozco todas las siglas y definiciones que hay que conocer. Pero a la hora de verdad hay que ser práctico. Y siendo práctico, los que utilizan prácticamente cualquier distribución de Linux (o GNU/Linux para que no os enfadéis) en servidores están jodidos si no actualizan. Bash está presente en todos los sistemas operativos que se instalen por defecto en la gran mayoría de los hosting que hay en Internet
Aquí mientras unos intentamos advertir de la gravedad del asunto, otros se dedican a decir que no es Linux sino GNU/Linux, mientras que otros solo les interesa lo que ha comido hoy Stallman y al otro de más allá mete a Windows en todo este tema (aunque no tenga nada que ver)
Aquí mientras unos intentamos advertir de la gravedad del asunto, otros se dedican a decir que no es Linux sino GNU/Linux, mientras que otros solo les interesa lo que ha comido hoy Stallman y al otro de más allá mete a Windows en todo este tema (aunque no tenga nada que ver)
#224:
#1 Hoy en día ningún sistema actual permite que se pueda explotar eso.
Si me dices hace 20 años, vale. Pero a día de hoy nadie coge una cadena de un sistema no confiable y lo ejecuta en una shell. Ni en bash ni en ninguna otra.
Ni punto de comparación del agujero de seguridad que genera este bug con lo que pueda ser un virus, por ejemplo.
La noticia es sensacionalista a tope.
Si me dices hace 20 años, vale. Pero a día de hoy nadie coge una cadena de un sistema no confiable y lo ejecuta en una shell. Ni en bash ni en ninguna otra.
Ni punto de comparación del agujero de seguridad que genera este bug con lo que pueda ser un virus, por ejemplo.
La noticia es sensacionalista a tope.
#1:
De piedra, me he quedado de piedra. Y esto no es una cosa de ayer, que igual hace meses que 'alguno' lo sabe y se habra estado forrando a hacer maldades.
#106:
#97 No es exactamente así. La línea env x='() ; echo vulnerable' bash -c "echo this is a test" crea la variable de entorno que le pasa luego a bash. Si quieres probar si zsh es vulnerable, la línea sería env x='() ; echo vulnerable' zsh -c "echo this is a test". El problema está en la shell que recibe las variables de entorno, no en la que las crea.
#17:
#14 La vulnerabilidad de bash parcheada:
http://box.jisko.net/i/378f1b7a.png
...y descartada de ayer:
Grave vulnerabilidad en bash (CVE-2014-6271) permite la ejecución remota de comandos/c8#c-8
http://box.jisko.net/i/378f1b7a.png
...y descartada de ayer:
Grave vulnerabilidad en bash (CVE-2014-6271) permite la ejecución remota de comandos/c8#c-8
#34:
El ejemplo más llamativo es el de los servidores que generan páginas con bash
Eso existe aún? Si con todos los micro-frameworks y lenguajes específicos para web, aún usas bash para cgi, mereces lo que te pase.
Eso existe aún? Si con todos los micro-frameworks y lenguajes específicos para web, aún usas bash para cgi, mereces lo que te pase.
#14:
En archlinux acaban de subir una actualización de bash... en el test que ofrece la página al final no imprime en ningún caso vulnerable
^-^
que eficiencia los de arch
^-^
que eficiencia los de arch
#27:
¿Pero entonces este tampoco será el año de Linux en los PCs de escritorio?
#23:
#21
Someone has posted large parts of the prenotification as a news
article, so in the interest of full disclosure, here is what we wrote to the non-vendors (vendors also received patches):
Debian and other GNU/Linux vendors plan to disclose a critical,
remotely exploitable security vulnerability in bash this week, related to the processing of environment variables. Stephane Chazelas discovered it, and CVE-2014-6271 has been assigned to it.
The issue is currently under embargo (not public), and you receive
this message as a courtesy notification because we assume that you
have network-based filtering capabilities, so that you can work on
ways to protect a significant number of customers. However, you
should not yet distribute IPS/IDS signatures, publicly or to
customers.
http://seclists.org/oss-sec/2014/q3/650
Someone has posted large parts of the prenotification as a news
article, so in the interest of full disclosure, here is what we wrote to the non-vendors (vendors also received patches):
Debian and other GNU/Linux vendors plan to disclose a critical,
remotely exploitable security vulnerability in bash this week, related to the processing of environment variables. Stephane Chazelas discovered it, and CVE-2014-6271 has been assigned to it.
The issue is currently under embargo (not public), and you receive
this message as a courtesy notification because we assume that you
have network-based filtering capabilities, so that you can work on
ways to protect a significant number of customers. However, you
should not yet distribute IPS/IDS signatures, publicly or to
customers.
http://seclists.org/oss-sec/2014/q3/650
Comentarios
#12 Joder, cómo sois algunos de exquisitos cuando se trata de vulnerabilidades relacionadas con sistemas operativos Linux... ¿Te imaginas que se descubre una vulnerabilidad grave que afecta al Administrador de Tareas de Windows y alguien lo vota negativo porque "la vulnerabilidad no es de Windows sino del Administrador de Tareas"? Bash es una parte importante de Linux, por tanto una vulnerabilidad en bash compromete a una cantidad enorme de sistemas Linux. Sólo se librarían aquellos que no hagan uso de él, y estate tú mirando a ver si no hay ningún proceso en segundo plano haciendo uso de bash para alguna de sus funciones...
Y respecto a lo de #7, es evidentemente obvio pero eso no cambia nada. Además es una excusa malísima, es como si yo digo que una vulnerabilidad en Windows también afecta a Linux si estás usando una máquina virtual con el Windows 7 en el VirtualBox que tienes instalado en tu Ubuntu.
Lo mejor del software libre es la continua capacidad de detectar vulnerabilidades y corregirlas, cosa que se lleva a cabo por parte de toda la comunidad debido a que es un proyecto libre y abierto. Para que esto siga siendo así, hace falta una gran capacidad autocrítica para seguir buscando y corrigiendo errores, y lo primero para eso es no menospreciarlos y admitir su importancia. Tu actitud es justo la opuesta: no sólo quitarles importancia sino tratar de quitar a Linux de en medio para que no le salpique la mierda. Esa actitud es propia de muchos defensores de Linux y así lo único que se consigue en mi opinión es perjudicar al proyecto.
#7 Eso es como decir que una vulnerabilidad en Windows afectara a Linux tambien si tienes Wine instalado...
#11 No mires el dedo.
La cuestión es que la vulnerabilidad no es de ni Linux ni de Os X, ni siquiera de Windows.
Es de Bash. El titular desde mi punto de vista es sensacionalista e inexacto.
De piedra, me he quedado de piedra. Y esto no es una cosa de ayer, que igual hace meses que 'alguno' lo sabe y se habra estado forrando a hacer maldades.
#13 ¿Vaya kakao no?
1) No es un exploit remoto.
2) Linux y OS X != todos los Unix. Es mas HP UX, AIX o Solaris NO usan ni instalan Bash Shell por defecto.
#14 La vulnerabilidad de bash parcheada:
http://box.jisko.net/i/378f1b7a.png
...y descartada de ayer:
Grave vulnerabilidad en bash (CVE-2014-6271) permite la ejecución remota de comandos/c8#c-8
En archlinux acaban de subir una actualización de bash... en el test que ofrece la página al final no imprime en ningún caso vulnerable
^-^
que eficiencia los de arch
¿Pero entonces este tampoco será el año de Linux en los PCs de escritorio?
#13 Yo uso pdksh. No es en todos los unix.
Y Ubuntu/Debian usan dash como /bin/sh . Bash es opcional.
Esto con Windows no pasa
El ejemplo más llamativo es el de los servidores que generan páginas con bash
Eso existe aún? Si con todos los micro-frameworks y lenguajes específicos para web, aún usas bash para cgi, mereces lo que te pase.
#7 claro... alguien ha soltado algún maletín para que omitan Windows del titular.
Vosotros y vuestro victimismo...
#26 $ apt-get update
#97 No es exactamente así. La línea env x='() ; echo vulnerable' bash -c "echo this is a test" crea la variable de entorno que le pasa luego a bash. Si quieres probar si zsh es vulnerable, la línea sería env x='() ; echo vulnerable' zsh -c "echo this is a test". El problema está en la shell que recibe las variables de entorno, no en la que las crea.
#55 ¿Con Bash? Ninguno, todos usan busybox.
#57 Cygwin no emula, y con Msysgit (git para Windows) tienes Bash de regalo. O , sorpresa.
#15 El Cacao es buen sustituto del sexo, aunque prefiero lo último.:
1º Remote exploit OSX
http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7
Por no decir un DHCP comprometido.
2º ¿Utilizan CUPS printing system HP UX, AIX o Solaris? Pues ya tienes otro vector.
#12 ¿Sensacionalista un exploit remoto en todos los Unix y sus derivados?
#21
Someone has posted large parts of the prenotification as a news
article, so in the interest of full disclosure, here is what we wrote to the non-vendors (vendors also received patches):
Debian and other GNU/Linux vendors plan to disclose a critical,
remotely exploitable security vulnerability in bash this week, related to the processing of environment variables. Stephane Chazelas discovered it, and CVE-2014-6271 has been assigned to it.
The issue is currently under embargo (not public), and you receive
this message as a courtesy notification because we assume that you
have network-based filtering capabilities, so that you can work on
ways to protect a significant number of customers. However, you
should not yet distribute IPS/IDS signatures, publicly or to
customers.
http://seclists.org/oss-sec/2014/q3/650
#3 bastante menos
#31 Ni maletines ni tonterías. El titular de la noticia ahora es correcto. El de menéame no está bien: es una vulnerabilidad de bash.
#207 a mí no hace falta que me des explicaciones. Yo soy administrador de sistemas y conozco todas las siglas y definiciones que hay que conocer. Pero a la hora de verdad hay que ser práctico. Y siendo práctico, los que utilizan prácticamente cualquier distribución de Linux (o GNU/Linux para que no os enfadéis) en servidores están jodidos si no actualizan. Bash está presente en todos los sistemas operativos que se instalen por defecto en la gran mayoría de los hosting que hay en Internet
Aquí mientras unos intentamos advertir de la gravedad del asunto, otros se dedican a decir que no es Linux sino GNU/Linux, mientras que otros solo les interesa lo que ha comido hoy Stallman y al otro de más allá mete a Windows en todo este tema (aunque no tenga nada que ver)
¿Alguien que lo explique en cristiano para los que usamos Linux pero no somos expertos?
¡Gracias!
#9 Claro que no. En Windows sólo te instalan barras de navegadores, malware, spyware y demás lindezas en cuanto le dejas el ordenador a tu hermana/sobrino/cuñado/padres
#9 ¿Y tu como lo sabes? ¿Has visto el código fuente de Windows?
#29 apt-get update && apt-get upgrade
El titular es sensacionalista porque no afecta a Linux, solo afecta al 99% de las distribuciones Linux.
En ubuntu sacaron el parche hace más de 20horas http://www.ubuntu.com/usn/usn-2362-1/ solo tienes que actualizar el sistema
#42 #12 tiene razón. Bash no es linux, es un intérprete más del puñado que puedes elegir. De hecho Bash nació cuatro años antes que Linux.
Y eso no tiene que ver nada con la autocrítica, puesto que Bash también es software libre y es otro fallo que tiene que solucionar un proyecto de software libre
PS: de hecho aquí la tienes con el título correcto (vulnerabilidad en Bash) y se ha descartado por irrelevante Grave vulnerabilidad en bash (CVE-2014-6271) permite la ejecución remota de comandos
Grave vulnerabilidad en bash (CVE-2014-6271) permi...
hackplayers.comErrónea, al menos el titular...
#42 No es por ser quisquilloso, pero es que precisamente bash no es parte de Linux. Que conste que me da igual, Linux tendrá sus vulnerabilidades, seguro. Pero no es el caso.
#63 #29 #47 #70 sudo
#9 GO TO #7
#2 El problema no es que no haya parche. Para cualquier bug, el parche sale casi instantáneamente.
El problema es qué pasa con los servidores cuyo administrador no se ha enterado de esto. O que no se mantienen. O que no se pueden actualizar así como así porque son críticos y hay que planificar este tipo de cosas. Ahí es donde está el problema, porque pueden pasar meses hasta que se arregle, si se arregla.
#214 busybox no es igual ni tiene a BASH.
#1 Hoy en día ningún sistema actual permite que se pueda explotar eso.
Si me dices hace 20 años, vale. Pero a día de hoy nadie coge una cadena de un sistema no confiable y lo ejecuta en una shell. Ni en bash ni en ninguna otra.
Ni punto de comparación del agujero de seguridad que genera este bug con lo que pueda ser un virus, por ejemplo.
La noticia es sensacionalista a tope.
#190 a ver que te explico las condiciones que se tienen que dar para que un servidor sea atacado por esto ya que la noticia no lo dice:
1-) La shell por defecto es bash o redirige a bash (debian's no)
2-) Ejecutar CGI o PHP, Perl, Python, etc. y hacer una llamada al sistema (system()) sin verificar qué es lo que estas recibiendo.
Para que lo entiendas mejor, es la misma genialidad detrás de los fallos de inyección SQL. ¿Es un fallo de SQL ejecutar SQL? NO! Es un fallo del tarugo que coge una cookie y se la pasa a SQL sin sanearla.
Parchear el fallo en OS X:
https://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7
#34 https://encrypted.google.com/#q=filetype:sh+:inurl:cgi-bin
#c-112" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2261840/order/112">#112 Aquí lo ves mejor. Por si acaso, para que nada entre por Bash:
/home/ander>cat bug.ksh
#!/bin/pdksh
rm -f echo && env -i X='() { (a)=>' pdksh -c 'echo date'; cat echo
rm -f echo && env -i X='() { (a)=>' pdksh -c 'echo ls -la'; cat echo
rm -f echo && env -i X='() { (a)=>' pdksh -c 'echo wget
https://bugzilla.redhat.com/
#226 "no, este bug casi no tiene posibilidad de ser explotado. "
Bueno, tiene la mayor puntuación de explotabilidad y no tienen más números en la escala para puntuar lo grave que es pero qué coño sabrán ellos ¿no?
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
Y estos otros sensacionalistas: http://unaaldia.hispasec.com/2014/09/bash-significa-golpe-porrazo-o-castana.html
#229 Pierdes el tiempo, aquí siempre se busca cualquier escusa para minimizar la noticia.
#2 Ya se esta liando parda, hay PoC y exploit por todos lados
#71 Nueva vulnerabilidad en Bash. Esa es la correcta. Hay Linux que funcionan sin Bash.
#26 viene a decir que si tienes un servidor web que use CGI (me dedico a eso y nunca he utilizado*) y use bash ya estas actualizando como un loco... Si no usa CGI tambien: ya estas actualizandolo.
Si eres un usuario no tiene demasiada importancia (actualiza, que ya esta el parche!), realmente si alguien puede ejecutar bash en tu ordenador no necesita hacer nada mas para ejecutar bash...
*mod_python y mod_php no parecen usarlo y java, evidentemente, menos.
#40 " diciendo que soy invulnerable por usar otra shell."
Si no tienes bash, no eres vulnerable. Repito, en OpenBSD ni siquiera está en el sistema base. Ni como dependencia de CUPS.
#42 "Sólo se librarían aquellos que no hagan uso de él, y estate tú mirando a ver si no hay ningún proceso en segundo plano haciendo uso de bash para alguna de sus funciones..."
Hay Linux sin bash, con BusyBox.
Olvidas millones de dispositivos HW que usan Linux SIN Bash o GNU Coreutils.
#84 "negativo, el fallo está en todos los intérpretes de shell. tanto bash, como shell como cualquier otro que se te ocurra que use sh o "./" para ejecutar un archivo, es vulnerable. "
Probando en pdksh. NO funciona. Por favor, no tergiverses. El fallo está en BASH.
Empecemos diciendo que si no gestionas ningún servidor expuesto a Internet no deberías preocuparte, probablemente
No te jode, y si estás muerto también puedes dejar de preocuparte...
#8 ¿Un fallo de una aplicación tira por tierra toda la seguridad de Linux?
Entonces en Windows la seguridad es inexistente a todos los efectos.
De todas formas, lo que comenta de explotar un fallo en bash manipulando la cadena useragent de un navegador, como que me tira un pelín para atras.
#25 #33 Cierto solamente corrige el primero. Lo acabo de comprobar.
#29 #47 O
$zypper ref && zypper up.
No sólo de apt-get updatevive el hombre...
#11 #28 Pues es incorrecto. Es una comparación errónea.
Wine no tiene nada que ver con Windows. Un bug en Windows no afecta a Wine, y viceversa. Wine es compatible con Windows a nivel de interfaz, pero no comparten código (como es lógico, pues Windows es código cerrado).
Sin embargo, sí puedes ejecutar Bash (el auténtico, el de la vulnerabilidad) en Windows, aunque evidentemente no es lo común.
Eso no quita que #7 se la esté cogiendo con papel de fumar . Bash viene instalado por defecto en MacOS y en muchas distros Linux. No viene instalado por defecto en Windows (y el porcentaje de Windows que lo tienen instalado es nimio). Así que por favor seamos racionales.
#15 Sí que permite ejecución remota de código.
#120 Mira el titular, y reflexiona. Ni afecta a todo internet ni a Linux en particular.
Si quieres vulnerabilidades explícitas para Linux, está el explot que conseguía root hace eones en la rama 2.6 .
Con el titular se puede dar a entender que afecta a Android, y no es el caso.
#124 " Bash es linux"
No me diga. Joder con los de GNU, usan una shell como kernel.
#151 Servidores != todos. Recuerda la teoría de conjuntos del colegio y tal.
En móviles, se usa Linux, y no solo en Android. Y no usan Bash.
GNU/Linux, todos los que quieras.
Pero la vulnerabilidad NO es de Linux u OSX. Es de BASH.
Cuando afecte a componentes intrínsecos de OSX u iOS (mach, cocoa, AQUA) o el kernel de Linux, entonces sí.
¿Quién es listo que permite funciones como variables ?
#20 " 2º ¿Utilizan CUPS printing system HP UX, AIX o Solaris? Pues ya tienes otro vector. "
¿Otro "lissssto". OpenBSD usa bash para usar CUPS? NO.
Y tampoco usamos el mismo cliente o servidor de dhcp de ISC.
Puedes vivir con pdksh perfectamente.
Hala, a trollear a casa.
En muchos UNIX bash es opcional
#59 GNU/Linux. En otros dispositivos está Linux sin bash tan alegremente. Routers, móviles, teles...
#75 Los demonios tampoco usaban Bash. ¿Cuando coño vas a darte cuenta que OBSD no necesita esa shell para lanzar nada?
Si está en /usr/local es por algo.
Tenemos PDKSH como shell estandar. Para TODO.
Dí lo que te dé la gana, no tienes razon. Ningún demonio depende de Bash.
#121 pues sí, tienes razón, el titular es sensacionalista.
#2 #17 Teniendo en cuenta que el descubridor estuvo esperando a que se publicasen los parches antes de anunciarlo, como para no haberlos.
Pero se filtró antes de tiempo y los parches se precipitaron.
Ahora ¿cuánto tiempo hace que otra gente no tan buena lo sabe y lo explota? puede que ningún otro lo haya encontrado, o puede que sí, sea como fuere, vaya agujero de seguridad.
Se puede liar parda
pero bueno, unas horas, y ya empiezan a aparecer parches
#84 El problema también lo tiene Bash. Otras shells no tienen esa vulnerabilidad.
Una cookie también es una variable de entorno. Piensa lo que se puede hacer.
#97 : Pues claro, porque estás ejecutando bash dos veces.
#15 Sí es un exploit remoto pues afecta, por ejemplo, a los servidores web que usen CGI y no incorporen el acelerador mod_cgi para llamar directamente a los scripts saltándose el bash.
#234 Pues no sé qué sabrás tú pero entre tú y la división nacional de ciberseguridad de EEUU + los de hispasec + los de redhat que la clasifican como alta, etc. me quedo con ellos y lo dicen bien claro:
Nivel de impacto: 10 (sobre diez). Nivel de explotabilidad: 10. Vector de ataque: explotable en red. Dificultad de explotación: baja. Tipo de impacto: fuga de información, modificación no autorizada, interrupción de servicio.
Pero paso de discutir.
#73 yo me refiero a las 14 paginas de resultados de google, no a todo en general.
Son servidores web normales, incluso de gobiernos. Es bash seguro.
Y como dicen mas arriba, ocurre no solo en bash, sino en otras muchas shells.
#18 has oído hablar de la programación funcional?
javascript:
var hi = function() ;
ruby:
hi = lambda
etc etc…
#29 Gracias, he puesto el Synaptic a actualizar y ahí me aparece el parche.
#130 " me refiero a que bash está presente en todos los sistemas linux"
Eso es soberamente mentira. Mi movil no usa Bash.
Estas cosas a mi no me afectan, lusers
Enviado desde mi MIR-2
http://goo.gl/1gtvtT
#13 con eso nadie hace un exploit hoy en día. Ningún sistema de los últimos años coge una cadena del exterior y la pasa a un intérprete bash. Sería un error de seguridad de primer orden de ese programa. Y si tienes un programa con ese error, el que tengas una bash mejor o peor ni te ayuda ni te deja de ayudar.
#66 sh . Los script de shell pueden ser ejecutados por shells que no sean Bash. Prácticamente todas las demas, incluso Busybox en Android.
¿Qué te creías? ¿sh = bash?
Hala, por ir de listo.
De hecho yo también tengo shell scripts que se usaron para actualizaar la ROM de base sin usar GNU Bash para nada.
#45 No pretendo hacer un flame contigo, pero por mi sigue con tu "invulnerabilidad".:
http://linux.slashdot.org/story/14/09/24/1638207/remote-exploit-vulnerability-found-in-bash
"The major attack vectors that have been identified in this case are HTTP requests and CGI scripts. Another attack surface is OpenSSH through the use of AcceptEnv variables.
Ahora, como dices, OpenBSD no es vulnerable en puro. Otra cosa son los servicios (o demonios) que instales.
#125 Sensacionalista, en portada y con solo 11 negativos. Como era eso... ¡10.000 millones de moscas no pueden estar equivocadas! ¡Comamos mierda!.
Pues eso, cuidado con lo que se ve en la portada de Meneame porque muchas veces solo es eso. Mierda.
#156 "De todas formas el peligro está en los servidores Linux. " Eso sí. Pero llamar el problema en Linux e incluso "toda internet" es pecar de sensacionalista.
Sí, GNU/Linux+ Apache / Nginx se usa mucho, pero hay otros UNIX sin Bash rulando internet amén de WIndows, y por supuesto la web no es " todo internet " .
Y sobre todo no todos los Linux llevan Bash. Es leer el titular y "coño, se avecina Skynet" .
Por como lo leo parece un cataclismo mundial.
#179 #180 donde pone que los de Genbeta le han dado un 10/10?? como se nota que os gusta hablar antes de leer, lo de 10/10 lo he sacado de esta noticia http://www.theguardian.com/technology/2014/sep/25/shellshock-bug-heartbleed
"The US government-backed National Vulnerability Database rated Shellshock 10/10 for severity. "
National Vulnerability Database:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
#122 no sudes, hombre, que no es tan difícil
Ni que bash fuese la única shell y es más:
así que estamos hablando de sistemas Linux, OS X y demás derivados UNIX (BSD, Solaris...).
Muchos solaris, aix y hp-ux de mi curro ni tienen bash ni para un /bin/bash, sólo ksh.
Así que lo veo un poquito sensacionalista. Ya que además, como apuntan por ahí, es un bug de la aplicación, no del OS. Bash no es parte integral *nix, sólo otra aplicación más.
Por cierto, Archlinux ya ha actualizado la versión de bash.
#19 Yo tambien uso Powershell en vez de CMD en windows, no por ello cuando sale un parche de windows voy de lisssto, diciendo que soy invulnerable por usar otra shell.
Para los que usen bash en Ubuntu.:
sudo apt-get update && sudo apt-get install bash
http://askubuntu.com/questions/528101/what-is-the-cve-2014-6271-bash-vulnerability-and-how-do-i-fix-it
P.D.:
#7 me imagino que diras que cuando sale un exploit en windows es sensanionalista porque tambien afecta a los linux con wine y a los osx con parallels
#41 A ver. El titular dice "Shellshock - La nueva vulnerabilidad para OS X y Linux". Es lo que digo que está mal. La noticia dice otra cosa "Una vulnerabilidad en Bash de Linux, OS X y otros *NIX es un gran problema de seguridad para todo Internet..." No es lo mismo.
#102 Por favor, pero bésamelo. No tenías ninguna falta de ofender, aunque a juzgar por otros comentarios tuyos, es una constante.
#106 #108 Ualá muy cierto!!! Me acabo de quedar con el culo torcío (pero muy limpio gracias a #102)
#51 No, qué va, en absoluto bash es parte de Linux...
Si sólo está instalado en el 99,99% de los equipos con Debian (https://qa.debian.org/popcon.php?package=bash)
Y apenas en el 99,99% de los Ubuntu (http://popcon.ubuntu.com/ - Link en la columna "Inst" de la primera tabla).
No he encontrado estadísticas de Fedora, pero dudo mucho que sean distintas.
#166 Si utilizas servidores Windows entonces estás exento de peligro. Esa es la realidad
Si utilizas servidores Windows entonces tienes bastantes otros problemas de los que preocuparte. Esa es la realidad.
#195 Joer, tio, para estar repitiendo una tontería durante tantos comentarios, mira que eres cansino, e incoherente, pero ahora es más molesto lo de cansino. NO, NO TODOS LOS SERVIDORES *NIX LLEVAN BASH. NO, EL 99% DE LOS FRIKIS (SEGUN TU LOS UNICOS CON LINUX DE ESCRITORIO) Y SYSADMIN HACEN LA INSTALACION POR DEFECTO.
Hala y vete a pastar. Pesao. Que no eres más que un pesao.
#11 iba a decir lo mismo.
#82 No lo voy a volver a releer pero del hilo http://seclists.org/oss-sec/2014/q3/649 se pueden sacar conclusiones.
#95 Vale, ya sé lo que querías que supiera.
Item plus del hilo:
Someone has posted large parts of the prenotification as a news
article
#12 te daría la razón si pudiese ignorar cómo y para qué se usa bash en GNU/Linux y Mac OS X en comparación con Windows. Peeero nope, no puedo.
#131 Instala esto y luego dime si no tienes bash
https://play.google.com/store/apps/details?id=hecticman.jsterm&hl=es
A seguir llorando
#144 Ya. Pero la realidad es como si está en el 100% de Debian y en todos los Ubuntu. Bash NO es linux ni OSX.
#c-205" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2261840/order/205">#205 #203 falso:
eldelshell@eldelshell-laptop:~$ head /etc/rc0.d/S30urandom
#! /bin/sh
#8 Diras la seguridad de Bash.
Linux tiene sus propios exploits
¿Cuantos móviles android (android está basado en linux) que hay en el mercado están afectados?
Fallos de gestión de smartphones ponen en riesgo al usuario: investigadores
Fallos de gestión de smartphones ponen en riesgo al usuario: investigadores
Fallos de gestión de smartphones ponen en riesgo a...
es.reuters.comAndroid, a vueltas con el problema de los parches que nunca llegan
Android, a vueltas con el problema de los parches que nunca llegan
Android, a vueltas con el problema de los parches ...
unaaldia.hispasec.com#81 Sigue sin ser "Linux", el fallo está en GNU Bash. Y repito, suma los móviles y dispositivos que usan Linux como embedido, superan a todos los demás de lejos que usan GNU Bash.
En servidores obviamente es otra cosa y están jodidos de verdad ya que usan GNU/Linux.
#86 Tampoco bash con el Linux, pues es un kernel. Si usas una distro, te lo comes.
Si usas android, usas Linux, pero no GNU Bash. O muchos routers y aparatos con busybox.
#71 Sin duda. Pero sintetizar, omitir o resumir. Pero en este caso es un titular falso.
#98 " Y como dicen mas arriba, ocurre no solo en bash, sino en otras muchas shells. "
No va en pdksh, que es la que usa OpenBSD y e instalado en Slackware desde los Slackbuilds.
10/10 would shebang again.
#9 Con Windows no hace falta que pase, se cuelan igual