Web Analytics
Conecta con nosotros

Noticias

Un bug en Bash puede crear un agujero de seguridad en OS X y Linux (Shellshock)

Publicado el
Vulnerabilidad en Bash afecta a Linux y OS X

Vulnerabilidad en Bash afecta a Linux y OS X

Una vulnerabilidad ha sido descubierta en GNU Bourne Again Shell (Bash), el intérprete de comandos usado por muchos sistemas Unix y Unix-like, entre ellos Linux y OS X, convirtiéndose en un “problema especialmente peligroso, ya que hay muchas maneras de poder usar Bash a través de una aplicación”, según un aviso de seguridad de Red Hat.

El bug fue descubierto por Stephane Schazeblas, y está relacionado en cómo Bash procesa variables del entorno dictadas por el sistema operativo o bien por un programa que llama a un script. Si Bash ha sido configurado como el intérprete de comandos por defecto, puede ser usado por hackers contra servidores y otros dispositivos Unix y Linux vía web, SSH, telnet o cualquier otro programa que ejecute scripts en Bash. Debido a su alcance muchos lo han comparado con Heatbleed, aunque parece que no es tan peligroso, afectando desde la versión 1.14 hasta la 4.3 de GNU Bash.

Algunas de las mayores distribuciones Linux ya han liberado parches para corregir el fallo, donde se pueden destacar las siguientes.

  • Red Hat Enterprise Linux (versiones de la 4 a la 7), incluyendo las versiones de Fedora que actualmente tienen soporte.
  • CentOS (de la versión 5 a la 7).
  • Ubuntu en todas las versiones LTS desde 10.04.
  • Debian.

Como ya hemos mencionado, aparte de ser usado localmente, Bash puede ser usado por muchas aplicaciones, como la ejecución de scripts CGI a través de mod_cgi y mod_cgid. Una simple solicitud a un servidor Apache dirigido a un script CGI vulnerable es suficiente para ejecutar código en el servidor, y con similares procedimientos también se puede atacar desde OpenSSH, que podría saltarse las barreras de seguridad, e incluso un servidor de DHCP configurado con fines maliciosos si un sistema Linux u OS X se conecta a él a través de la red a la que suministra las IP. Podríamos seguir mencionado servicios y no parar, como por ejemplo también CUPS, el servidor de impresión que usan tanto OS X como Linux.

Saber si un sistema es vulnerable es muy sencillo, ya que solo hay que ejecutar una línea de comandos para comprobarlo:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Si el sistema es vulnerable dará el siguiente resultado:

vulnerable
 this is a test

Mientras que un sistema que no esté afectado o parcheado mostrará lo siguiente en pantalla:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Se recomienda actualizar cuanto antes Bash a una versión con el bug corregido, en el caso de las distribuciones Linux y OS X tendría que venir con las actualizaciones del sistema.

[Actualización]

Según indican en ArsTechnica, el parche liberado parece no haber resuelto del todo el problema, llamado ahora Shellshock, haciendo saltar todas las alarmas, ya que Bash sigue siendo vulnerable a ataques.

Algunas empresas están padeciendo ataques a sus servidores a través de botnets que intentan aprovechar la vulnerabilidad.

Parece que el asunto era más serio de lo que parecía al principio.

[2ª actualización]

Tanto Red Hat como Ubuntu han liberado un segundo parche, así que los más probable es que ya esté disponible para al menos todas las distribuciones Linux más relevantes.

Nos mantenemos a la expectativa.

97 comentarios
  • Xbit

    Ea, ningun sistema es perfecto o invulnerable.

  • Babosita Mimosina

    Lo que es flipante en realidad es el hecho de que descubran bugs supuestamente importantes en código que lleva la tira de años y que es tan usado. ¿Qué pasa que nadie se da cuenta?.

  • Leonmafioso

    seguro los gobiernos si se dan cuenta y llevan años explotandolo.

  • unikutya

    la gente de MuyUbuntu siempre haciendo guerra sucia contra Debian, porque en todas las Distro escriben las versiones afectadas y en Debian ponen sólo «Debian»? cómo si todas las versiones fueran afectadas? Este problema fue corregido en la versión estable de Debian, la de pruebas y la inestable, es decir, el problema esta hasta Debian 6 Squeeze, en Debian 7 Wheezy, Debian 8 Jessie y Debian Sid, el problema fue corregido .

  • Lo sorprendente en realidad es la velocidad con la que corrigen los problemas en linux, ayer fue que leí por primea vez sobre este problema y realize el test y me dio que era vulnerable.
    Acabo de actualizar el sistema y volví a realizar el test y ya no lo es…
    Como dice Xbit, ningún sistema es perfecto, lo perfecto es la velocidad con que los arreglan.

    Uno de los motivos por el cual comencé a usar este SO.

    Saludos

  • Pipo Unix

    Ubuntu en todas las versiones TLS desde 10.04. es lts no tls (long time support) se entiende no !!!!

  • Zorencen R

    Un error Humano, pero si, creo que todos lo entendimos.

  • YoMismo

    https://security-tracker.debian.org/tracker/CVE-2014-6271
    Está corregido en squeeze (lts), wheezy (security) y sid.
    Siguen afectados: squeeze, wheezy, jessie

  • Gracias por el reporte.

  • roader

    Es una vulnerabilidad menor , permite modificar una variable , pero de todos modos , no tienes privilejios , alarmismo injustificado , como siempre pasa con una vulnerabilidad de este estilo . Sin contar que muchos servidores usan sh o ksh …

  • roader

    Que en realidad es importante , solo te permite modificar una variable , ademas el codigo corre sin privilejios , por lo que no puede hacer casi nada … Alarmismo como siempre .

  • roader

    Hombre , realmente esto es una vulnerabilidad menor de la que se ha hecho mucho alarmismo . Poco puedes hacer modificando una vulnerabilidad y que corra sin privilegios de root …

  • isorfe

    Pues no, claro que no, pero lo importante aquí es lo rápido que es corregido. Me gustaría contrastar la velocidad del parche en Linux frente a MacOS X.

  • Xbit

    El problema es si ese bug te permite escalar permisos. Ahi hablamos de palabras mayores.

  • kornival

    El «casi» ese es el problema. El bug lleva aprovechándose bastante tiempo.

  • Como eliminar todos los archivos personales de una persona, cosa que no necesita dichos privilegios y que son los archivos que realmente importan.

  • Pasa Heartbleed, que todavía sigue sin ser corregido al 100%.

  • Xbit

    Como hearthbleed o el de las X

  • kornival

    Y los que quedarán por descubrir.

  • pillabichos

    Actualizando…

  • pillabichos

    Con lo ‘tranquilos’ que estabamos con el windows… ojos que no ven.

  • kornival

    Hablo en general, pero siempre tiene que aparecer el comentario de «aludidos», como si de una acusación se tratara el nuestro. ¿TANTO DUELE?. ¿O es que comentar errores sean de quien sean es un ataque?. Deberíais hacéroslo mirar, a algunos un buen pediatra, a otros un diazepam.

  • ergo

    No es que duela, es que solo se ponen ejemplos de errores de software libre, pero la verdad es que son los últimos que se han filtrado en los últimos meses. Estoy seguro que no se debe a que el soft libre tenga más errores, sino que TODOS los errores que se conocen de este sale a la luz, al contrario que el privativo, que a saber cuales ha habido críticos y no nos hemos enterados siquiera de la actualización.
    Cosa a parte es la velocidad de corrección, tanto de HeartBlead como este, de pocas horas, igual que el fallo tan grabe del monitor del sistema (o como se llame) de XP que tardo mes y medio si mal no recuerdo en publicarse la actualización.

  • MoDeM ThUg

    No es por nada pero he actualizado y sigo con el problema

  • Xbit

    Hearthbleed se conocia desde 2012…

  • No se ahora, espero que ya lo hayan liberado, pero por las fuentes que manejé cuando ya estaba el artículo para publicarse indicaban que no era así, cuando en Linux ya estaba parcheado.

    Espero que a estas alturas ya lo esté, porque sino Apple va a confirmar todas mis sospechas en torno a esta empresa en materia de seguridad.

  • Irvandoval

    La actualización de la noticia deja un mal sabor de boca la verdad, no seria buena medida cambiar el shell de los servidores provisionalmente?

  • Francisco Monge Aguilar

    De hecho ya he visto dos actualizaciones en Debian referentes a Bash, supongo que corrigiendo el problema

  • no para mi uso zsh como shell :v

  • MaximoGeek

    Pppppppero ppppperoooooo si linux es Unix, si es el sistema operativo más seguro del mundo!!!! Jajajajajaja, OS X es Unix!!!! es seguro!!!! Jajajajaja, la verdad ya estaba esperando a que publiquen esta noticia para reirme un poco.

    Lo que me sorprende es que hayan comentarios que digan la rapidez con la que se parchó, jajajaja claro después de al menos 4 años jajajaja, que no es un error de gran alcance, pffffff, señores, por más que vengan con la excusa infantil de que hay miles de ojos viendo el código y demás este aún tiene errores garrafales como este que permite una escalación de privilegios, deberían afrontar la verdad de que no existe sistema operativo seguro y por lo visto este gran sistema operativo cien por ciento «seguro» tiene sus fallas que ya datan de años y que recién se dan cuenta, un sistema operativo que se ejecuta en línea de comandos en una gran mayoría de aparatos o servidores si quieren decirlo que otorga los privilegios no deseados a usuarios desconocidos, así de simple.

  • MaximoGeek

    Cómo puedes decir que es una vulnerabilidad menor cuando son demasiados los aparatos con Linux en mera línea de comandos?

  • MaximoGeek

    Exacto, por eso crearon LibreSSL, al parecer no es necesario crear viruses, troyanos o gusanos para entrarte a un sistema Linux, simplemente explotar las fallas que supuestamente no existen.

  • menxo

    bueno eduardo. no decias que linux era a prueba de balas?

  • ¿Por que la noticia de la vulnerabilidad corre como polvora, pero el parche que se hizo a velocidad como en ningún otro sistema para corregir el problema no?

  • Y peor que eso, en vez de corregir el fallo, prefieren volver a empezar. Aparentemente piensan que cambiando de nombre y versión se corrigen los problemas.

  • David Salazar

    Jajajajajajajajaajajajajajajajajajajajajajajaa…………………………….

  • David Salazar

    se nota q no leiste el articulo completo ^^

  • David Salazar

    jamas lo sera…..^^

  • Zas en toda la boca

    Toma toma toma. Que pasa linuxueros ? Donde esta la supuesta seguridad invulnerable ? Jajajajaja me troncho. Hasta algo tan sencillo como bash se le sacan fallos de seguridad, asi que imaginaros como esta el resto….
    Seguridad en linux es un truño, siempre ha sido asi, lo que da linux es una falsa sensación de seguridad y yo añadiria y Farsa de farsantes también.

  • Lo comprobaré, mira lo que cayó ayer y yo malo en la cama.

    Voy a investigar.

  • menxo

    tu sabes. eso de unix ¬¬

  • La verdad es que esto es muchísimo más que vergonzoso.

  • Cuando publicó aquello el artículo no estaba actualizado.

  • Xbit

    No digas eso, que te tachan de hereje informatico y te tiran a la hoguera o a los cocodrilos!

  • El articulo lo actualizaron luego de mi comentario, aun así.

    Acabo de realizar nuevamente el test y me sigue saliendo que todo esta OK, así que no se si habrá otro test para verificar que siga con problemas.

    Al parecer la actualización que tengo funciono.

    ╭─daniel@desktop /home/daniel
    ╰─$ env x='() { :;}; echo vulnerable’ bash -c «echo this is a test»
    bash: aviso: x: ignoring function definition attempt
    bash: error al importar la definición de la función para `x’
    this is a test

  • Mark

    al aumentar la popularidad de linux obiamente los ataques empezaran a manifestarse en estos lares, si no; miren a android.

    ni modo empezemos a acostumbrarnos con soluciones de antivirus.

  • Fernando Iñiguez Anda En Skate

    Estaría bueno que testees tu ortografía también.

  • Gracias por el consejo, tratare de tenerlo en cuenta.

  • gfx

    No eso no es cierto, cuando salen actualizaciones críticas para Windows, por ejemplo, les dan con todo y sí que todo mundo se entera, se pueden ver los parches en el Windows Update con su fecha y todo.

  • Todavía no se ha liberado el parche para corregir en OSX … je je je lo hermoso del caso es que cuando apple lo corrija saldrá en todos los titulares, pero no saldrá que en GNU/LINUX ya estamos listos.

  • roader

    Si , y , primero , deberia de correr en sandbox , segundo , no se si conoces la politica de permisos de Unix , practicamente no te dejaria hacer nada . Menos algo peligroso . Lo maximo , una bomba fork con bash .

  • roader

    ¿Conoces la politica de permisos POSIX? Sigues sin poder hacer mucho sea el caso que sea , sin contar que deberia correr en sandbox , si no , problema del sysadmin .

  • roader

    SI y no , en teoria puedes escalar permisos , pero solo si un script ejecutado como root es expuesto al usuario , en cuyo caso , el sysadmin merece ser ejecutado … Digo , despedido

  • gustavo m

    Nadie es perfecto, pero nadie es tan imperfecto como Windows 🙂

  • Nillo

    Pues ha dicho que no afecta OS X, me hacen reír, que si lo de las llamadas en iOS sin permiso era culpa de los desarrolladores, que si lo de iCloud fue culpa de los famosos por poner contraseñas débiles y ahora esto. Apple, la reina de las excusas.

    http://www.applesfera.com/os-x/shellshock-la-vulnerabilidad-de-bash-no-afecta-a-los-usuarios-de-os-x-segun-apple

  • Xbit

    Segun me he documentado con que simplemente se ejecute un script de un servicio o binario en bash ya es vulnerable de por si, asi que la escalada de privilegios es en si un hecho. Puesto que puedes meter un keylogger y robar credenciales. Chunga la cosa mijo…

  • Xbit

    No da privilegios no deseados realmente este bug, pero si es explotado se puede llegar a producir una escalada. Me he documentado un poco lel. Se necesita ejecutar algo que termine llamando a bash para poder aprovecharlo, como scripts.

  • roader

    Pero si el script corre en sandbox como debe ser se neutraliza el problema , ademas , lo que pueda registrar el keylogger queda limitada al propio shell, por lo que es extremadamente improbable que eso ocurra, por que , salvo excepciones , estos scripts no corren en shells interactivos . Ademas , aunque fuese interactivo , no tendria mucho sentido introducir la contraseña de root ahí . Como he dicho , es una vulnerabilidad menor , porque solo afecta a personas que ya de por si hacen las cosas mal . En la seguridad informatica , hay que dar por hecho que todo software es vulnerable .

  • roader

    Dime un ordenador que aguante un balazo … Na , esta es una vulnerabilidad que solo te afecta si estas haciendo algo mal de antemano , mucho alarmismo , como con cada vulnerabilidad un poco grave descubierta .

  • Xbit

    No tiene porque quedar limitado al propio shell, si se mete un keylogger lo mas probable es que registre todo lo tecleado. En fin…

  • roader

    Has investigado sobre LibreSSL ? Mira esto : http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html

    PD : Apuesto a que el proximo fallo esta en glibc , lastima que ya tenemos forks …

  • roader

    Vamos a ver el esquema multiusuario POSIX es bastante complejo , asi que un keylogger no tiene manera de acceder a la entrada en cualquier otro shell salvo que tenga privilegios de root , Si a esto le sumas que SIEMPRE DEBERIA estar en un sandbox … Lo dicho , la culpa es de los sysadmins , todo software tiene vulnerabilidades , aprended como prevenir que te afecten es importante tambien . (y no hablo de pax , grsecurity , selinux … Eso es tan seguro que asusta )

  • En mi blog puedes ver una opinión similar.

    Y si, ya hemos cubierto algo sobre la opinión de Apple, patético, tirando balones hacia fuera, cuando creo que en OS X puedes hacer sudo.

    Yo ya lo he dicho mil veces, la política de seguridad de Apple es de risa, ni siquiera reconocen un fallo cuando es evidente.

  • juancarlos

    La creatividad a la hora de pensar/escribir están entre dicho. Porque antes de escribir piensas un poco en que microsoft no anda finos en cuantos a bugfix se refiere.

  • Xerix

    Me sorprende lo sensacionalistas que se vuelven este tipo de noticias.
    Me parece una exageracion toda esta clase de alarmismos.
    Han existido en el pasado otros bugs de seguridad y solo por un error en bash, muchos definen la seguridad en GNU/Linux como un fraude.

  • pillabichos

    Es que tienen ganas de que haya un error grave de verdad que deje sistemas libres inoperativos como la reciente actualización de iOS y la más lejana actualización que dejaba Office inoperativo aunque se desinstalar y volviera a instalar o se limpiara el registro.
    En fin, lo que se deberían hacer mirar algunos es esa obsesión con su ballena blanca que es el software libre y los que queremos disfrutar de opciones distintas a las que nos imponen la industria.

  • pillabichos

    No solo es cuestión de popularidad sino de oportunidad, los que seáis más mayores recordaréis que había virus en el MSX y no en el Amstrad CPC y el Spectrum que eran mucho más populares.

  • pillabichos

    Por cierto, a mi me sale el test negativo en todos los GNU/Linux que tengo.
    La actualización lo soluciona.

  • pillabichos

    Si hubieras programado en tu vida sabrías que nada es completamente invulnerable, lo importante es la respuesta que se ha dado, lo usuarios de otros sistemas basados en unix tendrán que esperar un poco más.
    ¿Por qué estamos actualizando continuamente? Por si ocurre algo así, aunque en otros sistemas además hay que alquilar una licencia de antivirus, limpiar el registro, mucho cuidado con el crapware cuando te descargas cualquier programita, los pendrives de amigos, IE, etc…
    En cualquier caso el elemento más peligroso de cualquier sistema operativo es la falta de sentido común de su usuario.

  • pillabichos

    Será por eso que tanto les interesa que sigamos usando otros sistemas, más agujeros más espionaje.
    Aunque también está el tema de la corrupción y la ‘neutralidad tecnológica’.

  • Luis Cristian Rodriguez Cantu

    Si como si fueran tan inteligentes….

  • Luis Cristian Rodriguez Cantu

    pero explicame como hacerlo para acceder al servidor de disguiss por ejemplo….a me vas a decir que corre en windows server….

  • Xbit

    El alarmismo se produce porque se pueden colar en servidores y liarla gordísima. Es algo natural.

  • Xbit

    Lo han corregido rápido tras dar la alarma si, sin embargo, hay reportes de ser ya un bug aprovechado con anterioridad.

  • Xbit

    Lo de las famosas parece no haber sido un gran ladrillo en su tejado. La próxima seguro se tiran huevos a sus puertas o ventanas.

  • Xbit

    Nadie dice que sea un fraude la seguridad de Linux. Pero es alarmista por ser un bug aprovechable fácilmente para atacar o robar datos. Y eso si es muy grave.

  • Xbit

    Por muy sandboxeado que este, si alguien es bueno se salta todo tipo de mecanismos de seguridad creados (incluidos los enjaulamientos o sandboxeado, selinux, pax, DEP y otros mecanismos de seguridad).

  • Xbit

    Peligro pelirgro: diazepam! que algiuen nos quiere matar con un rifle con mira telescópica! dios mio sálvame! (soy imbécil, porque me pido a mi mismo que me salve?).

  • Xbit

    Y forks de forks… ese es el problema. Menos forkear y mas colaborar.

  • Zas en toda la boca

    No uso microsoft asi que el que queda en entredicho eres tú. Y no desvies el tema. Tiene fallos y punto.
    Y para pillabichos, no desvies el tema tú también. Y me la pela la respuesta antes ó despues, llevan más de 4 años con ese fallo !!!
    Unos vende motos, que si linux esto que si aquello y bla bla bla at infinitum…
    Tiene fallos y punto, te aguantas.
    Y no teneis argumentos validos ni moral para contradecirlo, asi que pues eso aguantaros y ya.

  • Una duda, al publico en general y a los de Muy computer, desde que se dio a conocer esta vulnerabilidad hasta ahora…

    ¿Alguien se ha enterado de que algún servidor haya sido afectado o atacado utilizándola?

    Porque si fuera tan grave, de seguro habríamos oído alguna noticia en la web sobre algún ataque utilizando esta vulnerabilidad que tan peligrosa y dañina aparenta ser por los comentarios que he leído estos últimos días.

  • Leonmafioso

    Ponte a creer que los gobiernos no son inteligentes, tonto es aquel que piensa que alguien o algo es tonto.

  • Luis Cristian Rodriguez Cantu

    Son inteligentes para robar. Pero si hay algo que usan para espiar, ese algo es Windows y Mac.

  • Luis Cristian Rodriguez Cantu

    Si el error ya esta corregido.

  • Luis Cristian Rodriguez Cantu

    Yo tambien uso zsh.

  • Andrés Necochea

    Mucho se ha hablado de este error, pero hasta el momento ningún medio ha explicado en qué consiste el error y cómo puede afectar a un servidor o computador doméstico.

    Yo entiendo bastante poco, pero en mi ignorancia intentaré explicar lo poco que entiendo.

    Hasta dónde yo sé es un error en la sintaxis de bash, típicamete bash
    interpreta las variables como texto, por ejemplo, si yo defino una
    variable como sigue:
    env var=»hola; ls -l»

    la cadena «ls -l»
    es interpretada como texto y no se ejecuta. Pero ante una secuencia
    específica de caracteres, bash se tiende a equivocar, por ejemplo con esos signos de puntuación extraños:

    env var=»() {:;}; ls -l»

    Ese segmento de la cadena «ls -l» no debiese ser ejecutado, pero por un error en bash se ejecuta.

    —————————————-
    ¿qué efecto podría tener esto?
    —————————————-
    Esto es un error en la programación de bash, claramente, pero por si
    sólo no debiese afectar la seguridad del sistema. Combinado con otros
    errores en otras herramientas podría tener, en potencia, algún efecto de
    cierta gravedad. Pero por si sólo no es mucho lo que se puede hacer.
    Por ejemplo, alguien podría definir una variable como sigue:

    env var=»() {:;}; rm -fr *» /bin/bash

    En primer lugar, no creo que haya alguna persona tan torpe como para ejecutar esta línea. En segundo lugar, bash desde siempre ha permitido ejecutar comandos dentro de la definición de las variables, la diferencia es que en este caso es producto de un error, no de un diseño deliberado.

    La gravedad del problema, según entiendo, radica en lo que señalan algunos sitios, que hay scripts que definen variables de entorno y utilizan bash para esto. En Linux abundan los lenguajes de scripts (Perl, Python, Javascript, PHP, etc.) y todos interactúan con bash de miles de formas. Entre los casos más graves que se señala está el de los scripts cgi, que se usan en varios servidores de sitios webs para administrar remotamente.

    Alguien podría acceder maliciosamente a algún software de administración de servidores (cpanel por ejemplo) y definir una variable de entorno como «() {:;}; rm -fr *» y en teoría esto borraría todo el contenido del servidor.

    Pero el alcance de esto depende mucho del diseño de los scripts y las cosas que te permiten hacer, y con qué privilegios, no creo que haya servidores web con scripts cgi que permitan modificar variables de sistema sin contar con ninguna clase de contraseña. También depende, en parte, de los lenguajes que interactúan con bash y qué cosas se pueden hacer con estos.

    Algunas personas que han dicho que esta vulnerabilidad permite escalar a privilegios de administración, por lo que entiendo no es así.

    En conclusión, es un error de programación en bash, pero para que tenga un efecto tiene que sumarse con otros errores. Por lo que he leído sobre el tema, no debiese afectar a los usuarios domésticos, sólo a los servidores web.

  • Andrés Necochea

    Hasta dónde yo entiendo la vulnerabilidad te permite ejecutar comandos dentro de una variable. Pero de todas formas no puedes llegar muy lejos, en teoría puedes ejecutar cualquier comando desde un inofensivo echo, hasta un rm -fr *, que te puede complicar bastante. Pero primero tienes que tener los permisos adecuados para definir las variables de sistema, y evidentemente los permisos de lectura, escritura, con una configuración adecuada, esta vulnerabilidad no debiese afectarnos en nada.

  • Andrés Necochea

    Coincidimos en que es un error bastante gordo que paso mucho tiempo desapercibido, aunque, por regla general arreglar estos bugs es mucho más fácil que descubrirlos. Si tardaron varios años en corregirlo es porque no había sido descubierto, una vez que se descubrió y se hizo público, se corrigió bastante rápido. Lo mismo pasa en todos los sistemas, no es una justificación, ni lógica de empate, es simplemente que si te sientes protegido de hearthbleed o de shellshock por el sólo hecho de usar otro sistema operativo, te aclaro de inmediato: no estás protegido.

    Otra cosa, este fallo sólo te permite ejecutar comandos de bash en lugares donde no se debería, pero no te permite escalar privilegios. Se entiende que si no tienes los privilegios adecuados no es mucho lo que puedes hacer con esta vulnerabilidad.

  • roader

    ¡ Aleluya ! Por fin alguien que lo entiende .

  • roader

    Hombre , los forks de glibc nacen por un buen motivo , glibc esta anticuado y es demasiado grande para embebidos . Asi que de ahí nacio musl , buscando un libc mas moderno y ulibc (microlibc romanizado) utilizado en el 99% de los embebidos unix .

  • roader

    Pero en ese caso no te va atacar a traves de una vulnerabilidad tan floja . Vuelvo a afirmar que los sysadmins deben asumir que cada software tiene cientos de vulnerabilidades ,y pensar la mejor forma de protejerse de ellas.

  • roader

    Si , pero lo comparan con heartbleed (que ese si que fue gordo) cuando es un fallo menor . Si te afecta este fallo es que ya se han colado mil veces en el servidor.

  • roader

    Y el de X11 , que tambien era minimo (como mucho la curiosidad de lo antiguo que era)

  • roader

    No , eso es imposible de hacer si no se tienen permisos de root , y la verdad es que tengo mis dudas sobre si es posible aun con esos privilegios .

  • Andrés Necochea

    Voy a poner un ejemplo práctico de cómo podría afectar este bug. Imaginemos un típico script escrito en bash:

    ———————————————
    #!/bin/bash

    echo -n «Escriba su nombre: »
    read nombre
    echo «Hola $nombre, ¿cómo está?»
    ———————————————

    Este error significa, en la práctica que un script tan inofensivo como el anterior podría convertirse en un arma peligrosa en las manos equivocadas.

    El uso normal de este script sería:
    ./script.sh
    Escriba su nombre: Andrés
    Hola Andrés, ¿cómo está?

    Pero alguien malicioso podría hacer lo siguiente:
    ./script.sh
    Escriba su nombre: () { :;}; comando

    Y podría introducir cualquier comando, incluido un comando que borre todos nuestros archivos o lea nuestras contraseñas (recordemos que hay programas que guardan las contraseñas sin encriptar).
    En resumen, es una vulnerabilidad gorda y fácil de explotar, aunque, de buenas a primeras, no se puede explotar de forma remota, ni permite escalar privilegios.

  • Diego

    CEO o publicista a la vista. Dicese del que se gana la vida o sacando ventajas de la marca o del producto por cual le pagan para vender o sacando desventajas de sus competidores.

    Además en este caso con manipulaciones o demagogias que sólo cuelan para los inexpertos, porque los expertos informáticos ya saben de que va el tema y siguen usando Linux, sin entrar en más detalles estúpidos, como que no existe la seguridad 100%, por eso algunos se acojonan con las nucleares o con los protócolode de enfermedades epidémicas, porque siempre hay fallos humanos, incluso hasta en el mejor de los protocolos o sistemas de seguridad.

    Además de estos profesionales o publicistas, en esta misma profesión existe una ideologia por interés personal contraria a la ideología de la libertad del software libre: Porque estos publicistas viven de la desinformación, de la opacidad o manipulación o medias verdades o supercherías o supersticiones o falsas correlaciones o falacias o sofismas bien presentados, y claro cuando se le presenta una ideología que defiende la cosas claras y el chocolate espeso que vela por toda transpariencia porque la libertad se basa en la verdad: «La verdad os hará libres»: Pues no sólo atacan en cuanto puedan con supercherías o manipulaciones de medias verdades al producto, sino que atacan a toda su filosofía.

    La vida y parece que más en España está llena de crétinos y falsos, que cuando llegan al mundo comercial toman su trabajo como el arte de la mentira y la manipulación, porque creen que comerciar es engañar, más si no pueden con la competencia.

    Esto me lleva a porque los españoles no tenemos la vergüenza de dimitir cuando no somos capaces o no estamos preparados para ser profesionales, y por eso España está llena de chapuceros que no tienen la vergüenza de dimitir: Y esto se ve igualmente reflejado en sus políticos.

    Fomentado en la falsa idea de que dimitir es deshonesto y desvergonzado, la persona que dimite es la máxima demostración de honestidad y vergüenza.

    Reconozco que dimitir va contra el orgullo, pero contra el orgullo de inmadurez, porque hay que tener mucha madurez y mucho tipo de orgullo para poder dimitir reconociendo las propia limitaciones de uno.

    Pero parece que esto va más con el carácter anglosajón que tienen la vergüenza de dimitir cuando un problema o trabajo les ha venido grande y lo reconocen.

  • Pingback: PING: GhostBSD, Adobe Reader, Calibre, Matchstick, Shellshock... » MuyLinux()

Top 5 Cupones

Lo más leído