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
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.
#1 ¿Meses? Esto lleva años, y hace años que se usa como herramienta propia del sistema. Bash, y otros intérpretes de shell, como zsh (mi favorito), son utilizados como herramienta básica de gestion de un sistema. Si no tuviera el poder de modificar el sistema, no sería util.
Aquí lo nuevo no es el bug, sino su explotación. Quizá no es un problema de vulnerabilidad, sino de una "falta de habilidad" por parte del desarrollador. Permitir que en los servidores web se ejecute una linea de comando desde una query es una animalada, más aun con privilegios de administrador. Es como si a través de una cookie pudiera hacer "apt-get update && apt-get dist-upgrade" y no necesitar ni sudo. Es de temerarios.
#83 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.
#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.
#85 te repito, zsh tambien es vulnerable, cualquier intérprete de shell.
#89 No es afán de tergiversar. Desconocía pdk, le daré un try.
En mi ejemplo ejecuto bash y la vulnerabilidad, luego zsh y la vulnerabilidad de nuevo. Idéntico resultado.
#97 ¿Ejecuto pdksh y te dejo con el culo al aire?
#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.
#97 : Pues claro, porque estás ejecutando bash dos veces.
#97 zsh es vulnerable, pero no necesariamente otras shells.
ksh por ejemplo.
#122 alias
#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.
#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.
#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.
#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.
#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
#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.
#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.
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
#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
#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.
#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
#23 #23 Pues no sé qué quieres decirme con eso. Ahí dice que alguien se adelantó y que esta semana planean hacer pública (ya lo hicieron) una vulnerabilidad crítica. No dicen desde cuándo la conocen. Ni si algún otro la conocía de antes. Ni contradice el hecho de que si el descubridor espera a que haya parches antes de hacerlo público, obviamente vas a tener parches cuando se haga público.
Esto data al menos del 14 de este mes, hace 11 días: https://bugzilla.redhat.com/show_bug.cgi?id=1141597 Mientras que tu enlace es de ayer.
P.D: Y lo que lleve actualizar todo lo afectado, que esto va para meses.
#82 No lo voy a volver a releer pero del hilo http://seclists.org/oss-sec/2014/q3/649 se pueden sacar conclusiones.
#92 Pues si las sacaste, exponlas, y si no las sacaste no tiene sentido que lo enlaces.
Que yo no te he mandado leer ningún tocho, te dije directamente lo que quería que supieras.
#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
#100 Felicidades.
#14 ya puedes votar antigua
¿Pero entonces este tampoco será el año de Linux en los PCs de escritorio?
#27 no, ¡el próximo año!
#13 Yo uso pdksh. No es en todos los unix.
Y Ubuntu/Debian usan dash como /bin/sh . Bash es opcional.
#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.:
#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.
#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.
#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.
Esto con Windows no pasa
#9 GO TO #7
#9 ¿Y tu como lo sabes? ¿Has visto el código fuente de Windows?
#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
#38 ¿Pero alguien deja su ordenador a alguien con su usuario logueado? El problema es el desconocimiento de la gente. En mi pc hay usuarios para todos los miembros de la familia, cada uno con sus iconitos, colorines, documentos, y aislado del resto. Y por supuesto el administrador no lo usao ni yo. Yo uso una cuenta de usuario avanzado y el resto usuarios a secas. Y ni un problema jamás. Windows no es más inseguro que linux si se usa bien, pero es tan masivamente usado que es normal que lo use gente sin saber qué hace.
#9 Con Windows no hace falta que pase, se cuelan igual
#54 Windows tiene cosas más chungas. Debido a la brutal complejidad de AD y su homogeneidad, no quiero saber lo que puede ocurrir ahí si es vulnerable una parte del sistema.
#9 no, este bug casi no tiene posibilidad de ser explotado. Los avisos de seguridad de windows son mucho más graves. Un triste virus es mucho más grave que esto. Ya sabes que hay verdaderos ejércitos de bots que son windows, como puede ser el de tu casa, a disposición de los crackeres/hackers que los han capturado y pueden lanzar desde ellos un ataque cuando quieran, como pueden tomar el control de la máquina y leer cualquiera de sus datos. Y muchas veces el usuario ni se entera.
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.
#34 https://encrypted.google.com/#q=filetype:sh+:inurl:cgi-bin
#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.
#66 bueno tampoco es tanto, 14 paginas, aunque algunas del gobierno de USA jeje
#68 cierto, pero bash es la shell por defecto en casi todo, asi que mi estimación pseudo-cientifica es que el 99% son de bash.
#69 " cierto, pero bash es la shell por defecto en casi todo, asi que mi estimación pseudo-cientifica es que el 99% son de bash. "
Lo dudo, hay más dispositivos no-PC's que sistemas de escritorio. Y no, Bash no es la shell por defecto, ese bloat de GNU no cabe en dispositivos reducidos ni de coña.
GNU Libc, menos.
#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.
#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.
#68 Es solo una prueba de concepto de posibles vulnerables,se perfectamente que sh no es solo bash, esa forma de contestar tan prepotente te la guardas.
#78 No, el uso de GNU bash es totalmente ridículo en dispositivos empotrados.
Como mucho la vulnerabilidad es jodida de verdad en servidores.
Y repito, como el otro "lissssto", en otros UNIX bash ni está como base ni se le espera. No está ni glibc por defecto para muchas cosas.
#79 http://www.cpfirewall.com/how-to-connect-on-cp-splat-or-gaia-gw-with-sftp-scp-client/ este tambien es irrelevante ?
#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.
¿Alguien que lo explique en cristiano para los que usamos Linux pero no somos expertos?
¡Gracias!
#26 $ apt-get update
#29 Gracias, he puesto el Synaptic a actualizar y ahí me aparece el parche.
#29 apt-get update && apt-get upgrade
#29 #47 O
$zypper ref && zypper up.
No sólo de apt-get updatevive el hombre...
#63 yum update
#63 #29 #47 #70 sudo
#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.
El titular es sensacionalista porque no afecta a Linux, solo afecta al 99% de las distribuciones Linux.
#59 GNU/Linux. En otros dispositivos está Linux sin bash tan alegremente. Routers, móviles, teles...
En ubuntu sacaron el parche hace más de 20horas http://www.ubuntu.com/usn/usn-2362-1/ solo tienes que actualizar el sistema
#25 Son dos fallos en realidad, lee el artículo, ese solo parchea el primero.
#25 #33 Cierto solamente corrige el primero. Lo acabo de comprobar.
Errónea, al menos el titular...
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
#71 Nueva vulnerabilidad en Bash. Esa es la correcta. Hay Linux que funcionan sin 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...
¿Quién es listo que permite funciones como variables ?
#18 has oído hablar de la programación funcional?
javascript:
var hi = function() ;
ruby:
hi = lambda
etc etc…
Se puede liar parda
pero bueno, unas horas, y ya empiezan a aparecer parches
#2 Ya se esta liando parda, hay PoC y exploit por todos lados
#2 El parche no esta completo, y se pueda saltar
#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.
#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.
#61 ya, lo que pasa es que un titular no puede ocupar cuatro fascículos de enciclopedia. Se acepta que se omita cierta información siempre que esté luego correctamente explicada.
#71 Sin duda. Pero sintetizar, omitir o resumir. Pero en este caso es un titular falso.
¿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#55 ¿Con Bash? Ninguno, todos usan busybox.
#57 Cygwin no emula, y con Msysgit (git para Windows) tienes Bash de regalo. O , sorpresa.
#58 Wine es acrónimo de "Wine Is Not an Emulator"
#60 Me refiero a que no carga binarios de Linux. Es un shell portado a Windows, nada más.
Con Cygwin los binarios siguen siendo Win32 + capa Cygwi.dll por si quieres compilar algo de Unix como BSDgames.
#58 cigwyn no viene por defecto en la instalación de windows
#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.
#87 ahora que me recuerdas lo de andoid.
Se sabe si afecta a iphone?
Para funcionar, los programas necesitan datos. Supongamos un servidor de Internet que llama a un script de bash para generar una página web
http://upload.wikimedia.org/wikipedia/commons/8/81/Roto2.svg
#48 En Plan9 puedes llamar a la shell rc(1) como WSGI . Por ejemplo, en WERC, un "anti-framework " . Pero ni de coña es tan inseguro como lanzar Bash.
Yo entiendo que el fallo es muy grave especialmente para los que estén usando Bash como CGI, por ejemplo. En el uso más normal de Bash como Shell local o remota no veo un fallo grave (no hay escalada de privilegios, los comandos inyectados entiendo que se ejecutan en el mismo espacio de usuario que Bash).
Y no puede hablarse propiamente de un fallo de Linux o de OSX. Sería el equivalente a que PHP permitiese ejecutar comandos arbitrarios a través de peticiones GET, muy grave (mucho más que éste, ya que se usa mucho más), pero no un fallo del sistema operativo.
Cada vez que sale una noticia de seguridad esto se vuelve una mierda.
Que yo sepa, RedHat/Centos y Ubuntu ya tienen actualización del paquete que anula el Bug. Y las demás importantes supongo que también tienen ya la correción hecha.
duplicada:
https://www.meneame.net/go?id=2261396
me cerraron por mi primer comentario
Censura en méneame
Creo que este artículo describe bastante bien el riesgo real de este bug tanto para servidores como clientes:
Linux, OS X hit by Shellshock Bash vulnerability [ENG]
http://www.bit-tech.net/news/bits/2014/09/25/shellshock/1
En concreto en el cuarto párrafo:
The flaw stems from poor handling of user-supplied variables, which can be abused to execute arbitrary code in the context of the affected user or application. For Bash uses like remote access via SSH, this is a minor issue: access to exploit the vulnerability still requires that the user authenticates with valid credentials, meaning it's little more than a jailbreak exploit for those with restricted accounts. A more serious configuration is in web servers which pass user-supplied information through to a Bash shell in order to execute a program or script; these, experts have warned, can be readily exploited to run code under the context of the web server process - potentially leading to file leakage that could reveal user account information.
Los parches NO ARREGLAN AL 100% el problema. Y lo entiendo, no se puede andar a la ligera corrigiendo el parser de bash, pueden destrozar mucho más de lo que arreglen. Me dedico a estas cosas y es muy delicado tocar esta pieza...
#49 Otras shells no tienen ese problema al no parsear las funciones en variables tan a la ligera. Hay mundo más allá de GNU Bash.
Uff, esta https://www.meneame.net/go?id=2261838 llegó un minuto antes, aunque a mi juicio es menos completa.
#3 bastante menos
En lo que respecta al uso de Bash en CGI a mí me parece un poquito temerario usarlo para algo serio y parseando variables con él. Nunca se me ha pasado por la cabeza que Bash fuese algo seguro per se, aparte de que es tan tremendamente incómodo de programar que para cualquier cosa un poco compleja tiraría de PHP o Perl o lo que sea. Me sorprende que haya tantas web usando Bash como CGI.
Y ahora el lisssto me dirá de Apache en OBSD, como si lo viera.
¿El mismo apache que OBSD mantiene en la BASE del sistema operativo y no requiere de Bash para funcionar? También lo cambiaron a NGINX, así que bash tampoco está, ni nada GNU como base, que les da urticaria a esa gente.
De hecho para usar Bash en OBSD tuve que instalarla explícitamente tras instalar Gnome. No digo más.
También es una vulnerabilidad para Windows si tienes instalado Cygwin. Creo que se debería corregir el titular porque es incorrecto. No es una vulnerabilidad solo para OS X ni Linux, aunque el titular seguro que así vende mucho más.
#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.
#12 ¿Sensacionalista un exploit remoto en todos los Unix y sus derivados?
#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.
#13 ¿"Exploit remoto"? Deja que me descojone
Esto es usar bash como siempre se ha usado, desde que bash es bash, y el que no sepa usarlo... pues mira, que se dedique a otra cosa. Ni exploit, ni remoto, lo que es esto es UNA ESTUPIDEZ
#12 Pues el que mira el dedo eres tu, que porque el titular lo haga mas entendible al publico que no sabe lo que es bash, lo descartas...
#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.
#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.
#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.
#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.com#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.
#119, vale, ahora pon lo que he dicho en #114 en contexto con el mensaje #12
#11 iba a decir lo mismo.
#7 claro... alguien ha soltado algún maletín para que omitan Windows del titular.
Vosotros y vuestro victimismo...
#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.
#39 ... Para OSX y Linux. En ningún momento dije "de" osx y Linux
#31 los fallos de seguridad de windows no pueden subir a portada.
Es una simple cuestión numérica.
#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
#57 Si el fallo es estrictamente de Windows, probablemente sea un fallo de implementación que estará ausente en esos dos. O al menos no necesariamente presente.
#7 eres un poco tonto amigo. Bash es linux, lo utiliza todo el mundo en esos sistemas. Cygwin en Windows lo utilizan 3 frikis de ordenadores como tú.
Otro talibán con venda en los ojos
Y eso que Linux es mucho mas seguro que Windows
Es gravísimo. Es más esto en parte tira por tierra lo de la seguridad de Linux, menos mal que al menos se reparará pronto.
Salu2
#8 Diras la seguridad de Bash.
Linux tiene sus propios exploits
#53 y #77 Lo decía porque Linux lo instala por defecto. Al menos en Kubuntu se instala por defecto. Y sí es un riesgo que afecta a la seguridad de todo el sistema debilitando la seguridad del mismo.
Por otro lado ya lo están explotando:
http://about-threats.trendmicro.com/us/malware/ELF_BASHLITE.A
Salu2
#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.
#77 Bash no es solo "una aplicación"