¿Se puede reemplazar bash por completo en OS X?

Debido a CVE-2014-6271 y CVE-2014-7169 en OS XI, me preguntaba: ¿se puede reemplazar bash completamente por otro shell no afectado (por ejemplo, dash u otros)?

Formule la parte de la explotación de DHCP de esta pregunta como una nueva pregunta. Gracias.

Respuestas (6)

Primero, no necesita hacer esto a menos que esté ofreciendo servicios web a la Internet pública desde su Mac. Si no lo está, espere hasta que haya una actualización de seguridad oficial de Apple.

Sin embargo, si está ofreciendo servicios web, es posible que desee actualizar.

Parche Oficial

Apple ha lanzado una actualización oficial de seguridad de Bash aquí

Comprobar si eres vulnerable

Primero confirme que está utilizando un bash desactualizado:

$ which bash
/bin/bash
$ /bin/bash --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
Copyright (C) 2007 Free Software Foundation, Inc.

El bash más actual es 4.3.25

Si no tiene instalado Xcode, necesitará las herramientas de línea de comandos de Xcode, que puede instalar

$ xcode-select --install

O desde el portal de desarrolladores .

Para instalar Brew ( http://brew.sh ):

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Entonces hazlo:

$ brew doctor

Siga las instrucciones si hay problemas. Muchos problemas comunes se abordan aquí .

Luego actualice brew a la última lista de paquetes:

$ brew update

Para obtener el último bash 4.3.25:

$ brew install bash

Esto instala bash en/usr/local/Cellar/bash/4.3.25/bin/bash

El antiguo bashy shtodavía existe en /bin, por lo que después de la instalación cambiará el nombre de los ejecutables antiguos a un archivo nuevo.

$ sudo mv /bin/bash /bin/bash_old
$ sudo mv /bin/sh /bin/sh_old

Si es muy paranoico, puede eliminar los permisos de ejecución en elbash_old

$ sudo chmod a-x /bin/bash_old /bin/sh_old

Luego cree un enlace simbólico al nuevo bash 4.3.25 que instaló brew.

$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash
$ sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh

Reinicie y está completo.

Una advertencia: esto puede romper algunos scripts de shell existentes que pueden depender de bash 3.2 o las diferencias que tiene Mac shsobre Linux sh. Hay una respuesta mucho más sofisticada para reemplazar bash y sh de las fuentes en esta publicación.

En la mayoría de los casos, lo mejor es esperar a las actualizaciones oficiales.

“En la mayoría de los casos, es mejor esperar las actualizaciones oficiales”. A menos que alguien esté ejecutando un servidor, nada de esto es realmente necesario. Muchas personas romperán sus instalaciones de OS X en los próximos días, ya que entrarán en pánico para neutralizar una amenaza que apenas entienden.
@JakeGould - Estoy de acuerdo.
Copiaría los archivos en lugar de vincularlos; si por alguna razón elimina la instalación de brew, su sistema tiene un problema...
Creo que apple.stackexchange.com/a/146851/83347 es la mejor respuesta, porque usa fuentes de Apple...

Como dijo @webmarc, no. Puede reemplazarlo /bin/bashcon algún otro shell, pero seguramente romperá algunos programas porque bash tiene varias diferencias en su sintaxis que lo hacen incompatible. No pude encontrar un shell alternativo compatible con bash. Sin embargo, hice un enlace simbólico a dash /bin/shy no encontré ningún problema hasta ahora.

Con respecto al DHCP aquí hay un ataque de prueba de concepto. El artículo trata sobre dhcpcd(un cliente Linux). No estoy seguro acerca de Mac OS X. En la discusión sobre Hacker News dicen que el cliente OS X no usa bash en absoluto.

Otro vector podría ser sshd. Pero el ataque requiere autenticación. Entonces, a menos que esté ejecutando algún servicio ssh como un gitservidor, debería estar seguro.

"En la discusión sobre Hacker News, dicen que el cliente OS X no usa bash en absoluto". ¿Dónde está esta discusión? Debe proporcionar un enlace.
@JakeGould El enlace ya está en la respuesta. Lee los comentarios.

dashcontiene solo un pequeño subconjunto de los comandos que se encuentran en bashe even sh(que a su vez es un subconjunto de cosas en bash). Reemplazar cualquiera de los dos dashseguramente generará scripts inoperables en su sistema y posiblemente dañará su sistema más de lo que lo protege.

Puede volver a compilar bash para mitigar algunos (en el momento en que se escribió esto) de peligro potencial o esperar a que Apple lance una solución oficial.

Desafortunadamente, no... varios shells tienen sintaxis diferentes, lo que hace que los scripts escritos para un shell sean posiblemente incompatibles con otro shell.

No he visto la infección basada en DHCP de la que habla, ¿puede proporcionar un enlace en su pregunta?

algunos sitios indican que uno podría estar infectado a través de un cliente DHCP.

Esto no se aplica a OS X. En los sistemas Linux, generalmente se llama a un script de shell después de recibir una concesión de DHCP del servidor. Este no es el caso en OS X.

A menos que esté ejecutando un servidor web en su Mac que sirve scripts CGI, tiene pocas razones para preocuparse.

Sí, si quiere decir como /bin/sh, pero podría ser problemático, pero si desea reemplazar bash como /bin/bash o eliminar bash por completo, básicamente no, aunque no es imposible, ya que los scripts son archivos de texto, podría editar cada script de shell y luego mantener el sistema usted mismo, por sí mismo, por el resto del tiempo... No hay un reemplazo directo para bash.

No es que reemplazar /bin/sh sea fácil, pero podría terminar. Si una secuencia de comandos asume su /bin/sh , en realidad es bash, y usa cosas únicas para bash, entonces la secuencia de comandos que comienza #!/bin/sh ahora se rompería. Cambié el nombre de mi /bin/sh a /bin/sh.was.bash y luego hice sh un enlace a mksh, y reiniciado fue recibido con el indicador #. Reinicié de nuevo con el indicador detallado y encontré algunas líneas en /etc/rc -- export -n, algo bash, el equivalente de korn shell es typeset +x, modifiqué el script rc, y arrancó, y c/ todo bien. El sistema con el que estoy experimentando es Tiger, por lo que hay un script rc y no puedo esperar actualizaciones de Apple. OSX moderno no tiene un script rc, PERO las aplicaciones modernas pueden ir de intel linux, donde /bin/sh es bash, a intel-mac, donde /bin/sh también es bash,

Entonces, tal vez debería decir muy problemático, porque deberías tomarlo como una razón para NO hacer esto. En mi defensa, he estado hurgando con los demonios de lanzamiento y los scripts rc, esta semana y la semana anterior, jugando con las opciones de dynamic_pager, desactivando algunos demonios de lanzamiento (haciéndolos controlables por variables en hostconfig), así que para mí , esto es solo un experimento un poco más radical de lo que podría haber hecho hoy, de todos modos.

SI desea hacer algo, si cree que podría ser más vulnerable que otros, debido a un software adicional, etc., puede mirar cada secuencia de comandos que le preocupa y cambiar la primera línea (el shhbang) para hacer algo que no sean #!/bin/sh o #/bin/bash, y prepárese para editar los scripts, ya que podrían tener características específicas de bash. BASH es realmente un shell tipo korn, más que un shell tipo bourne como ash o dash, así que si quieres mantener las ediciones triviales, usa un shell korn como reemplazo. De hecho, en tiger /bin/ksh está el "NUEVO Korn Shell", si esto sigue siendo cierto, yo diría que siga con eso, entonces no necesita instalar nada y dejar /bin solo, lo cual no es una mala idea. , simplemente cambie los scripts a #!/bin/ksh, elimine los bashisms para las características, comunes a korn shell, pero podría tener suerte y no habría ninguno.

Existe la posibilidad de que se ignore 'shhbang', ya que si se invoca un script de shell como "/bin/sh /etc/rc", entonces la primera línea es solo un comentario y se ignora, pero con este enfoque solo puedes romper las cosas que cambias, a medida que las cambias.