stringtranslate.com

Shellshock (error de software)

Shellshock , también conocido como Bashdoor , [1] es una familia de errores de seguridad [2] en el shell Bash de Unix , el primero de los cuales se reveló el 24 de septiembre de 2014. Shellshock podría permitir a un atacante hacer que Bash ejecute comandos arbitrarios y obtenga acceso no autorizado [3] a muchos servicios conectados a Internet, como servidores web, que usan Bash para procesar solicitudes.

El 12 de septiembre de 2014, Stéphane Chazelas informó al encargado de mantenimiento de Bash, Chet Ramey [1], de su descubrimiento del error original, al que llamó "Bashdoor". Trabajando con expertos en seguridad, Chazelas desarrolló un parche [1] (corrección) para el problema, al que para entonces se le había asignado el identificador de vulnerabilidad CVE - 2014-6271 . [4] La existencia del error se anunció al público el 24 de septiembre de 2014, cuando las actualizaciones de Bash con la corrección estaban listas para su distribución. [5]

El error que descubrió Chazelas provocó que Bash ejecutara comandos de forma involuntaria cuando los comandos se concatenaban al final de las definiciones de funciones almacenadas en los valores de las variables de entorno . [1] [6] A los pocos días de su publicación, se descubrieron una variedad de vulnerabilidades relacionadas ( CVE - 2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 y CVE-2014-7187 ). Ramey las abordó con una serie de parches adicionales. [7] [8]

Los atacantes explotaron Shellshock pocas horas después de la divulgación inicial creando botnets de computadoras comprometidas para realizar ataques distribuidos de denegación de servicio y escaneo de vulnerabilidades . [9] [10] Las compañías de seguridad registraron millones de ataques y sondeos relacionados con el error en los días posteriores a la divulgación. [11] [12]

Debido al potencial de comprometer millones de sistemas sin parches, Shellshock fue comparado con el error Heartbleed en su gravedad. [3] [13]

Fondo

El error Shellshock afecta a Bash , un programa que varios sistemas basados ​​en Unix utilizan para ejecutar líneas de comandos y scripts de comandos. A menudo se instala como la interfaz de línea de comandos predeterminada del sistema . El análisis del historial del código fuente de Bash muestra que el error se introdujo el 5 de agosto de 1989 y se lanzó en la versión 1.03 de Bash el 1 de septiembre de 1989. [14] [15] [16]

Shellshock es una vulnerabilidad de ejecución de código arbitrario que ofrece una forma para que los usuarios de un sistema ejecuten comandos que no deberían estar disponibles para ellos. Esto sucede a través de la característica de "exportación de funciones" de Bash, mediante la cual un proceso de Bash puede compartir scripts de comandos con otros procesos de Bash que ejecuta. [17] Esta característica se implementa codificando los scripts en una tabla que se comparte entre los procesos, conocida como lista de variables de entorno . Cada nuevo proceso de Bash escanea esta tabla en busca de scripts codificados, ensambla cada uno en un comando que define ese script en el nuevo proceso y ejecuta ese comando. [18] El nuevo proceso asume que los scripts encontrados en la lista provienen de otro proceso de Bash, pero no puede verificar esto, ni puede verificar que el comando que ha creado sea una definición de script correctamente formada. Por lo tanto, un atacante puede ejecutar comandos arbitrarios en el sistema o explotar otros errores que puedan existir en el intérprete de comandos de Bash, si el atacante tiene una forma de manipular la lista de variables de entorno y luego hacer que Bash se ejecute. En el momento en que se descubrió el error, Bash estaba instalado en macOS y muchos sistemas operativos Linux como el principal intérprete de comandos, de modo que cualquier programa que usara la systemfunción para ejecutar cualquier otro programa usaría Bash para hacerlo.

La presencia del error se anunció al público el 24 de septiembre de 2014, cuando las actualizaciones de Bash con la corrección estaban listas para su distribución, [5] aunque tomó algún tiempo para que las computadoras se actualizaran para cerrar el potencial problema de seguridad.

Informes de ataques

Una hora después del anuncio de la vulnerabilidad de Bash, hubo informes de máquinas que estaban siendo comprometidas por el error. Para el 25 de septiembre de 2014, los atacantes estaban utilizando botnets basados ​​en computadoras comprometidas con exploits basados ​​en el error para ataques distribuidos de denegación de servicio (DDoS) y escaneo de vulnerabilidades . [9] [10] [19] Kaspersky Labs informó que las máquinas comprometidas en un ataque, llamado "Thanks-Rob", estaban realizando ataques DDoS contra tres objetivos, que no identificaron. [9] El 26 de septiembre de 2014, se informó de una botnet relacionada con Shellshock llamada "wopbot", que se estaba utilizando para un ataque DDoS contra Akamai Technologies y para escanear el Departamento de Defensa de los Estados Unidos . [10]

El 26 de septiembre, la empresa de seguridad Incapsula detectó 17.400 ataques a más de 1.800 dominios web, originados en 400 direcciones IP únicas, en las 24 horas anteriores; el 55% de los ataques provenían de China y Estados Unidos. [11] Para el 30 de septiembre, la empresa de rendimiento de sitios web CloudFlare dijo que estaba rastreando aproximadamente 1,5 millones de ataques y sondeos por día relacionados con el error. [12]

El 6 de octubre, se informó ampliamente que los servidores de Yahoo! habían sido comprometidos en un ataque relacionado con el problema de Shellshock. [20] [21] Sin embargo, al día siguiente, se negó que hubiera sido Shellshock específicamente el que había permitido estos ataques. [22]

Vectores de explotación específicos

Servidor web basado en CGI
Cuando un servidor web utiliza la interfaz de puerta de enlace común (CGI) para gestionar una solicitud de documento, copia determinada información de la solicitud en la lista de variables de entorno y luego delega la solicitud a un programa controlador. Si el controlador es un script de Bash, o si ejecuta Bash, entonces Bash recibirá las variables de entorno que le pase el servidor y las procesará como se describió anteriormente. Esto proporciona un medio para que un atacante active la vulnerabilidad Shellshock con una solicitud de documento especialmente diseñada. [6]
La documentación de seguridad del servidor web Apache , ampliamente utilizado , afirma: "Los scripts CGI pueden... ser extremadamente peligrosos si no se los controla cuidadosamente" [23] y, en su lugar, se suelen utilizar otros métodos para gestionar las solicitudes del servidor web. Hay varios servicios en línea que intentan probar la vulnerabilidad en servidores web expuestos a Internet. [ cita requerida ]
Servidor OpenSSH
OpenSSH tiene una característica llamada "ForceCommand", que permite ejecutar un comando fijo cuando el usuario inicia sesión, en lugar de ejecutar un comando sin restricciones. El comando fijo se ejecuta incluso si el usuario especificó que se debe ejecutar otro comando; en ese caso, el comando original se coloca en la variable de entorno "SSH_ORIGINAL_COMMAND". Cuando el comando forzado se ejecuta en un shell Bash (si el shell del usuario está configurado como Bash), el shell Bash analizará la variable de entorno SSH_ORIGINAL_COMMAND al iniciarse y ejecutará los comandos integrados en ella. El usuario ha utilizado su acceso restringido al shell para obtener acceso sin restricciones al shell, utilizando el error Shellshock. [24]
Clientes DHCP
Algunos clientes DHCP también pueden pasar comandos a Bash; un sistema vulnerable podría ser atacado al conectarse a una red Wi-Fi abierta. Un cliente DHCP normalmente solicita y obtiene una dirección IP de un servidor DHCP, pero también se le pueden proporcionar una serie de opciones adicionales. Un servidor DHCP malicioso podría proporcionar, en una de estas opciones, una cadena diseñada para ejecutar código en una estación de trabajo o computadora portátil vulnerable. [13]
Servidor Qmail
Al utilizar Bash para procesar mensajes de correo electrónico (por ejemplo, a través de .forward o qmail-alias), el servidor de correo qmail pasa la entrada externa de una manera que puede explotar una versión vulnerable de Bash. [25] [7]
Shell restringido de IBM HMC
El error puede aprovecharse para obtener acceso a Bash desde el shell restringido de IBM Hardware Management Console , [26] una pequeña variante de Linux para administradores de sistemas. IBM lanzó un parche para resolver este problema. [27]

Vulnerabilidades reportadas

Descripción general

El responsable de mantenimiento de Bash fue advertido sobre el primer descubrimiento del error el 12 de septiembre de 2014; pronto se publicó una solución. [1] Se informó a algunas empresas y distribuidores antes de que el asunto se divulgara públicamente el 24 de septiembre de 2014 con el identificador CVE - 2014-6271 . [4] [5] Sin embargo, después del lanzamiento del parche hubo informes posteriores de vulnerabilidades diferentes, aunque relacionadas. [28]

El 26 de septiembre de 2014, dos colaboradores de código abierto, David A. Wheeler y Norihiro Tanaka, notaron que había problemas adicionales, incluso después de aplicar los parches más recientes a los sistemas. En un correo electrónico dirigido a las listas de correo oss-sec y bash-bug, Wheeler escribió: "Este parche simplemente continúa con el trabajo de 'whack-a-mole' [ sic ] de corregir los errores de análisis que comenzaron con el primer parche. El analizador de Bash seguramente tendrá muchas, muchas, muchas otras vulnerabilidades". [29]

El 27 de septiembre de 2014, Michał Zalewski de Google Inc. anunció su descubrimiento de otras vulnerabilidades de Bash, [7] una basada en el hecho de que Bash se compila normalmente sin aleatorización del diseño del espacio de direcciones . [30] El 1 de octubre, Zalewski publicó detalles de los errores finales y confirmó que un parche de Florian Weimer de Red Hat publicado el 25 de septiembre efectivamente los previene. Lo ha hecho utilizando una técnica de fuzzing con la ayuda de una utilidad de software conocida como american fuzzy lop . [31]

Informe inicial (CVE-2014-6271)

Esta forma original de la vulnerabilidad ( CVE - 2014-6271) implica una variable de entorno especialmente diseñada que contiene una definición de función exportada, seguida de comandos arbitrarios. Bash ejecuta incorrectamente los comandos finales cuando importa la función. [32] La vulnerabilidad se puede probar con el siguiente comando:

env x = '() { :;}; echo vulnerable' bash -c "echo esto es una prueba"    

En los sistemas afectados por la vulnerabilidad, los comandos anteriores mostrarán la palabra "vulnerable" como resultado de que Bash ejecute el comando "echo vulnerable" , que estaba integrado en la variable de entorno especialmente diseñada denominada "x" . [8] [33]

CVE-2014-6277

Descubierta por Michał Zalewski , [7] [30] [34] la vulnerabilidad CVE - 2014-6277, que se relaciona con el análisis de definiciones de funciones en variables de entorno por Bash, puede causar un error de segmentación . [35]

CVE-2014-6278

También descubierto por Michał Zalewski , [35] [36] este error ( CVE - 2014-6278) se relaciona con el análisis de definiciones de funciones en variables de entorno por Bash.

CVE-2014-7169

El mismo día en que se publicó la vulnerabilidad original, Tavis Ormandy descubrió este error relacionado ( CVE - 2014-7169), [24] que se demuestra en el siguiente código:

env X = '() { (a)=>\' bash -c "echo fecha" ; cat echo      

En un sistema vulnerable, esto ejecutaría el comando "date" involuntariamente. [24]

A continuación se muestra un ejemplo de un sistema que tiene un parche para CVE-2014-6271 pero no para CVE-2014-7169:

$ X = '() { (a)=>\'  bash  -c "echo date" bash: X: línea 1: error de sintaxis cerca de un token inesperado `=' bash: X: línea 1: `' bash: error al importar la definición de función para `X' $ cat echo vie sep 26 01:37:16 UTC 2014  

El sistema muestra errores de sintaxis y notifica al usuario que se ha evitado CVE-2014-6271, pero aún así escribe un archivo llamado 'echo' en el directorio de trabajo, que contiene el resultado de la llamada 'date'.

Un sistema parcheado para CVE-2014-6271 y CVE-2014-7169 simplemente repetirá la palabra "fecha" y no se creará el archivo "echo", como se muestra a continuación:

$ X = '() { (a)=>\'  bash  -c "echo date" date $ cat echo cat: echo: No existe el archivo o directorio  

CVE-2014-7186

Florian Weimer y Todd Sabin encontraron este error ( CVE - 2014-7186), [8] [31] que se relaciona con un error de acceso a memoria fuera de límites en el código del analizador Bash. [37]

Un ejemplo de la vulnerabilidad, que aprovecha el uso de múltiples declaraciones "<<EOF" ( documentos "aquí" anidados ):

bash  -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"   

Un sistema vulnerable reflejará el texto "CVE-2014-7186 vulnerable, redir_stack".

CVE-2014-7187

También encontrado por Florian Weimer, [8] CVE - 2014-7187 es un error de un dígito en el código del analizador Bash, que permite el acceso a la memoria fuera de los límites. [38]

Un ejemplo de la vulnerabilidad, que aprovecha el uso de múltiples declaraciones "done":

( para  x en { 1 ..200 } ; hacer echo "para x $x en ; hacer :" ; hecho ; para x en { 1 ..200 } ; hacer echo hecho ; hecho ) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"                     

Un sistema vulnerable mostrará el texto "CVE-2014-7187 vulnerable, word_lineno". Esta prueba requiere un shell que admita la expansión de llaves . [39]

Parches

Hasta el 24 de septiembre de 2014, el mantenedor de Bash Chet Ramey proporcionó una versión de parche bash43-025 de Bash 4.3 que abordaba CVE-2014-6271, [40] que ya estaba empaquetada por los mantenedores de la distribución. El 24 de septiembre, siguió bash43-026, que abordaba CVE-2014-7169. [41] Luego se descubrió CVE-2014-7186. Florian Weimer de Red Hat publicó un código de parche para esto "extraoficialmente" el 25 de septiembre, [42] que Ramey incorporó a Bash como bash43-027. [43] [44] —Estos parches proporcionaron solo el código fuente , útil solo para aquellos que saben cómo compilar (" reconstruir ") un nuevo archivo ejecutable binario de Bash a partir del archivo de parche y los archivos de código fuente restantes. Los parches agregaron un prefijo de nombre de variable cuando se exportan funciones; Esto evitó que variables arbitrarias activaran la vulnerabilidad y permitió que otros programas eliminaran funciones Bash del entorno.

Al día siguiente, Red Hat presentó oficialmente las actualizaciones correspondientes para Red Hat Enterprise Linux , [45] [46] después de otro día para Fedora 21. [ 47] Canonical Ltd. presentó actualizaciones para sus versiones de soporte a largo plazo de Ubuntu el sábado 27 de septiembre; [48] el domingo, hubo actualizaciones para SUSE Linux Enterprise . [49] El lunes y martes siguientes a finales de mes, aparecieron las actualizaciones de Mac OS X. [50] [51]

El 1 de octubre de 2014, Michał Zalewski de Google Inc. finalmente declaró que el código de Weimer y bash43-027 habían corregido no solo los primeros tres errores sino también los tres restantes que se publicaron después de bash43-027, incluidos sus propios dos descubrimientos. [31] Esto significa que después de las actualizaciones de distribución anteriores, no se han requerido otras actualizaciones para cubrir los seis problemas. [46]

Todos ellos también han sido cubiertos por IBM Hardware Management Console. [27]

Referencias

  1. ^ abcde Perlroth, Nicole (25 de septiembre de 2014). "Los expertos en seguridad esperan que el error de software 'Shellshock' en Bash sea significativo". New York Times . Consultado el 25 de septiembre de 2014 .
  2. ^ Aunque en algunas fuentes se lo describe como un "virus", Shellshock es en realidad un fallo de diseño en un programa que viene con algunos sistemas operativos. Véase => Staff (25 de septiembre de 2014). "¿A qué afecta el error "Shellshock"?". The Safe Mac . Archivado desde el original el 29 de septiembre de 2014. Consultado el 27 de septiembre de 2014 .
  3. ^ ab Seltzer, Larry (29 de septiembre de 2014). "Shellshock hace que Heartbleed parezca insignificante". ZDNet . Consultado el 29 de septiembre de 2014 .
  4. ^ por Florian Weimer (24 de septiembre de 2014). «Re: CVE-2014-6271: ejecución remota de código mediante bash». oss-sec (lista de correo) . Consultado el 1 de noviembre de 2014 .
  5. ^ abc Florian Weimer (24 de septiembre de 2014). «Re: CVE-2014-6271: ejecución remota de código mediante bash». oss-sec (lista de correo) . Consultado el 1 de noviembre de 2014 .
  6. ^ ab Leyden, John (24 de septiembre de 2014). "Patch Bash NOW: el error 'Shell Shock' deja a los sistemas OS X y Linux totalmente expuestos". The Register . Consultado el 25 de septiembre de 2014 .
  7. ^ abcd Saarinen, Juha (29 de septiembre de 2014). "Más fallas hacen que el parche Shellshock sea ineficaz". iTnews . Consultado el 29 de septiembre de 2014 .
  8. ^ abcd Vaughan-Nichols, Steven (27 de septiembre de 2014). "Shellshock: mejores parches 'bash' ahora disponibles". ZDNet . Consultado el 29 de septiembre de 2014 .
  9. ^ abc Greenberg, Andy (25 de septiembre de 2014). "Los piratas informáticos ya están utilizando el error Shellshock para lanzar ataques de botnet". Wired . Consultado el 28 de septiembre de 2014 .
  10. ^ abc Saarinen, Juha (26 de septiembre de 2014). "El primer botnet Shellshock ataca a Akamai y las redes del Departamento de Defensa de Estados Unidos". iTnews . Consultado el 26 de septiembre de 2014 .
  11. ^ ab Perlroth, Nicole (26 de septiembre de 2014). "Compañías se apresuran a solucionar el error de software Shellshock mientras los piratas informáticos lanzan miles de ataques". New York Times . Consultado el 29 de septiembre de 2014 .
  12. ^ ab Strohm, Chris; Robertson, Jordan (30 de septiembre de 2014). "Shellshock atrae ataques de hackers y genera una carrera para corregir un error". Businessweek. Archivado desde el original el 1 de octubre de 2014. Consultado el 1 de octubre de 2014 .
  13. ^ ab Cerrudo, Cesar (30 de septiembre de 2014). "Why the Shellshock Bug Is Worse than Heartbleed". MIT Technology Review . Consultado el 1 de octubre de 2014 .
  14. ^ Fox, Brian (21 de marzo de 1990). «Bash 1.05 ChangeLog». Archivado desde el original el 6 de diciembre de 2023. Consultado el 14 de octubre de 2014 .
  15. ^ Chazelas, Stéphane (10 de octubre de 2014). «¿Cuándo se introdujo Shellshock?». Stéphane Chazelas y Chet Ramey confirman la fecha de introducción de la vulnerabilidad en el canal de comunicación oficial de Bash . Archivado desde el original el 20 de diciembre de 2016. Consultado el 14 de octubre de 2014 .
  16. ^ Chazelas, Stéphane (25 de septiembre de 2014). "¿Cuándo se introdujo el error Shellshock (CVE-2014-6271/7169) y cuál es el parche que lo corrige por completo?".
  17. ^ "Manual de referencia de Bash: funciones de shell" . Consultado el 2 de octubre de 2014 .
  18. ^ "Código fuente de Bash 4.3, archivo variables.c, líneas 315-388" . Consultado el 2 de octubre de 2014 .
  19. ^ Varios (26 de septiembre de 2014). «Ataques web basados ​​en el error Shellshock». BBC . Consultado el 26 de septiembre de 2014 .
  20. ^ Boren, Zachary (6 de octubre de 2014). "Shellshock: hackers rumanos están accediendo a servidores de Yahoo, afirma experto en seguridad". Independent . Consultado el 7 de octubre de 2014 .
  21. ^ "Yahoo! ¡Conmocionado como las Tortugas Ninja!". Archivado desde el original el 9 de octubre de 2014 . Consultado el 7 de octubre de 2014 .
  22. ^ Hanno Böck (7 de octubre de 2014). "Yahoo por Shellshock atacado". Golem - IT-News für Profis (en alemán) . Consultado el 30 de octubre de 2014 .
  23. ^ "Documentación de Apache HTTP Server 2.2: consejos de seguridad" . Consultado el 2 de octubre de 2014 .
  24. ^ abc Wolfgang Kandek (24 de septiembre de 2014). «Las leyes de las vulnerabilidades». Qualys.com. Archivado desde el original el 3 de mayo de 2016. Consultado el 26 de septiembre de 2014 .
  25. ^ Kyle George (27 de septiembre de 2014). "qmail es un vector para CVE-2014-6271 (bash shellshock)". qmail (Lista de correo).
  26. ^ "IBM HMC es un vector para CVE-2014-6271 (bash "shellshock")". IBM . Archivado desde el original el 19 de enero de 2020.
  27. ^ ab "Boletín de seguridad: Vulnerabilidades en Bash afectan a DS8000 HMC (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, CVE-2014-6278)". IBM. 3 de octubre de 2014. Consultado el 2 de noviembre de 2014 .
  28. ^ "Shellshock". 13 de febrero de 2015. Consultado el 17 de septiembre de 2016 .
  29. ^ Gallagher, Sean (26 de septiembre de 2014). "¿Más vulnerabilidades en bash? Shellshock se convierte en whack-a-mole". Arstechnica . Consultado el 26 de septiembre de 2014 .
  30. ^ ab Staff (28 de septiembre de 2014). "Shellshock, Parte 3: Tres problemas de seguridad más en Bash (en alemán)". Heise Online . Consultado el 28 de septiembre de 2014 .
  31. ^ abc "Error de Bash: los otros dos RCE, o cómo fuimos eliminando la corrección original (CVE-2014-6277 y '78)". lcamtuf blog . 1 de octubre de 2014 . Consultado el 8 de octubre de 2014 .
  32. ^ "Resumen de vulnerabilidades para CVE-2014-6271". NIST. 4 de octubre de 2014. Consultado el 8 de octubre de 2014 .
  33. ^ "Ataque de inyección de código de variables de entorno especialmente diseñadas por Bash". Red Hat Security . Consultado el 2 de octubre de 2014 .
  34. ^ Staff (27 de septiembre de 2014). «Resumen de vulnerabilidades del Sistema Nacional de Concienciación Cibernética para CVE-2014-6277». Instituto Nacional de Estándares y Tecnología . Consultado el 28 de septiembre de 2014 .
  35. ^ ab Constatin, Lucian (29 de septiembre de 2014). "Un parche mejorado aborda los nuevos vectores de ataque del error Shellshock Bash". PC World . Consultado el 1 de octubre de 2014 .
  36. ^ Staff (30 de septiembre de 2014). «Resumen de vulnerabilidades del Sistema Nacional de Concienciación Cibernética para CVE-2014-6278». Instituto Nacional de Estándares y Tecnología . Consultado el 1 de octubre de 2014 .
  37. ^ Staff (29 de septiembre de 2014). «Resumen de vulnerabilidades del Sistema Nacional de Concienciación Cibernética para CVE-2014-7186». Instituto Nacional de Estándares y Tecnología . Consultado el 1 de octubre de 2014 .
  38. ^ Staff (29 de septiembre de 2014). «Resumen de vulnerabilidades del Sistema Nacional de Concienciación Cibernética para CVE-2014-7187». Instituto Nacional de Estándares y Tecnología . Consultado el 1 de octubre de 2014 .
  39. ^ Ramey, Chet. "Re: CVE-2014-7187". lists.gnu.org .
  40. ^ "INFORME SOBRE EL PARCHE DE BASH". GNU.org . 12 de septiembre de 2014 . Consultado el 2 de noviembre de 2014 .
  41. ^ "INFORME SOBRE EL PARCHE DE BASH". GNU.org . 25 de septiembre de 2014 . Consultado el 2 de noviembre de 2014 .
  42. ^ Weimer, Florian (25 de septiembre de 2014). «Re: CVE-2014-6271: ejecución remota de código a través de bash». Proyecto Openwall . Consultado el 2 de noviembre de 2014 .
  43. ^ "INFORME SOBRE EL PARCHE DE BASH". GNU.org . 25 de septiembre de 2014 . Consultado el 2 de noviembre de 2014 .
  44. ^ Gallagher, Sean (26 de septiembre de 2014). "Se lanzó un nuevo parche "Shellshock" para resolver las deficiencias de la primera corrección [Actualizado]" . Consultado el 2 de noviembre de 2014 .
  45. ^ "Importante: actualización de seguridad de bash". Red Hat. 30 de septiembre de 2014. Consultado el 2 de noviembre de 2014 .
  46. ^ ab "Vulnerabilidad de inyección de código Bash a través de variables de entorno especialmente diseñadas (CVE-2014-6271, CVE-2014-7169)". Red Hat. 2 de octubre de 2014. Consultado el 2 de noviembre de 2014 .
  47. ^ "[SEGURIDAD] Actualización de Fedora 21: bash-4.3.25-2.fc21". FedoraProject.org . 27 de septiembre de 2014 . Consultado el 2 de noviembre de 2014 .
  48. ^ "USN-2364-1: Vulnerabilidades en Bash". Canonical Ltd. 27 de septiembre de 2014. Consultado el 2 de noviembre de 2014 .
  49. ^ "Actualización de seguridad de SUSE: Actualización de seguridad para bash". OpenSUSE . 28 de septiembre de 2014 . Consultado el 2 de noviembre de 2014 .
  50. ^ Clover, Juli (29 de septiembre de 2014). "Apple lanza una actualización de OS X Bash para corregir la falla de seguridad 'Shellshock' en Mavericks, Mountain Lion y Lion". MacRumors.com . Consultado el 2 de octubre de 2014 .
  51. ^ Slivka, Eric (30 de septiembre de 2014). "Apple lanza OS X Yosemite Golden Master Candidate para desarrolladores [Actualización: también versión beta pública]". MacRumors.com . Consultado el 2 de octubre de 2014 .

Enlaces externos