¿Son las Mac vulnerables al error shellshock de Bash?

Red Hat anunció recientemente un error importante relacionado con la seguridad en el shell Bash. Algunos lo llaman el error "shellshock". Dado que OS X se basa en Unix, ¿es vulnerable a los ataques que aprovechan este error?

Como usuario final, ¿debo preocuparme por una solución inmediata? ¿O es mejor que espere una actualización de software oficial de Apple?

Para ver qué acciones afectan a OSX, consulte security.stackexchange.com/questions/68123/…
Se actualizó la pregunta para que sea menos un engaño y más una solicitud de consejo para los laicos.
Apple ha lanzado una solución ahora: support.apple.com/kb/DL1769

Respuestas (5)

Sí, eres técnicamente vulnerable. Entonces, si tiene ganas de entrar en pánico o facturar a un cliente en pánico por unas horas de trabajo de pánico, ¡adelante!

Pero la realidad es que, a menos que permita el acceso SSH desde conexiones remotas o un servidor web que ejecuta secuencias de comandos del lado del servidor, no está en riesgo. Solo es verdaderamente vulnerable si alguien que no conoce puede acceder de forma remota a su máquina y hacerlo de una manera en la que se pueda ejecutar un comando Bash.

Lo que significa que su Mac de escritorio, que en realidad no ejecuta aplicaciones de servidor de ningún tipo, no corre ningún riesgo grave. Estoy dispuesto a comer un poco de "pastel humilde" proverbial aquí, pero no creo que la mayoría de los usuarios de Mac estén en riesgo al final del día.

Por lo tanto, este problema preocupa principalmente a los administradores de sistemas en servidores Mac OS X y Unix/Linux expuestos al mundo, no a los usuarios de escritorio que no habilitan el uso compartido de SSH.

Tal vez exista un riesgo extremo de que se cree un malware o virus de Mac para explotar este riesgo, pero lo dudo.

EDITAR: Y solo para explicar cómo este problema, en mi humilde opinión, no es realmente un problema para la mayoría de los usuarios promedio, sí, puedo ejecutar el siguiente comando desde bashMac OS X 10.9.5:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Y veo esto:

vulnerable
hello

¿Adivina qué? Eso solo es aterrador si no lo piensas racionalmente. Ya tenía que haber iniciado sesión en mi Mac para incluso abrir la Terminal. Y para negar lo que dije sobre SSH anteriormente, incluso para llegar al punto en que puedo ejecutar esta prueba incluso si SSH está habilitado, aún tendría que iniciar sesión para empezar. Y luego, digamos que tengo acceso a través de SSH, el comando no me permite hacer NADA más allá de mis derechos de usuario normales, como este:

env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'

Lo que significa que si realmente es vulnerable a ser explotado por este truco, su seguridad central en el sistema tendría que estar tan comprometida que el hecho de que bashtenga una falla es realmente el menor de sus problemas.

Esta es una preocupación de un problema general de control y derechos, ya que tiene la posibilidad de permitir el acceso no deseado, ya que el comportamiento se extiende fuera de las normas esperadas. Pero en mi humilde opinión, no es un riesgo a la par con OpenSSL o la variedad común de riesgos "déjame dejar mi contraseña en una nota pegada a mi pantalla".

Al final del día, todavía estoy parcheando todos mis servidores Linux/Unix que ejecuto como procedimiento estándar. Y felizmente parchearé las Mac que administro una vez que haya una solución. Pero para el uso práctico del día a día me siento bien sin preocuparme por esto ya que no entiendo cómo una falla que no permite privilegios de usuario elevados suma nada.

ACTUALIZACIÓN: Palabra oficial de Apple publicada aquí ; énfasis mío:

“La gran mayoría de los usuarios de OS X no corren el riesgo de vulnerabilidades de bash recientemente informadas”, dijo un portavoz de Apple a iMore. control de sistemas vulnerables. Con OS X, los sistemas son seguros de manera predeterminada y no están expuestos a vulnerabilidades remotas de bash a menos que los usuarios configuren servicios UNIX avanzados. Estamos trabajando para proporcionar rápidamente una actualización de software para nuestros usuarios avanzados de UNIX”.

Traducción: ¿Lo que dije anteriormente acerca de que esto es un problema del servidor y no un problema del cliente? Exactamente.

UNA ACTUALIZACIÓN FINAL: para cualquiera que tenga problemas para compilar desde el código fuente, a partir del 29 de septiembre, Apple ha lanzado oficialmente parches para Mac OS X 10.9.5, 10.8.5 y 10.7.5:

OTRA ACTUALIZACIÓN FINAL: ¡Y ahora, Apple acaba de lanzar hoy una actualización de seguridad combinada que también incluye la bashactualización !

Nota: La actualización de seguridad 2014-005 incluye el contenido de seguridad de OS X bash Update 1.0

"o un servidor web que ejecuta secuencias de comandos del lado del servidor", o tener una aplicación en ejecución, escuchando en un puerto abierto que permite realizar llamadas RPC que terminan ejecutando comandos de shell. Esto podría ser cualquier cantidad de cosas, ya que hay muchas aplicaciones estándar que hacen su RPC. Creo que esta respuesta es muy ingenua. Es muy fácil estar "ejecutando un servidor web" sin darse cuenta en el curso de la ejecución de una aplicación que hace algo del tipo cliente-servidor.
¿Se puede acceder a la cuenta de invitado de forma remota de forma predeterminada?
@IanC. ¿Puede proporcionar un ejemplo en el que OS X fuera de la caja sería verdaderamente vulnerable? Por ejemplo, ¿algo como WebEx o GotoMeeting se acercaría a las capacidades de Bash? El punto es que no puedo pensar en un escenario simple de instalación de OS X que realmente exponga las cosas. ¿Puedes?
La cuenta de invitado no está disponible para ssh. De hecho, ni siquiera es posible ponerlo a disposición de ssh, IIRC. El hecho es que, para la gran mayoría de los usuarios de OS X, la vulnerabilidad bash no es un problema en absoluto. Para aquellos de nosotros en los que es un problema, necesitamos volver a compilar bash tan pronto como esté disponible una solución probada, pero eso no es ahora.
@JakeGould todo lo que se necesita en un servidor en ejecución que posiblemente ejecute comandos a través del shell. Plex, por ejemplo, es uno de esos allí, donde está transcodificando y entregando videos desde su Mac en tiempo real. La transcodificación se realiza mediante un comando de shell y tiene una API abierta para interactuar con ella que no está autenticada. Gruñir es otro ejemplo. Los puertos abiertos con oyentes están por todas partes en su Mac. Incluso las aplicaciones que no escuchan pueden desembolsar inadvertidamente cuando reciben comandos.
@IanC. Bien, buenos ejemplos. Pero todavía te estás perdiendo el punto: ¿Cómo se puede explotar tal vulnerabilidad en cada ejemplo que proporcionas? En cada caso, un usuario necesitaría acceso al sistema para comenzar y luego, ¿qué? No estoy siendo frívolo con esto, pero todavía no entiendo cuál sería realmente el riesgo. Alguien, por ejemplo, tendría que abrirse camino a través de la API de Plex para luego hacer qué exactamente en bash para hacer algo fuera de los derechos de usuario y privilegios de acceso normales.
@danielAzuelos “¡Todo el mundo es vulnerable mientras la cuenta de invitado esté abierta :[!” La cuenta de invitado no tiene nada que ver con bash. Entonces, ¿el miedo se basa en qué exactamente? Además, incluso si la cuenta de invitado está abierta y de alguna manera bashse puede usar, ¿entonces qué? Por lo que veo, supongo que usar este exploit no tendría privilegios elevados ni nada parecido. En serio, estoy dispuesto a dar marcha atrás en mi postura, pero esto parece más un pánico basado en no mucho, mientras que OpenSSL fue un problema real.
¡+1 por ser una voz de cordura! Sí, técnicamente esto es un problema, pero buena suerte explotándolo, a menos que esté ejecutando un servicio que permite ejecutar comandos arbitrarios, y entonces, ¿adivinen qué? ¡Ya tienes un problema! Sé que esto es un poco más grave, ya que establecer una variable nunca debería ejecutar código, pero la mayoría de los programas pasan argumentos como argumentos, no como variables de entorno.
"Eso solo es aterrador si no lo piensas racionalmente". no puede ser subestimado. Esta misma regla se aplica a cualquier moda de seguridad, seguridad informática, seguridad nacional, seguridad personal. Los humanos son notoriamente fáciles de poner en modo de pánico y muy difíciles de sacar.
→ JakeGould: si la cuenta de invitado está activada, un usuario puede usarla. Luego, al usar la bashvulnerabilidad, puede obligar a cualquier demonio a ejecutarse como root y usar un bash para ejecutar cualquier comando con los privilegios de root . De forma predeterminada en Mavericks, la cuenta de invitado está desactivada y el sshacceso también está desactivado :).
@danielAzuelos Esto es completamente incorrecto: "Entonces, al usar la vulnerabilidad bash, puede forzar a cualquier demonio a ejecutarse como root y usar un bash para ejecutar cualquier comando con privilegios de root". ¿De dónde sacas la idea de que esta falla de shellshock/bash da como resultado privilegios elevados? no lo hace Si alguien inicia sesión como invitado en un sistema sin parches, simplemente estará ejecutando código como invitado. Si de alguna manera un invitado puede editar o influir en una cuenta raíz, esa falla no se debe a shellshock/bash sino a la falta de seguridad en el sistema en general.
-1 Muy mal. Hay muchas herramientas que usan bash: los scripts de instalación generalmente usan bash, lo que crea riesgos de escalada de privilegios. Se debe suponer que todos los servidores usan bash a menos que sepa lo contrario, no solo sshd. En particular, apache podría crear una vulnerabilidad remota usando bash. etc.
Es probable que también existan riesgos de escalada de privilegios de una cuenta de invitado. ¿A quién le importa? Cualquier máquina Mac OS X es extremadamente vulnerable una vez que los usuarios obtienen acceso, especialmente los usuarios locales. Son los demonios del servidor los que deberían asustarte, no solo sshd, sino todos los demonios del servidor.
@JeffBurdges “Apache podría crear una vulnerabilidad remota usando bash. etc." ¿Cómo? Está diciendo que existen riesgos de escalada, pero ¿cómo podría un usuario sin privilegios escalar sus privilegios de esta manera? Apache no tiene privilegios especiales y debe modificarse conscientemente a través de los derechos de configuración o sudo para poder hacer cosas de raíz.
Los módulos de Apache, los scripts CGI, etc. comúnmente llaman a bash. Un truco muy efectivo aquí: twitter.com/JZdziarski/status/515135854436962304 E incluso si su configuración de Apache no llama a bash en condiciones normales de operación, no se sabe qué puede convencer un atacante para que haga.
Como dije a continuación, se debe suponer que TODOS los servidores llamarán a bash a menos que se demuestre lo contrario. Y Mac OS X está lleno de exploits de escalada de privilegios una vez que llega a un shell.
De hecho, ¡tu respuesta es totalmente incorrecta! El uso ordinario de ssh no es vulnerable ya que ya está abriendo un shell, solo el comando de inicio de sesión restringido de ssh es vulnerable. Casi ningún usuario de Linux lo sabe, así que ningún usuario de Mac lo sabe.
@JeffBurdges Los ejemplos que proporciona se refieren a explotaciones del servidor. Y si realmente sigues los hilos de esos, todo es bastante teórico sin que nadie confirme que funcionan. En lo que respecta a un usuario de Mac OS X de escritorio, el pánico es excesivo. Pero si usted es un administrador del servidor, debe estar preocupado. Pero, por favor, continúe alentando a los novatos a parchear los suyos bashmanualmente desde la fuente. Habrá TONELADAS más de daño en las máquinas de los clientes debido a consejos como este que los que se producirían con cualquier exploit verdadero de "Shellshock".
@JeffBurdges Si cree que mi respuesta es un peligro, sus publicaciones de TOC aquí demuestran lo contrario. Como dije, dé un paso atrás y analice esto racionalmente: esto es un riesgo para los SERVIDORES. No a CLIENTES. Este foro y esta pregunta son sobre Mac OS X y principalmente del lado del CLIENTE. Entonces, vote hacia abajo o marque, pero su TOC, comportamiento de pánico dice mucho en contra del caso que está presentando.
Ya mencioné que recompilar bash es una exageración. La respuesta correcta para los usos ordinarios de escritorio es activar el firewall y desactivar los servicios compartidos O aceptar que confían en el firewall proporcionado por su enrutador. Eso es lo que dice mi comentario. Selecciona un servidor probablemente generalmente no vulnerable, ssh, e ignora que mucha gente está haciendo un servidor web local rudimentario con secuencias de comandos activas desconocidas.
@JeffBurdges “Ya mencioné que volver a compilar bash es una exageración. La respuesta correcta para ” Tus comentarios de TOC están arruinando tu capacidad para publicar. O te calmas o paras. No borro mi respuesta. Si no está de acuerdo con eso, acéptelo. Si cree que su respuesta es más destacada, espero con ansias la gran cantidad de votos a favor que obtendrá su consejo sabio y sensato. ¡Salud!
je. A los cuadros de edición SE no les gusta el corrector ortográfico de Mac, siempre crea comentarios prematuros. Lo siento por eso. De todos modos..
@JeffBurdges: con respecto a "Los scripts de instalación generalmente usan bash, lo que crea riesgos de escalada de privilegios", ¿por qué un script de instalación malicioso necesitaría usar este exploit? Si el usuario está instalando un script de instalación malicioso (un caballo de Troya), entonces el código no necesitaría invocar este error, ya que se rootea de todos modos.
Los clientes también pueden ser vulnerables. trustsec.com/september-2014/shellshock-dhcp-rce-proof-concept
@nyuszika7h ¡Ahhhh! Bueno. Esto es exactamente lo que estaba buscando. Básicamente, si un servidor DHCP es pirateado y se implementa el exploit bash, si bash no está parcheado, entonces podría ser una víctima. Excelente ejemplo. Debe publicar esto como una respuesta para un voto a favor.
Se trata de FUD, percepción y realidad. Los riesgos para el 99% de los usuarios de Mac son inexistentes. PERO: eso no es excusa para que Apple demore en obtener una solución adecuada. Después del alboroto de icloud-gate, habría pensado que la alta gerencia de Apple estaría seriamente preocupada por algo que empaña la imagen de Apple. Como usuario habitual, me preocuparía que Apple no tape ese agujero, ¡especialmente porque es tan fácil de observar usando una sola línea de código!
@AlbertGodfrind "...Apple estaría seriamente preocupado por algo que empaña la imagen de Apple". Apple en 2014 realmente no se preocupa por los problemas de uso del escritorio como solía hacerlo. Se trata de iDevices, iOS y mercantilizar ese espacio. Lo cual es otra discusión completamente diferente, pero el crecimiento exponencial de Apple ha distorsionado su visión del mercado que no es de iOS.
Existe un exploit público de escalada de privilegios disponible para VMWare Fusion (que generalmente solo se instala en los clientes): packagestormsecurity.com/files/128425/…
@ScottDudley: Eso no tiene nada que ver con VMWare. Y no tiene nada que ver con Mac OS. Simplemente muestra que si ejecuta Linux en una VM, esa instalación es sensible a la vulnerabilidad de bash si aún no se ha parcheado. Ejecuto varias máquinas virtuales Linux en mi computadora portátil (usando Virtualbox) y todas son vulnerables porque aún no las he parcheado. No ejecutan ningún servidor web y solo se puede acceder a ellos desde mi host.
@AlbertGodfrind, eso es incorrecto; lea la página nuevamente. Esa página afirma contener un exploit de escalada de privilegios de OS X (admito que no lo he probado). Parece ser un exploit contra la instalación de VMWare Fusion en OS X, y no tiene nada que ver con Linux en absoluto. Una lectura rápida del código sugiere que es posible que Fusion ni siquiera necesite estar ejecutándose para explotarlo.
@ScottDudley Su evaluación del exploit con VMWare Fusion es correcta. Pero no está del todo claro cómo una carga útil llegaría a una máquina host para causar el daño. ¿Cómo comenzaría el exploit con el uso en el mundo real en un cliente o incluso en una máquina servidor?
@JakeGould es una escalada de privilegios, por lo que amplía la superficie de ataque, y ahora una debilidad en cualquier proceso de usuario se puede combinar con esto para obtener la raíz. Por ejemplo, las personas de arriba estaban hablando de cómo si httpd fuera explotado (¡lo que no tiene por qué suceder usando la falla de bash!), Entonces solo te quedaría el acceso a la zona de usuario ejecutándose como el usuario de apache. Si tiene Fusion y bash no está parcheado, una vez que obtenga el usuario, también puede obtener la raíz. Elija entre las vulnerabilidades de varios procesos de usuario en <=10.9.4.
@ScottDudley Te estás perdiendo el punto: ¿Cómo llegaría esa secuencia de comandos al punto en que podría hacer eso? Ese script no puede estar fuera de la máquina que ejecuta VMWare Fusion, ¿verdad? ¿Cómo llega al interior?
@JakeGould, explota cualquier vulnerabilidad de proceso de usuario (que podría ser a través de shellshock o a través de cualquier otro problema con los procesos de un usuario, digamos, una de las vulnerabilidades en el enlace anterior). Por eso se llama escalada de privilegios: en.wikipedia.org/wiki/Privilege_escalation
@ScottDudley Entiendo qué es la escalada de privilegios. Entiendo el riesgo. ¿Leíste mi respuesta y los comentarios anteriores? Pero en el caso que está destacando, es difícil para mí entender cómo una máquina OS X básica sería vulnerable a lo que está mostrando. Si no lo entiendes, lo siento. Lea sobre cómo funciona este error y descubra cómo para los usuarios de clientes de Mac OS X no es tan importante, incluso si no se corrige.
@JakeGould, sí, leí la respuesta y entiendo los matices. Aquí hay un ejemplo simple. Algunos spambots envían por correo electrónico un archivo PDF malicioso a su @mac.comdirección. No hace nada más que pasar el mensaje en Mail.app, que muestra el PDF en el panel de vista previa, que luego activa la carga útil (CVE-2014-4377). Su bash sin parches podría convertir este exploit de usuario (malo) en un exploit de nivel raíz (peor).
@ScottDudley Bien, ¡ahora lo dejaste más claro! Pero lo que sugeriría es que publique esa información en una respuesta aquí para que otros puedan comprender mejor los riesgos de borde de esto.

¡Sí!

Escriba esto en su caparazón

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

Si dice vulnerableque eres vulnerable.

si dice

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello

entonces eres bueno

Editar: enlace a la solución

Gracias. Actualicé la pregunta: si descubrimos que somos vulnerables, ¿cómo puede solucionarlo un usuario de Mac?
@abbyhairboat publicó mi respuesta. A menos que esté ejecutando un servidor expuesto al mundo exterior, no existe ningún riesgo práctico. Los administradores del servidor son los que deben preocuparse por esto.
→ abby: vea esta respuesta relacionada: apple.stackexchange.com/a/146851/22003 .
Intente esto env X="() { :;} ; echo busted" /bin/sh -c "echo completed": incluso después de parchear mi sistema, este arroja un 'roto' en la línea de comando. Bah.
Parece que zsh también es vulnerable.
@Mark no, zsh es seguro. necesita reemplazar "bash -c" con "zsh -c" para probarlo.
Parcheé bash 3.2 de Mac OS X e incluí instrucciones aquí: github.com/ido/macosx-bash-92-shellshock-patched/blob/master/…
@TraneFrancks: Apple usa bash en /bin/sh... necesita reemplazar ambos /bin/sh y /bin/bashestar protegido. /bin/shes en realidad más problemático, ya que es el shell que es probable que utilicen los lenguajes de secuencias de comandos para ejecutar comandos de shell.
@Joe, soy muy consciente de lo que necesita parches. Escribí un tutorial sobre el proceso aquí: apple.stackexchange.com/a/146943/91441 El artículo también estaba aquí, pero los moderadores lo eliminaron por ser un duplicado. bashEl problema era que compilar desde el código fuente de Apple con xcodebuild haría ambas cosas shen un solo paso. Construir a partir de la fuente Vanilla GNU requiere compilaciones separadas. Además, bashbugtiene una ubicación de instalación diferente en OS X que la salida de GNU, por lo que también debe moverse.
@nyuszika7h ¡Ahhhh! Bueno. Esto es exactamente lo que estaba buscando. Básicamente, si un servidor DHCP es pirateado y se implementa el exploit bash, si bash no está parcheado, entonces podría ser una víctima. Excelente ejemplo. Debe publicar esto como una respuesta para un voto a favor.

Como usuario final , compruebe que:

  • su cuenta de invitado está desactivada:

    Preferencias del sistema > Usuarios y grupos > Usuario invitado

  • su sshacceso está desactivado:

    Preferencias del sistema > Compartir > Inicio de sesión remoto

De forma predeterminada, ambos están desactivados en Mavericks.

Como usuario final , es más seguro esperar una actualización de seguridad oficial de Apple que solucione esta bashvulnerabilidad.

Estos son irrelevantes. Cualquiera de estos, por su propia naturaleza, otorga a los usuarios acceso para ejecutar comandos en el sistema, por lo que si los tiene habilitados, su intención es permitir que los usuarios ejecuten comandos. El error de Shellshock es un medio para que los usuarios que no tenía la intención de poder ejecutar comandos puedan hacerlo, por ejemplo, un usuario del servidor web que ejecuta. Por lo tanto, su respuesta debería decir "Deshabilitar el uso compartido en la web" (pero eso es solo una cosa que debe verificar)
Me molesta que Apple no aconseje desactivar esa configuración. ¿Quién los habilitaría? Me gustaría. Soy usuario de Mac desde 1986, desarrollador de aplicaciones web a tiempo completo (así que ssh es mi vida) y padre (así que una cuenta de invitado para los niños no es tan mala idea). Conozco a muchas personas que son como yo en estos aspectos que usan computadoras portátiles Apple. ¿Quieres perdernos? Dejar esta vulnerabilidad abierta es una buena manera.

Todas las máquinas Mac OS X son técnicamente vulnerables a "Shellshock", hasta que Apple publica una actualización de seguridad que parchea bash, pero...

Tu pregunta debería ser: ¿Puedo ser hackeado de forma remota?

Hay tanto software que se usa bashdistraídamente que responder a esa pregunta es extremadamente difícil. Si está preocupado, le sugiero varios cambios System Preferencespara evitar exploits remotos:

  • Deshabilite TODOS los servicios compartidos en Preferencias de uso compartido.
  • Habilite el Firewall en Seguridad y privacidad.

Si está particularmente preocupado, presione el Firewallbotón de opciones para:

  • Desmarque Automatically allow signed software to receive incoming connections.
  • comprobar Block all incoming connections_

Todavía existe una posibilidad respetable de que seas vulnerable a un ataque de nivel usando DHCP, Bonjour, etc., pero bueno, si necesitas otro servicio, obviamente puedes dejarlo funcionando mientras esperas que no sea explotado. Y también deberá dejar el cortafuegos más abierto. Es probable que esté bien si su máquina vive detrás de otro firewall.

Además, ¿hay ataques de escalada de privilegios locales habilitados por "Shellshock"? Sí, casi seguro. Sin embargo, no me preocuparía porque Mac OS X tiene suficientes ataques similares. Apple no repara rápidamente los errores de escalada de privilegios locales. Y Apple los crea con frecuencia con los servicios habilitados para Apple Script. Simplemente suponga que todas las máquinas Mac OS X siempre son vulnerables a los ataques locales. Si necesita asistir a conferencias de piratas informáticos como DEFCON, cómprese una caja de Linux para ese propósito.

Actualización: hay instrucciones para volver a compilar su propio bash fijo y también se cubren otras preguntas . Lo haré yo mismo, pero en mi humilde opinión, eso es excesivo si no ejecuta ningún servidor y mantiene el firewall de Apple activado de todos modos.

Actualización: si se siente cómodo con el uso de la terminal, hay un programa llamado execsnoopmencionado aquí que le permitirá probar si los procesos del servidor suelen llamar a bash. No es una bala mágica ya que el proceso del servidor puede llamar a bash solo en situaciones inusuales, pero le dará una buena idea.

Finalmente, Apple no es muy bueno parcheando las vulnerabilidades de seguridad, pero son buenos en relaciones públicas, por lo que esto se parcheará relativamente rápido. Por lo tanto, es razonable pensar "No necesito correr más rápido que el oso, solo necesito correr más rápido que la gran cantidad de servidores fácilmente explotables en Internet". :)

No hay posibilidad de que las Mac sean vulnerables a un ataque usando DHCP, ya que no usa Bash.
¿Como sabes eso? El aviso inicial era un cliente DHCP vulnerable. Y muchos artículos especulan que los clientes DHCP de Mac OS X y/o iOS pueden ser vulnerables. Se debe suponer que todos los servidores son vulnerables a menos que se demuestre lo contrario.
No, no deberían serlo; eso es FUD absoluto. Puede examinar tanto el código fuente abierto para la implementación de dhcp de OS X como medir las llamadas del sistema para verificar.
@JeffBurdges, OS X no ha usado shell exec con DHCP desde 10.3, y antes de eso bash no estaba instalado en el sistema. DHCP en OS X simplemente no es un problema con Shellshock. (Una cosa menos de la que preocuparse. :))
→ Jeff: por favor considere: strings /usr/libexec/bootpd | egrep '/bin|bash'y nm -a /usr/libexec/bootpd | egrep 'fork|exec'. Al leer el resultado de estos comandos en diferentes versiones de MacOS X, es posible que reconsidere su análisis de riesgo debido a dhcpdMacOS X... pero solo este :(.
No exactamente. Se debe revisar los símbolos llamados por la biblioteca que otool -L /usr/libexec/bootpdinforma que contiene una execllamada. Y el stringscomando no tiene sentido ya que las variables de entorno determinan el shell llamado. Sin embargo, estoy impresionado de que no le hayan gustado las llamadas a la biblioteca system.
@JeffBurdges, entonces, ¿agregar "|SHELL" a la cadena de búsqueda de egrep (para la salida de cadenas) no captaría eso?
Además, sobre eso otool -L, el único resultado que recibo es una lista de bibliotecas (CoreFoundation, SystemConfiguration, OpenDirectory, libresolv.9.dylib y libSystem.B.dylib)
Sí strings .. | grep SHELLes mucho más útil que bash, pero no absoluto. Imho nm -a ... | grep systemes el más importante, y exectambién ayuda, pero eso es solo para el software BSD, Linux, etc. de vainilla. Las bibliotecas de Apple ofrecen diferentes rutinas. Simplemente use la forma Cocoa, por ejemplo: stackoverflow.com/questions/412562/…
No es gran cosa, pero ustedes están diciendo repetidamente cosas que son técnicamente incorrectas. No puedes estar 100% seguro sin hacer más trabajo de campo. Apple podría haber hecho ese trabajo preliminar para sus servidores que permanecen con el firewall habilitado antes de emitir su declaración, pero en realidad dudo que hayan hecho tanto. Probablemente esté bien, pero uno debería reventar las chuletas de Apple por ser tan dolorosamente lento para arreglarlo bash.
Soy usuario de Snow Lion y veo que Apple no ha planeado hacer nada para 10.6.8. Pero ahora he hecho una visita a las Preferencias del sistema, que modifiqué al nivel más paranoico en sus sugerencias. gracias jeff

Creé esta herramienta tan pronto como me enteré de esta vulnerabilidad. Le proporcionará un enlace a un artículo para parchear su caparazón si la herramienta determina que es vulnerable.

Requiere Mac OS X 10.6 y superior.

Tal vez sea solo yo... pero la idea de ejecutar el código de una persona al azar para probar un exploit parece una muy mala idea cuando puedes pegar fácilmente una cadena (eso es claramente solo ejecutar la prueba y nada más) en un ventana de terminales
Acepto, por eso la fuente está en code.google.com/p/shellshock-check
A veces, sin embargo, puede ofrecer facilidad de uso para probar múltiples sistemas.
No veo el beneficio de esta cosa. Es mucho más fácil comprobar la vulnerabilidad pegando una simple línea de comando en la ventana del terminal.
Sin embargo, cuando pruebo varias máquinas, especialmente en mi caso, ya que eso es lo que hago, poner una unidad flash y abrir Shellshock Check.app es mucho más fácil que abrir Safari, buscar el comando bash para verificar, luego abrir Terminal, pegar eso comando y luego presionando Enter. Es mucho más rápido conectar una unidad flash y abrir una aplicación.
Si necesita verificar varios sistemas, simplemente use un script de shell simple para probar la vulnerabilidad, colóquelo en su dispositivo de memoria y ejecútelo desde el dispositivo (simplemente ábralo para ejecutarlo).
Por otra parte, es posible que desee verificar esa unidad flash en busca del error BadUSB ( srlabs.de/badusb ) :-)
¿Son las Mac vulnerables al error shellshock de Bash?
RespuestasAquíPolítica de privacidad1y, 0v