Un bug en Bash vulnera la seguridad de sistemas Linux, Unix y OS X

ElChabaldelPc escribió:pasaros a freebsd

Lo corrigieron ayer a las 5 de la tarde. Me sonó muy rara esa actualización de bash tan derepente, justo antes, había probado el pkg audit y daba todo ok, pero aun así actualicé el bash y supongo que era por esto, o tal vez ya estaba de antes solventado.

Estaría genial que las distros y demás empezaran a dar soporte a fish, mucho más comodo que el bash, pero ignorada por la comunidad

pirtugan escribió:Voy a explicar lo que he leído... y algien con carácter didactico (que no dictatorial) me explique en qué sitio me he perdido.

Intentaré aclarártelo.

pirtugan escribió:A) El problema parece que parte del bash. En la definición de una variable de entorno en el shell Bash.
B) Según lo que se publica (test incluido) el problema surge porque las variables de entorno permiten ejecutar código.

La idea es que alguien malicioso, de alguna forma (hay varias formas, pero no entraré en eso ahora mismo porque no es relevante aún):
1) consiga modificar una "variable de entorno"
2) que dicha variable sea heredada por los procesos hijos (proceso hijo = cuando ejecutas un programa, tú a mano, o un script)
3) y que uno de esos procesos hijo sea el programa bash

Punto 1) Modificar una variable de entorno.
Si tienes ya acceso al equipo, hacer esto es trivial. Pero es que si tienes ya acceso al equipo... qué más quieres? Ya puedes intentar escalar privilegios con algun exploit del kernel, borrar todos los archivos del usuario actual, o lo que quieras.
Lo jugoso es conseguir modificar una variable de entorno sin tener ya acceso previo al equipo. Es decir, acceso remoto al equipo. Por eso todo el mundo habla de "remoto", porque ahí está el mayor peligro.



Punto 2) Conseguir que los procesos hijo hereden variables de entorno

Muchos programas almacenan información en variables de entorno, como método para comunicarse con procesos hijo.


Un ejemplo es los scripts CGI ejecutados con el servidor web apache: apache pone ciertos valores en variables de entorno, y el script cgi (y sus hijos) pueden leer dichas variables. Si un script CGI quiere saber qué navegador está usando el usuario que visita la web cgi, apache le pasa el User-Agent en una variable de entorno.

De esta forma, si yo modifico mi firefox para que el user-agent no sea "Mozilla blah blah", sino que ponga "() {:;}; date", ese churro de caracteres raro va a acabar en una variable de entorno del script CGI.

Se menciona mucho los CGI porque, por diseño, se utiliza variables de entorno para comunicarse entre apache y el cgi. Una web normal (web que no sea CGI) generalmente no las utiliza. CGI es una tecnologia obsoleta, pero es util y aún existen muchos CGIs por el mundo.

Aparte, no tiene por qué ser apache+cgi. Puede que existan otras formas de conseguir el punto 1) y 2), como un servidor DHCP (del atacante) que consigue modificar las variables de entorno del cliente DHCP (del ordenador atacado), etc.
Hay 4 o 5 posibles puntos de ataque similares (aparte de apache-cgi, y de dhclient), y seguramente se vayan descubriendo más con el tiempo.


Punto 3) Que uno de los hijos ejecute bash.

Primero, aclarar que lo único necesario es ejecutar bash. No es necesario que bash haga nada en particular: por el mero hecho de haber sido ejecutado, bash ejecutará el código de las variables de entorno.

Por tanto, aquí no se trata de que el hacker consiga modificar el equipo atacado, para que ejecute bash.

Más bien lo contrario: se trata de que el hacker busca a ver qué programa hace uso de bash durante su ejecución normal. Si está intentando usar CGIs, el hacker intentará localizar un CGI que haga uso de bash. Una forma fácil de localizar cgis válidos, es simplemente intentar realizar el ataque contra todos los cgis que existan. Con suerte alguno usará bash, y podrá liarla parda.
Si no tiene suerte, el equipo, aún teniendo una versión vulnerable de bash, será inatacable por esa vía. Tendra que ver si consigue hacerlo por otro método (en vez de cgis de apache, pues con dhclient, u openssh, o lo que sea)

Total, que si hemos localizado un programa que se apoye en bash para cualquier tarea, y le hemos podido tocar las variables de entorno al programa para que bash las herede al ser ejecutado, hemos completado el ataque: podemos ejecutar lo que queramos.

En esencia, es como si hemos conseguido sacar la contraseña de acceso del usuario que ejecuta ese programa.
Si apache tiene acceso a una base de datos, en ese momento nosotros tambien tenemos acceso a la base de datos, y podemos echarle un vistazo. O podemos borrar archivos del sistema al tuntún para tumbarlo. O lo que sea.

En OSX, se demuestra por lo mismo que digo siempre que Android/OSX son MUY inseguros.

Código abierto, pero sin control, a la espera de parches, a la espera de...

En un sistema puramente libre, sale el bug y a las 2h todo el mundo, que actualice, tiene resuleto el bug. Ahora bien, si eres Apple y ahora estás más pendiente de resolver los problemas de la 8.0.1, sumado a añadir este parche al bash, tardarás días en solventar el fallo, dependiendo del alarmismo que se le de al bug.

El caso de Android es aun más gracioso, pues el 80% de los usuarios ni saben que existe la posibilidad de actualizar sus dispositivos, salvo que les salga, ese molesto mensaje de que tienen que actualizar el cual muchas veces ignoran.
Para los que me saltan, si si, mi Android yo lo actualizo, genial, te sobra el tiempo, para un móvil prefiero un código 100% cerrado, donde si sale un bug, es la misma empresa, la que me parchea directamente. Recordemos que llevamos al gran hermano en el bolsillo y ya puedes hacer lo que te de la gana, que tienes un gps/microfono/cámara... en tu bolsillo todo el día. Evidente, ya, con código cerrado pueden hacerte de todo y no lo sabes, pero existe la clave, de que si se detecta que hay ese bug y no se corrige, la gente deja de usar dicho teléfono.

STeNYaK escribió:...

Genial explicación, muchas gracias. Deberían linkearla a la noticia.

NINGÚN software medianamente grande está libre 100% de bugs

La de bugs que habrán y ni lo sabemos en todos los SO el tema esta en que es lo que instalas en el pc ni mas ni menos

En Debian todo perfect

Lotush escribió:La de bugs que habrán y ni lo sabemos en todos los SO el tema esta en que es lo que instalas en el pc ni mas ni menos

No es lo mismo, para windows hasta se crean virus que aprovechan esa vulnerabilidad, precisamente porque micro$oft no hace caso

Yo pienso que la idea de "Seguridad" esta mal en relación al sistema operativo. Si bien es cierto que hay muchas distribuciones en la actualidad, es mentira decir éste o aquel, es el "MÁS" seguro de todos; yo me inclino mejor a decir, el sistema que yo uso, como casi nadie lo usa, casi nadie lo ataca , porque el sistema no solo esta compuesto por si mismo como tal, sino que hay programas adicionales que no son siempre responsabilidad del creador del sistema, y esos programas pueden contener puertas o "bugs" que pueden ser explotados

Dentro de unos días sale Windows 9, y ni bien a caido en la mano de alguien y ya tiene crack o generador de seriales, mas "N" problemas explotados, quien puede negar, que si esto pasara con otro sistema, no harían lo mismo?

Lamentablemente hay que ser buen amigo de los parches

En Mint 16 no se soluciona actualizando.

El PS3 ejecuta bash?

uuuuuuuuuuu un bug en linux

si es lo que dijo mi profesor, si quieren estropear un S.O. da igual lo seguro que sea jejeje

apietoteae escribió:uuuuuuuuuuu un bug en linux

si es lo que dijo mi profesor, si quieren estropear un S.O. da igual lo seguro que sea jejeje

cambia de profesor D

mi linux mint ya ha solucionado el bug este

Me hacen gracia los comentarios de muchos, defendiendo la bondades de lo libre (que las tiene, que duda cabe), basándose en la rapidez del parche, o de que todo el mundo parcheará en media hora una vez conocido el problema.

Resulta que en la propia redacción de la noticia se cita de forma textual:

El descubridor del bug escribió:....amenaza tan grande como Heartbleed" debido a la extensión, antigüedad y características del problema....

El descubridor del bug escribió: ...nunca seremos capaces de catalogar todo el software que hay por ahí vulnerable al bug de Bash. […] El número de sistemas que se deben parchear, y que no lo harán, es mucho más grande que con Heartbleed

Es decir, que el propio ingeniero descubridor dice que el problema es desde el inicio de los tiempos, y que el número de afectados que no lo corregirán es inmenso.
¿Que una vez ha sido público ha sido corregido rapidamente?
Por supuesto, pero
A.: No se sabe si alguien lo conocía (y usaba maliciosamente) con anterioridad.
B.: Muchos sistemas quedaran expuestos de por vida.

Que el software libre tiene infinidad de ventajas es innegable, que sea la solución a los problemas de seguridad del mundo moderno.... No lo creo.

Por cierto, a mi también me interesaría saber si ps3 utiliza bash para algo.

Saludos.

berny6969 escribió:

apietoteae escribió:uuuuuuuuuuu un bug en linux

si es lo que dijo mi profesor, si quieren estropear un S.O. da igual lo seguro que sea jejeje

cambia de profesor D

mmm me dejas intrigado, tan seguro es linux¿?

apietoteae escribió:

berny6969 escribió:

apietoteae escribió:uuuuuuuuuuu un bug en linux

si es lo que dijo mi profesor, si quieren estropear un S.O. da igual lo seguro que sea jejeje

cambia de profesor D

mmm me dejas intrigado, tan seguro es linux¿?

Claro que si, no has leído la noticia? Es un bug en bash NO EN LINUX

no te mates mucho que pocos entienden en que consiste el bug

lo malo puede ser los dispositivos que lleven bash integrado,routers,firewalls, decodificadores de satelite etc que no va a actualizarlos

berny6969 escribió:

apietoteae escribió:uuuuuuuuuuu un bug en linux

si es lo que dijo mi profesor, si quieren estropear un S.O. da igual lo seguro que sea jejeje

cambia de profesor D

pues ya que estoy quiero aclarar una duda.

Steam Os esta basado en linux ( o lo que sea )

Steam Os tiene esa seguridad digna de linux o es mas ligero en ese tema?

pd: siento confundirme con bash, para mi todos los sistemas basados en linux (ubuntu, guadalines etc) los meto en el mismo saco

steamos esta basado en Debian es lo mismo si utiliza bash el bug lo tendra

la solucion es parchear bash o pasarse a fish

apietoteae escribió:pues ya que estoy quiero aclarar una duda.

Steam Os esta basado en linux ( o lo que sea )

Steam Os tiene esa seguridad digna de linux o es mas ligero en ese tema?

pd: siento confundirme con bash, para mi todos los sistemas basados en linux (ubuntu, guadalines etc) los meto en el mismo saco

En cyanogen ya esta arreglado el falle, un poco mas tarde de salir esta noticia

Debian 7.6 sin problemas desde el último apt upgrade. Qué lástima, le he tirado todos los PoC que he encontrado y no ha funcionado ni uno

Esta claro q no hay ningún SO impenetrable, pero la verdadera seguridad es la rápida actuación para tapar los bugs

Esto es grave, sí.

Lo actualice ayer el sistema, pero no había probado la función esa.
Imagen

pirtugan escribió:Nose... me sonó todo tan raro raro que me he puesto a mirar un poquito el tema... y mi neurona no me da para más.... Me he leido la noticia en EOL... y en serio... o igual lo contrario... se parece lo que un cojón a un cubo. Veo que esto ha ido creciendo y creciendo hasta que ha llegado aquí....

Voy a explicar lo que he leído... y algien con carácter didactico (que no dictatorial) me explique en qué sitio me he perdido.

A) El problema parece que parte del bash. En la definición de una variable de entorno en el shell Bash.
B) Según lo que se publica (test incluido) el problema surge porque las variables de entorno permiten ejecutar código.
C) La prueba hace uso de la comilla simple....
D) Potencialmente, se podría en teoría incluir codigo malicioso con dicho uso.

En las referencias que he encontrado, inicialmente se habla de la vulnerabilidad del sistema si fija esa variable de entorno. Pero luego empezaron a meter la palabra... remoto por todos lados... y ya la cabeza me empezó a dar vueltas... finalmente dicen que es muy complicado de arreglar y que está extendido por el universo conocido y más allá.


Ahora van mis preguntas que mi simple neurona no llega a entender....

A) Que yo sepa de toda la vida... el bash... cuando defines una variable de entorno, si le metes algo en comilla simple... lo ejecuta y punto.... directamente... pues es una definición del sistema.

Siendo esto así, a los que les da error la ejecución del test (no vulnerable), lamento decirles que si... parece que tienen un bash 'aparente mente robusto al fallo', pero tienen un mojón mierdoso de implementación, pues hasta el manual del bash dice claramente que tiene que ejecutarse y dar el valor del resultado de dicha ejecución a la variable.

B) Las ejecuciones son eso... ejecuciones... y claro, para definir la variable, hace falta previamente un acceso al bash. Es decir, tienes que tener acceso a él.

Efectivamente, hay programas que permiten desde una ventanita fijar variables de entorno, pero en ese caso. El que está fallando no es el bash, es el programa que permite por ejemplo meter unas comillas simples en vez de un path o ruta a un fichero y/o directorio.

C) Lo de remoto, me da un poco de pánico, pero en serio, que no lo veo por ningun lado... no se que tiene que ver ejecutar un/unos comandos en un bash a que puedan saltarse por la cara un protocolo y entrar a saco en tu ordenador (Heartbleed) y sin dejar rastro.

Aqui cuando alguien, programa con sus variables de entorno o usuario a saco en el bash mete comandos queda todo registrado a nombre del usuario que lo ha hecho. Con lo que de remoto, es que sigo sin verlo por ningún lado.

Se habla en algún momento de cgi o de ... er que??? cgi... aún hay webs o ordenadores con servidores usando cgi y creen que están seguros??? ummm no hace falta esta supuesta vulnerabilidad para saltar esa seguridad.

Por último pongo un link a donde se está discutiendo si realmente esto es o no una vulnerabilidad....

http://unix.stackexchange.com/questions ... t-insecure

Saludos

Magnífica explicación.

Africa escribió:Me hacen gracia los comentarios de muchos, defendiendo la bondades de lo libre (que las tiene, que duda cabe), basándose en la rapidez del parche, o de que todo el mundo parcheará en media hora una vez conocido el problema.

Resulta que en la propia redacción de la noticia se cita de forma textual:

El descubridor del bug escribió:....amenaza tan grande como Heartbleed" debido a la extensión, antigüedad y características del problema....

El descubridor del bug escribió: ...nunca seremos capaces de catalogar todo el software que hay por ahí vulnerable al bug de Bash. […] El número de sistemas que se deben parchear, y que no lo harán, es mucho más grande que con Heartbleed

Es decir, que el propio ingeniero descubridor dice que el problema es desde el inicio de los tiempos, y que el número de afectados que no lo corregirán es inmenso.
¿Que una vez ha sido público ha sido corregido rapidamente?
Por supuesto, pero
A.: No se sabe si alguien lo conocía (y usaba maliciosamente) con anterioridad.
B.: Muchos sistemas quedaran expuestos de por vida.

Que el software libre tiene infinidad de ventajas es innegable, que sea la solución a los problemas de seguridad del mundo moderno.... No lo creo.

Por cierto, a mi también me interesaría saber si ps3 utiliza bash para algo.

Saludos.

No te molestes, la discusion principal se basa en "linux es seguro, lo que falla es bash", "android es seguro, lo que falla es bash", "linux y android arreglan rapido, apple no" "para windows sacan virus que usan el fallo" (aunque linux no traiga bash de base), y por ultimo "apple y windows no molan porque tardan mucho en actualizar o no actualizan", a, y que no se me olvide "mi linux marca y modelo "lafuse" ya esta arreglado 2 horas despues de la noticia".

Con tal de "sentirse" seguros con que su "android" ha sido actualizado unas horas despues y su linux tambien.
Ni se paran a pensar que su router, el que les da conectividad a toda su intranet en su casa, la misma que utilizan para navegar por webs de bancos y realizar compras online a traves de sus tabletas android, o de sus sistemas operativos linux "lafuse", con un 99% de probabilidades estara afectado, y cualquier usuario con unos conocimientos minimos tendra acceso a toda su intranet, telefonos moviles, pcs, televisiones, etc... desde china, pakistan o rusia.

Ey, pero no pasa nada, que mi ANDROID ya no es vulnerable

Parece que este si va a ser el año de Linux

Claro que si, no has leído la noticia? Es un bug en bash NO EN LINUX

Es ironico ¿ verdad ?

Ingalius escribió:

Africa escribió:Me hacen gracia los comentarios de muchos, defendiendo la bondades de lo libre (que las tiene, que duda cabe), basándose en la rapidez del parche, o de que todo el mundo parcheará en media hora una vez conocido el problema.

Resulta que en la propia redacción de la noticia se cita de forma textual:

El descubridor del bug escribió:....amenaza tan grande como Heartbleed" debido a la extensión, antigüedad y características del problema....

El descubridor del bug escribió: ...nunca seremos capaces de catalogar todo el software que hay por ahí vulnerable al bug de Bash. […] El número de sistemas que se deben parchear, y que no lo harán, es mucho más grande que con Heartbleed

Es decir, que el propio ingeniero descubridor dice que el problema es desde el inicio de los tiempos, y que el número de afectados que no lo corregirán es inmenso.
¿Que una vez ha sido público ha sido corregido rapidamente?
Por supuesto, pero
A.: No se sabe si alguien lo conocía (y usaba maliciosamente) con anterioridad.
B.: Muchos sistemas quedaran expuestos de por vida.

Que el software libre tiene infinidad de ventajas es innegable, que sea la solución a los problemas de seguridad del mundo moderno.... No lo creo.

Por cierto, a mi también me interesaría saber si ps3 utiliza bash para algo.

Saludos.

No te molestes, la discusion principal se basa en "linux es seguro, lo que falla es bash", "android es seguro, lo que falla es bash", "linux y android arreglan rapido, apple no" "para windows sacan virus que usan el fallo" (aunque linux no traiga bash de base), y por ultimo "apple y windows no molan porque tardan mucho en actualizar o no actualizan", a, y que no se me olvide "mi linux marca y modelo "lafuse" ya esta arreglado 2 horas despues de la noticia".

Con tal de "sentirse" seguros con que su "android" ha sido actualizado unas horas despues y su linux tambien.
Ni se paran a pensar que su router, el que les da conectividad a toda su intranet en su casa, la misma que utilizan para navegar por webs de bancos y realizar compras online a traves de sus tabletas android, o de sus sistemas operativos linux "lafuse", con un 99% de probabilidades estara afectado, y cualquier usuario con unos conocimientos minimos tendra acceso a toda su intranet, telefonos moviles, pcs, televisiones, etc... desde china, pakistan o rusia.

Ey, pero no pasa nada, que mi ANDROID ya no es vulnerable

No te preocupes, mi router con DD-WRT también está actualizado

PElayin_5 escribió:

Ingalius escribió:

Africa escribió:......

No te molestes, la discusion principal se basa en "linux es seguro, lo que falla es bash", "android es seguro, lo que falla es bash", "linux y android arreglan rapido, apple no" "para windows sacan virus que usan el fallo" (aunque linux no traiga bash de base), y por ultimo "apple y windows no molan porque tardan mucho en actualizar o no actualizan", a, y que no se me olvide "mi linux marca y modelo "lafuse" ya esta arreglado 2 horas despues de la noticia".

Con tal de "sentirse" seguros con que su "android" ha sido actualizado unas horas despues y su linux tambien.
Ni se paran a pensar que su router, el que les da conectividad a toda su intranet en su casa, la misma que utilizan para navegar por webs de bancos y realizar compras online a traves de sus tabletas android, o de sus sistemas operativos linux "lafuse", con un 99% de probabilidades estara afectado, y cualquier usuario con unos conocimientos minimos tendra acceso a toda su intranet, telefonos moviles, pcs, televisiones, etc... desde china, pakistan o rusia.

Ey, pero no pasa nada, que mi ANDROID ya no es vulnerable

No te preocupes, mi router con DD-WRT también está actualizado

Te felicito, y te puedo mandar incluso un pin si lo quieres, me puedo permitir el lujo
Ahora, puedes ir acrtualizando el router de todos tus famliares, todos tus vecinos, e incluso el de todo tu barrio, porque ellos no lo tendran.
Linux es muy seguro

P.D.: y te rtecomiendo que, el proveedor de servicios que utilices, le hagas un test al, nodo que te de sevicio a ti (si tienes opcion de ello), porque probablemente sea vulnerable, por lo tanto su sistema tambien lo sea a traves del nodo que utilice tu ISP para darte servicio.

NewDump escribió:Parece que este si va a ser el año de Linux

Claro que si, no has leído la noticia? Es un bug en bash NO EN LINUX

Es ironico ¿ verdad ?

De irónico nada, lleva toda la razón. Hay muchos sistema Linux que no usan bash (los embebidos casi ninguno porque bash es muy pesado).

Y por cierto, salvo OSX, ningun Unix usa bash por default (ni siquiera los BSD).

Para quienes habeis parcheado el bash, no habeis solucionado el tema aún porque ya han descubierto una nueva vulnerabilidad que el parche no resuelve:

https://web.nvd.nist.gov/view/vuln/deta ... -2014-7169

Para quienes habeis parcheado el bash, no habeis solucionado el tema aún porque ya han descubierto una nueva vulnerabilidad que el parche no resuelve:

No se a parcheado nada, pero hay miles de sistemas ahora mismo vulnerables y esto no hace Linux mas seguro lo hace inseguro al igual que si fuera en Windows o en Ios

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 vulnerabilidad . En realidad , es una tontería . Mucho alarmismo .

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 vulnerabilidad . En realidad , es una tontería . Mucho alarmismo

de alarmismo nada. el que se merece Al principio, la vulnerabilidad no parece tan grave pero la realidad es que se puede ejecutarse código remoto simplemente establecimiento de una variable de entorno y sin que el usuario se percate de la situación.

El escenario más problemático parece ser cuando un Bash scripts es ejecutado mediante cgi-bin. La especificación CGI requiere que el servidor web convierta la solicitud de los headers HTTP suministrados por el cliente y las transforme en variables de entorno.

Entonces, se puede aprovechar que Apache "transforma" las cabeceras en variables de entorno: por ejemplo el User-Agent se introducirá como valor de la variable de entorno HTTP_USER_AGENT de Apache. Si un script Bash se llama vía cgi-bin, un atacante puede utilizar estas variables para ejecutar código que el servidor web.

NewDump escribió:

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 vulnerabilidad . En realidad , es una tontería . Mucho alarmismo

de alarmismo nada. el que se merece Al principio, la vulnerabilidad no parece tan grave pero la realidad es que se puede ejecutarse código remoto simplemente establecimiento de una variable de entorno y sin que el usuario se percate de la situación.

El escenario más problemático parece ser cuando un Bash scripts es ejecutado mediante cgi-bin. La especificación CGI requiere que el servidor web convierta la solicitud de los headers HTTP suministrados por el cliente y las transforme en variables de entorno.

Entonces, se puede aprovechar que Apache "transforma" las cabeceras en variables de entorno: por ejemplo el User-Agent se introducirá como valor de la variable de entorno HTTP_USER_AGENT de Apache. Si un script Bash se llama vía cgi-bin, un atacante puede utilizar estas variables para ejecutar código que el servidor web.

afecta a gente que usa cgi-bin, eso es cierto, pero no todo el mundo usa cgi, tengo varias webs y no uso cgi ni apache ni loco xD

Nirgail escribió:Joe, ni los sistemas Unix se salvan de bugs. Mucho ojo gente!

Vamos a ver... que el bug no tiene nada que ver con los sistemas en sí. La culpa no es de Unix, ni de Linux, ni de ningún sistema operativo. La culpa es de Bash y punto.

En mis servidores, con debian claro esta ya llevo 4 actualiaciones en 24 horas
Igualito que en los mac que hasta dentro de un mes no sacaran nada.

Los teléfonos que son vulnerables son los que tienen jailbreack o rooteados y luego instalado el interprete bash.

También es aplicable a routers y demás aparatos. El problema es que si tienes acceso a dispositivos aunque no tengas cuenta root puedes lanzar ataques dos y similares, o crear una buena bootnet.

Ya hay robots intentando accedes a las ips de OVH con diferentes tipos de ataques.

Africa escribió:Me hacen gracia los comentarios de muchos, defendiendo la bondades de lo libre (que las tiene, que duda cabe), basándose en la rapidez del parche, o de que todo el mundo parcheará en media hora una vez conocido el problema.
[...]

¿Que una vez ha sido público ha sido corregido rapidamente?
Por supuesto, pero
A.: No se sabe si alguien lo conocía (y usaba maliciosamente) con anterioridad.
B.: Muchos sistemas quedaran expuestos de por vida.

Da la impresión de que criticas el software libre por esos 2 puntos que mencionas. Si es así, tu crítica es válida... pero es también perfectamente aplicable al software privativo.

Es decir, en lo que se refiere a esos 2 aspectos concretos que mencionas, el software libre no es ni mejor ni peor. Pero si ademas tienes en cuenta tantos otros aspectos que existen (como la rapidez con la que se ha provisto un parche para mitigar el daño, como has mencionado), el software libre casi siempre sale mejor parado que el privativo.

afecta a gente que usa cgi-bin, eso es cierto, pero no todo el mundo usa cgi, tengo varias webs y no uso cgi ni apache ni loco xD

ya hay un gusano y todo rulando xD

STeNYaK escribió:

Africa escribió:Me hacen gracia los comentarios de muchos, defendiendo la bondades de lo libre (que las tiene, que duda cabe), basándose en la rapidez del parche, o de que todo el mundo parcheará en media hora una vez conocido el problema.
[...]

¿Que una vez ha sido público ha sido corregido rapidamente?
Por supuesto, pero
A.: No se sabe si alguien lo conocía (y usaba maliciosamente) con anterioridad.
B.: Muchos sistemas quedaran expuestos de por vida.

Da la impresión de que criticas el software libre por esos 2 puntos que mencionas. Si es así, tu crítica es válida... pero es también perfectamente aplicable al software privativo.

Es decir, en lo que se refiere a esos 2 aspectos concretos que mencionas, el software libre no es ni mejor ni peor. Pero si ademas tienes en cuenta tantos otros aspectos que existen (como la rapidez con la que se ha provisto un parche para mitigar el daño, como has mencionado), el software libre casi siempre sale mejor parado que el privativo.

Soy un gran amante del software libre, pero no emplearé argumentos de seguridad para defenderlo. No hay nada seguro y si algún sistema se libra es porque es tan minoritario que nadie se pone a investigarlo/atacarlo.

Mi "crítica" no es hacia el soft libre, del que soy ferviente defensor, sino a la hipocresía de muchos, a los que la misma noticia les sirve para argumentar en favor o en contra dependiendo del sistema vulnerado. Que es del que yo no uso, es que ya lo sabía el mio es más seguro, que es del que uso, mira que rápido lo arreglan..... Cuando el propio ingeniero que lo ha públicado admite que el error es muy grave, muy antigüo y de muy difícil solución. Y digo yo que algo entenderá de esto el buen hombre.

Saludos.

DoNPiNPoN escribió:En mis servidores, con debian claro esta ya llevo 4 actualiaciones en 24 horas
Igualito que en los mac que hasta dentro de un mes no sacaran nada.

Los teléfonos que son vulnerables son los que tienen jailbreack o rooteados y luego instalado el interprete bash.

También es aplicable a routers y demás aparatos. El problema es que si tienes acceso a dispositivos aunque no tengas cuenta root puedes lanzar ataques dos y similares, o crear una buena bootnet.

Ya hay robots intentando accedes a las ips de OVH con diferentes tipos de ataques.

Hay muchos aparatos, como dices routers, que no llevan bash, porque es muy pesado, llevan otros shells más ligeros.


Por cierto, me llama la atención cuantos "expertos" en seguridad que no saben cual es la diferencia de que este bug afecte a bash o al núcleo de linux, o que no saben siquiera si su router/consola/aparatodeloquesea lleva bash veo yo criticando linux. Curioso. (no creo que haga falta que ponga un cartel de sarcasmo, cuando utilizo expertos entrecomillado, pero vete a saber...)

No hay sistema invulnerable ni irrasteable, lo que sucede es que el dinero está en atacar sistemas Windows y en menor grado Mac.

No hay ningún sistema que no se pueda romper, aunque en este caso es solo en el interprete de comandos.
Por suerte en casi nada esta solucionado.

Siempre habra Trolls en todos los sistemas. Los de windows diciendo que unix, linux, BSD y derivados son una mierda, y los talibanes deel software libre.... hay grises entre el blanco y le negro...

saludos

Ya han actualizado bash en Raspbian para la Raspberry Pi, me extrañaba que siendo Debian tardasen tanto.

Africa escribió:Soy un gran amante del software libre, pero no emplearé argumentos de seguridad para defenderlo. No hay nada seguro y si algún sistema se libra es porque es tan minoritario que nadie se pone a investigarlo/atacarlo.

De acuerdo en lo segundo. En cuanto a la seguridad, la opinión generalizada (no en los foros, sino de los expertos de criptografía y demás) suele ser que un sistema de código abierto que ha sobrevivido al escrutinio de la comunidad suele ser más seguro que un sistema cerrado (todo el rollo de la seguridad por oscuridad y tal).

Africa escribió:Mi "crítica" no es hacia el soft libre, del que soy ferviente defensor, sino a la hipocresía de muchos, a los que la misma noticia les sirve para argumentar en favor o en contra

100% de acuerdo (aunque a menudo los que argumentan a favor y los que argumentan en contra son grupos diferentes de gente, a los que incorrectamente metemos en el mismo saco, y así no nos queda otra que tratarlos de hipócritas )

Resuelto ya en Slackware Linux

http://www.slackware.com/changelog/stable.php?cpu=i386

Todo software es suceptible de tener fallos, por la sencilla razón de es escrito por humanos. La diferencia radica en que en Linux los errores se corrigen inmediatamente y en otros sistemas operativos no. Hasta dudo de la intencionalidad de algunos supuestos "fallos" en Windows.

Africa escribió:Mi "crítica" no es hacia el soft libre, del que soy ferviente defensor, sino a la hipocresía de muchos, a los que la misma noticia les sirve para argumentar en favor o en contra dependiendo del sistema vulnerado.

Pero es que se dicen cosas falsas!!!! Es un fallo de BASH un shell de entre los cientos que existen en el mundo unix!!!

No es un fallo de Linux y mucho menos un fallo de de Unix porque el 99% de los Unix no usan bash!! (ni AIX, ni HP-UX, ni Solaris, ni FreeBSD ni OpenBSD llevan bash por default... todos usan sh, csh o ksh!!). El único Unix que lleva Bash por default es Mac OSX y apartir de Panther (antes usaba csh). También existen muchos Linux que no usan bash por default, los embebidos tiran de BusyBox en el 99% de los casos. Decir que es un problema "de linux" es MENTIR.

Algunos en el afan de defender los DESASTRES de Windows buscan cualquier tontería para justificar lo injustificable. A mi me la suda Linux, soy usuario BSD y Mac, y de hecho Linux me parece un sistema NEFASTO en muchos aspectos... pero joder al Cesar lo que es del Cesar!!!

Esto es un no parar. Hace nada los que teníamos un NAS Synology estábamos acojonados. Ahora de nuevo esto. Es uno de los grandes problemas del mundo de internet y debería ser todo mucho más seguro.

Actualizado ayer en Linux Mint 17, problema resuelto

anikilador_imperial escribió:

Klaudcito escribió:Pásate a Linux decían...Es seguro...

Y en 12 horas se ha solucionado el bug en todas las distros importantes ese es el poder de Linux. En cuanto se encuentra un bug es inmediatamente erradicado, porque cualquiera puede arreglarlo. Software libre

Por eso mismo, ese poder del software libre que comentas es un arma de doble filo. Igual que cualquiera puede arreglarlo, cualquiera con no buenas intenciones puede estropearlo.