Shellshock (error de software)

De Wikipedia, la enciclopedia libre

Shellshock, también conocida como Bashdoor,[1]​ es una familia de bugs de seguridad en la ampliamente usada Bash de Shell de Unix. El primero de estos bugs fue divulgado el 24 de septiembre de 2014. Varios servicios de internet tal como algunas implementaciones de servidores web usan Bash para ciertos pedidos y procesos, esto le permitía al atacante ejecutar comandos arbitrarios en versiones vulnerables de Bash, de esta forma el atacante podía ganar acceso no autorizado al sistema atacado.[2]​

El 12 de septiembre Stéphane Chazelas contactó al encargado del mantenimiento de Bash, Chet Ramey[1]​ mencionándole acerca de su descubrimiento del error original el cual fue llamado "Bashdoor". Trabajando en conjunto con expertos en seguridad se obtuvo en poco tiempo un parche que solucionaría el problema.[1]​ El error se identificó mediante el nombre de CVE-2014-6271. Fue anunciado al público el 24 de septiembre del 2014 cuando las actualizaciones de Bash ya incluían los parches hechos para la versión que se distribuiría en la actualización correspondiente.[3]​

El primer error ocasionaba que Bash sin previa autorización ejecutara comandos cuando los comandos están concatenados al final de una definición de función guardada en los valores de las variables de entorno[1]​[4]​ A días de la publicación del error, el intenso escrutinio de los defectos de diseño subyacentes descubrieron una nueva variedad, vulnerabilidades que se encontraban relacionadas, (CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 y CVE-2014-7187); para las cuales Ramey creó nuevos parches al software de Bash.[5]​[6]​

Atacantes explotaron Shellshock apenas habían pasado unas horas de la revelación inicial mediante la creación de botnets de computadoras previamente comprometidas para ejecutar ataques de denegación de servicio distribuido y escaneo de vulnerabilidades.[7]​[8]​ Las compañías de seguridad identificaron millones de ataques y pruebas relacionadas con el error en los días siguientes a su descubrimiento.[9]​[10]​

Shellshock pudo comprometer millones de servidores que no tuvieran el parche desarrollado por Ramey. Debido a su gran impacto ha sido comparada con el error Heartbleed debido a la severidad de la falla ocasionada.[2]​[11]​

Apple Inc. comenta que los sistemas OS X están a salvo por default, a menos que los usuarios configuraran servicios avanzados de UNIX. Estos usuarios avanzados pueden apagar los servicios hasta que un parche oficial de OS X esté disponible, de igual forma podrían usar Xcode para reemplazar el Bash provisto por default por sistema con una versión personalizada y compilada de Bash que incorporara parches no oficiales.[12]​[13]​[14]​ A pesar de ser notificada de la vulnerabilidad antes de ser publicada, la compañía no sacó una actualización correspondiente de OS X hasta el 29 de septiembre de 2014, al tiempo que la actualización de Bash OS X 1.0 fue publicada.[15]​[16]​[17]​

Antecedentes[editar]

Las vulnerabilidades Shellshock afectan a Bash, un programa que varios sistemas basados en Unix utilizan para ejecutar líneas de comando y scripts que ejecuten instrucciones. Comúnmente se encuentra instalado como la interfaz por defecto de línea de comando. Bash es un programa de Software libre, que fue desarrollado de manera colaborativa desde 1992 por Chet Ramey, un arquitecto profesional de software.[1]​ El análisis del historial del código fuente de Bash muestra que las vulnerabilidades han existido desde la versión 1.03 publicada en septiembre de 1989,[18]​[19]​ que fue introducida por el autor original de Bash, Brian Fox.

En los sistemas operativos basados en Unix y en otros sistemas operativos que Bash soporta, cada programa en curso tiene su propia lista de pares <nombre,valor> llamados variables de ambiente. Cuando un programa empieza, otro programa provee la lista inicial de variables de ambiente para el nuevo programa.[20]​ Independientemente de estas variables de ambiente, Bash también mantiene una lista interna de funciones, las cuales son scripts nombrados que pueden ser ejecutados desde el programa.[21]​ Dado que Bash opera tanto como un interpretador de comando como un comando por sí mismo, es posible ejecutar Bash desde él mismo. Cuando esto sucede, la instancia original puede exportar variables de ambiente y definiciones de funciones a la nueva instancia creada de Bash.[22]​ Las definiciones de función son exportadas siendo codificadas dentro de la lista de variables de ambiente como variables cuyos valores empiezan con un paréntesis ("()") seguidas por una definición de función. Esta nueva instancia de Bash, hasta su inicialización, escanea la lista de variables de ambiente en su formato y las convierte de vuelta a funciones internas. Hace esta conversión creando un fragmento de código desde el valor y ejecutándolo, de este modo crea la función dinámicamente, en tiempo de ejecución, pero afecta a las versiones que no verifican que sea un definición función válida.[23]​ Por lo tanto, da la oportunidad de ejecutar Bash con un valor escogido de la lista de variables de ambiente, un atacante puede ejecutar comandos arbitrarios o explotar otros errores de software que existan en el interpretador de comando de Bash.

Reporte de ataques[editar]

Apenas una hora después del anuncio de la vulnerabilidad Shellshock, hubo reportes de máquinas que fueron comprometidas por el error de software. El 25 de septiembre de 2014, Botnets basados en computadoras comprometidas que fueron usadas gracias a la vulnerabilidad que el error ocasionaba fueron usadas por lo atacantes como máquinas que ejecutaban ataques de denegación de servicio distribuidos (DDoS) y hacían escaneos de vulnerabilidades.[7]​[8]​[24]​ Laboratorios Kaspersky reportaron que las máquinas comprometidas en el ataque, apodado "Thanks-Rob", conducían ataques DDoS hacia tres objetivos, los cuales no pudieron ser identificados.[7]​ El 26 de septiembre de 2014, un botnet apodado "wopbot" fue reportado, el cual estaba siendo usado como botnet el cual atacaba a Akamai Technologies y a la vez escaneaba al Departamento de Defensa de los Estados Unidos.[8]​

El 26 de septiembre, la firma de seguridad Incapsula notó 17,400 ataques, más de 1,800 en dominios web que se originaron desde 400 direcciones IP, en las 24 horas previas, 55% de los ataques provenían de China y de los Estados Unidos.[9]​ Para el 30 de septiembre, el sitio de la firma CloudFare dijo que estaba rastreando y siguiendo aproximadamente 1.5 millones de ataques y pruebas relacionadas con el error Shellshock.[10]​

El 6 de octubre fue ampliamente reportado que los servidores Yahoo! habían sido comprometidos en un ataque relacionado con el error ShellShock .[25]​[26]​ Aunque al día siguiente fue negado que únicamente el error Shellshock hubiera sido el causante de estos ataques.[27]​

Vectores vulnerables[editar]

Servidor Web CGI
Cuando un servidor web usa la Interfaz de entrada común para manejar una petición de documento, pasa varios detalles de la petición a un programa manejador en la lista de variables de ambiente. Por ejemplo, la variable HTTP_USER_AGENT tiene un valor que en un uso normal identifica al programa que manda la petición. Si la petición es un script de Bash o si se ejecuta usando la llamada a sistema, Bash recibirá las variables de entorno que fueron pasadas por el servidor y se procesarán como se describió más arriba. Eso provee medio para que un atacante desencadene la vulnerabilidad ShellShock con una petición hecha especialmente para este propósito.[4]​ La documentación de seguridad que es ampliamente usada en los servidores Apache cita "Los scripts de CGI son extremadamente peligrosos si no son adecuadamente revisados"[28]​ Otros métodos para manejar peticiones de servidores web son usadas usualmente para evitar esta situación. Hay un número de servicios de internet que son usados para probar las vulnerabilidades a las que son expuestas los servidores.
Servidor OpenSSH
OpenSSH tiene un "Comando de Fuerza" la cual es una característica donde un comando fijo es ejecutado cuando el usuario entra con sus credenciales a su sesión respectiva, en lugar del comando por default de la shell. El comando fijo es ejecutado aun cuando el usuario dicta que el cualquier otro comando debería ser ejecutado, en ese caso lo que sucede es que el comando original es puesto dentro de la variables de ambiente "SSH_ORIGINAL_COMMAND". Cuando el comando es forzado a correr en un shell de Bash, esta misma hará un parseo de la variable de ambiente "SSH_ORIGINAL_COMMAND" al inicio de sesión y se correrá embebida en ella. El usuario a través de esto tendrá acceso sin restricciones a la shell, usando el error de software ShellShock.[29]​
Clientes DHCP
Varios clientes DHCP también pueden pasar comando de Bash, un sistema vulnerable puede ser atacado cuando se conecta a una red abierta Wi-Fi. Un cliente DHCP típicamente solicita y recibe direcciones IP de un servidor DHCP, pero también puede proveer una serie de opciones adicionales. Un servidor DHCP infectado puede proveer, en una de estas opciones un string hecho de tal forma que ejecute un código malicioso en una computadora de trabajo.[11]​
Servidor QMail
Cuando se usa Bash para procesar mensajes de correo electrónico, ya sea para reenviar o enviar, el servidor Qmail pasa datos de entrada externo que pueden ser usados como una vulnerabilidad de la versión respectiva de Bash.[30]​[31]​
Shell restringida IBM HMC
Este error de software puede ser aprovechado de tal forma que se gane acceso a Bash a través de la Shell restringida de IBM y su consola de manejo de hardware,[32]​ una pequeña versión de Linux para administradores de sistema. IBM ya lanzó una actualización que soluciona este error.[33]​

Vulnerabilidades reportadas[editar]

Vista general[editar]

El encargado de Bash fue advertido sobre el descubrimiento del primer bug el 9 de diciembre de 2014, y fue solucionado rápidamente.[1]​ Unas pocas compañías y distribuidores fueron informados de este asunto antes de que fuera público el 24 de diciembre de 2014 con el identificador VE-2014-6271.[34]​[3]​ Sin embargo después de la salida del bug hubo reportes subsecuentes relacionados con más vulnerabilidades.

El 26 de septiembre de 2014 dos distribuidores de código abierto, David A. Wheeler y Norihiro Tanaka se dieron cuenta de que había problemas adicionales, aún después de la salida de los parches. En un correo electrónico dirigido a oss-sec, Wheeler escribió "Este parche solo es un intento de solucionar errores de parseo que comienzan con el primer parche. El parser de Bash tiene muchas más vulnerabilidades".[35]​ Sin embargo, este fue un razonamiento general sin prestar general atención en el posible aprovechamiento que pudo haber tenido Bash.

El 27 de septiembre de 2014, Michal Zalewski de Google anunció el descubrimiento de más vulnerabilidades de Bash,[5]​ una estaba basada en que Bash típicamente compila sin aleatorización en el espacio de direcciones.[36]​ El 1 de octubre, Zalewski publicó los detalles de los bugs finales y confirmó que un parche desarrollado por Florian Weimer de Red Hat que fue publicado el 25 de septiembre lo podría prevenir. Esto fue logrado usando una técnica difusa para así crear una técnica de ayuda de software conocida como American Fuzzy Loop.[37]​

Reporte inicial (CVE-2014-6271)[editar]

Esta forma original de vulnerabilidad involucra una variable de entorno especialmente diseñada para exportar la definición de una función seguida por comandos arbitrarios. Bash ejecuta incorrectamente la secuencia de comandos cuando importa la función.[38]​ La vulnerabilidad puede ser revisada con el siguiente comando

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

En los sistemas afectados por la vulnerabilidad, los comandos desplegados arriba desplegarían la palabra "vulnerable" como resultado de la ejecución de Bash corriendo el comando "echo vulnerable" que está integrado en otra variable especial llamada X.[6]​[39]​

CVE-2014-6277[editar]

Descubierto por Michal Zelwski[5]​[36]​[40]​ esta vulnerabilidad se relaciona a parsear definiciones de funciones en el ambiente de Bash, debido a que pueden ocasionar segfault.[41]​

CVE-2014-6278[editar]

También descubierto por Michał Zalewski.[41]​[42]​ se relaciona con el parseo de las definiciones de funciones de variables en Bash.

CVE-2014-7169[editar]

De la misma forma que la vulnerabilidad original fue publicada, Tavis Ormandy descubrió este bug relacionado[29]​ el cual puede ser demostrado por el siguiente código: 

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

En un sistema vulnerable esto desplegaría el comando "date" no intencionalmente.[29]​

Aquí hay un ejemplo de un sistema que tiene el parche para el bug CVE-2014-6271 pero no para el CVE-2014-7169:

$ X='() { (a)=>\' bash -c "echo date"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
$ cat echo
Fri Sep 26 01:37:16 UTC 2014

El sistema despliega los errores de sintaxis, notificando al usuario que CVE-2014-6271fue prevenida, pero aún escribe un archivo llamado "echo", en el directorio de trabajo, conteniendo la fecha de creación como resultado del bug.

Un sistema publicado para el parche de CVE-2014-6271 y CVE-2014-7169 simplemente haría echo a la palabra "date" y el archivo "echo" no sería creado como se muestra debajo. 

$ X='() { (a)=>\' bash -c "echo date"
date
$ cat echo
cat: echo: No such file or directory

CVE-2014-7186[editar]

Florian Weimer y Todd Sabin encontraron este bug[6]​[37]​, que está relacionado con desbordamiento de búferen el parser de Bash.[43]​

Un ejemplo de dicha vulnerabilidad que se aprovecha de los múltiples usos de declaraciones "<<EOF": 

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

Un sistema vulnerable haría echo sobre el texto "CVE-2014-7186 vulnerable, redir_stack".[44]​

Parches[editar]

Hasta el 24 de septiembre de 2014, el encargado de Bash Chet Ramey proveyó de una versión del parche bash43-025 de la dirección de Bash 4.3 CVE-2014-6271[45]​ la cual ya esta empaquetada y distribuida por los encargados de las distribuciones. En septiembre 24 fue empaquetada finalmente por los administradores de las versiones. El 24 de septiembre, bash43.026 seguido de la dirección CVE-2014-7169 fue descubierta. Florian Weimer de Red Hat publicó cierto código útil para un parche no oficial en septiembre 25,[46]​ El cual Ramaney incorporó a Bash como bash43-027.[47]​ Estos parches solo proveían código que supieran como recompilar una nueva distribución ejecutable de Bash a partir de archivos proveídos de forma externa.

El día siguiente, Red Hat sacó oficialmente de acuerdo a las actualizaciones de Red Hat Linux[48]​[49]​ solo un día después que Fedora 21[50]​ Canonical presentó mejoras y actualizaciones para Ubuntu y sus versiones a largo plazo presentadas para la versión de Unix[51]​ El domingo las actualizaciones hubo actualizaciones para SUSE Linux[52]​ El siguiente lunes y martes y finales de mes las actualizaciones para Apple Os X por fin salieron.[53]​[54]​

Referencias[editar]

  1. ↑ a b c d e f Perlroth, Nicole (25 de septiembre de 2014). «Security Experts Expect ‘Shellshock’ Software Bug in Bash to Be Significant». New York Times. Consultado el 25 de septiembre de 2014. 
  2. ↑ a b Seltzer, Larry (29 de septiembre de 2014). «Shellshock makes Heartbleed look insignificant». ZDNet. Consultado el 29 de septiembre de 2014. 
  3. ↑ a b Florian Weimer (24 de septiembre de 2014). «oss-sec: Re: CVE-2014-6271: remote code execution through bash». Seclists.org. Consultado el 1 de noviembre de 2014. 
  4. ↑ a b Leyden, John (24 de septiembre de 2014). «Patch Bash NOW: 'Shell Shock' bug blasts OS X, Linux systems wide open». The Register. Consultado el 25 de septiembre de 2014. 
  5. ↑ a b c Saarinen, Juha (29 de septiembre de 2014). «Further flaws render Shellshock patch ineffective». iTnews. Consultado el 29 de septiembre de 2014. 
  6. ↑ a b c Vaughan-Nichols, Steven (27 de septiembre de 2014). «Shellshock: Better 'bash' patches now available». ZDNet. Consultado el 29 de septiembre de 2014. 
  7. ↑ a b c Greenberg, Andy (25 de septiembre de 2014). «Hackers Are Already Using the Shellshock Bug to Launch Botnet Attacks». Wired. Consultado el 28 de septiembre de 2014. 
  8. ↑ a b c Saarinen, Juha (26 de septiembre de 2014). «First Shellshock botnet attacks Akamai, US DoD networks». iTnews. Consultado el 26 de septiembre de 2014. 
  9. ↑ a b Perlroth, Nicole (26 de septiembre de 2014). «Companies Rush to Fix Shellshock Software Bug as Hackers Launch Thousands of Attacks». New York Times. Consultado el 29 de septiembre de 2014. 
  10. ↑ a b Strohm, Chris; Robertson, Jordan (30 de septiembre de 2014). «Shellshock Draws Hacker Attacks, Sparks Race to Patch Bug». Businessweek. Consultado el 1 de octubre de 2014. 
  11. ↑ a b 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. 
  12. ↑ Chacos, Brad (26 de septiembre de 2014). «Apple Says Users Safe». Mac World. Consultado el 26 de septiembre de 2014. 
  13. ↑ «Apple Working Quickly». iMore. 26 de septiembre de 2014. Archivado desde el original el 8 de octubre de 2014. Consultado el 26 de septiembre de 2014. 
  14. ↑ TJ Luoma (25 de septiembre de 2014). «How to patch OS X for the bash/Shellshock vulnerability». Engadget. Consultado el 11 de agosto de 2015. 
  15. ↑ Gallagher, Sean. «Apple working on "Shellshock" fix, says most users not at risk». Consultado el 29 de septiembre de 2014. 
  16. ↑ Ragan, Steve (30 de septiembre de 2014). «Apple's Shellshock patch is incomplete experts say». CSO Online. Consultado el 9 de octubre de 2014. 
  17. ↑ «About OS X bash Update 1.0». 
  18. ↑ Fox, Brian (21 de marzo de 1990). «Bash 1.05 ChangeLog». Consultado el 14 de octubre de 2014. 
  19. ↑ Chazelas, Stéphane (10 de octubre de 2014). «when was shellshock introduced». Stéphane Chazelas and Chet Ramey confirm the vulnerability introduction date on Bash official communication channel. Archivado desde el original el 20 de diciembre de 2016. Consultado el 14 de octubre de 2014. 
  20. ↑ «Open Group Base Specification: exec». Consultado el 2 de octubre de 2014. 
  21. ↑ «Bash Reference Manual: Shell Functions». Consultado el 2 de octubre de 2014. 
  22. ↑ «Bash Reference Manual: Bourne Shell Builtins». Consultado el 2 de octubre de 2014. 
  23. ↑ «Bash 4.3 source code, file variables.c, lines 315-388». Consultado el 2 de octubre de 2014. 
  24. ↑ Various (26 de septiembre de 2014). «Web attacks build on Shellshock bug». BBC. Archivado desde el original el 29 de septiembre de 2014. Consultado el 26 de septiembre de 2014. 
  25. ↑ Boren, Zachary (6 de octubre de 2014). «Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert». Independent. Consultado el 7 de octubre de 2014. 
  26. ↑ «Yahoo! Shellshocked Like Ninja Turtles!». Archivado desde el original el 9 de octubre de 2014. Consultado el 7 de octubre de 2014. 
  27. ↑ Hanno Böck (7 de octubre de 2014). «Yahoo durch Shellshock angegriffen». Golem - IT-News für Profis (en alemán). Consultado el 30 de octubre de 2014. 
  28. ↑ «Apache HTTP Server 2.2 Documentation: Security Tips». Consultado el 2 de octubre de 2014. 
  29. ↑ a b c Wolfgang Kandek (24 de septiembre de 2014). «The Laws of Vulnerabilities». Qualys.com. Archivado desde el original el 6 de octubre de 2014. Consultado el 26 de septiembre de 2014. 
  30. ↑ "qmail is a vector for CVE-2014-6271 (bash shellshock)", Sep 27, 2014, Kyle George, qmail mailing list
  31. ↑ "Further flaws render Shellshock patch ineffective", Sep 29, 2014, Juha Saarinen, itnews.com.au
  32. ↑ "IBM HMC is a vector for CVE-2014-6271 (bash "shellshock")
  33. ↑ «Security Bulletin: Vulnerabilities in Bash affect 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. 
  34. ↑ Error en la cita: Etiqueta <ref> no válida; no se ha definido el contenido de las referencias llamadas seclist-q3-650
  35. ↑ Gallagher, Sean (26 de septiembre de 2014). «Still more vulnerabilities in bash? Shellshock becomes whack-a-mole». Arstechnica. Consultado el 26 de septiembre de 2014. 
  36. ↑ a b Staff (28 de septiembre de 2014). «Shellshock, Part 3: Three more security problems in Bash (in german)». Heise Online (en alemán). Consultado el 28 de septiembre de 2014. 
  37. ↑ a b «Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)». lcamtuf blog. 1 de octubre de 2014. Consultado el 8 de octubre de 2014. 
  38. ↑ «Vulnerability Summary for CVE-2014-6271». NIST. 4 de octubre de 2014. Consultado el 8 de octubre de 2014. 
  39. ↑ «Bash specially-crafted environment variables code injection attack». Red Hat Security. Consultado el 2 de octubre de 2014. 
  40. ↑ Staff (27 de septiembre de 2014). «National Cyber Awareness System Vulnerability Summary for CVE-2014-6277». National Institute of Standards and Technology. Consultado el 28 de septiembre de 2014. 
  41. ↑ a b Constatin, Lucian (29 de septiembre de 2014). «Improved patch tackles new Shellshock Bash bug attack vectors». PC World. Consultado el 1 de octubre de 2014. 
  42. ↑ Staff (30 de septiembre de 2014). «National Cyber Awareness System Vulnerability Summary for CVE-2014-6278». National Institute of Standards and Technology. Consultado el 1 de octubre de 2014. 
  43. ↑ Staff (29 de septiembre de 2014). «National Cyber Awareness System Vulnerability Summary for CVE-2014-7186». National Institute of Standards and Technology. Consultado el 1 de octubre de 2014. 
  44. ↑ Ramey, Chet. «Re: CVE-2014-7187». lists.gnu.org. 
  45. ↑ «BASH PATCH REPORT». GNU.org. 12 de septiembre de 2014. Consultado el 2 de noviembre de 2014. 
  46. ↑ Weimer, Florian (25 de septiembre de 2014). «Re: CVE-2014-6271: remote code execution through bash». Openwall Project. Consultado el 2 de noviembre de 2014. 
  47. ↑ Gallagher, Sean (26 de septiembre de 2014). «New “Shellshock” patch rushed out to resolve gaps in first fix [Updated]». Consultado el 2 de noviembre de 2014. 
  48. ↑ «Important: bash security update». Red Hat. 30 de septiembre de 2014. Consultado el 2 de noviembre de 2014. 
  49. ↑ «Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)». Red Hat. 2 de octubre de 2014. Consultado el 2 de noviembre de 2014. 
  50. ↑ «[SECURITY] Fedora 21 Update: bash-4.3.25-2.fc21». FedoraProject.org. 27 de septiembre de 2014. Consultado el 2 de noviembre de 2014. 
  51. ↑ «USN-2364-1: Bash vulnerabilities». Canonical Ltd. 27 de septiembre de 2014. Consultado el 2 de noviembre de 2014. 
  52. ↑ «SUSE Security Update: Security update for bash». OpenSUSE. 28 de septiembre de 2014. Consultado el 2 de noviembre de 2014. 
  53. ↑ Clover, Juli (29 de septiembre de 2014). «Apple Releases OS X Bash Update to Fix 'Shellshock' Security Flaw in Mavericks, Mountain Lion, and Lion». MacRumors.com. Consultado el 2 de octubre de 2014. 
  54. ↑ Slivka, Eric (30 de septiembre de 2014). «Apple Releases OS X Yosemite Golden Master Candidate to Developers [Update: Also Public Beta]». MacRumors.com. Consultado el 2 de octubre de 2014. 

Enlaces externos[editar]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Shellshock_(error_de_software)&oldid=159434599»