Debido a CVE-2014-6271 y CVE-2014-7169 en OS X, me preguntaba: ¿puede bash ser reemplazado por completo por otra shell no afectada (por ejemplo, guión u otros)?
Debido a CVE-2014-6271 y CVE-2014-7169 en OS X, me preguntaba: ¿puede bash ser reemplazado por completo por otra shell no afectada (por ejemplo, guión u otros)?
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.
Apple ha lanzado una Actualización oficial de seguridad de Bash aquí
Primero confirma que estás usando un bash obsoleto:
$ 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 se pueden instalar mediante
$ xcode-select --install
O desde el portal del desarrollador .
Para instalar Brew ( enlace ):
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Entonces haz:
$ brew doctor
Siga las instrucciones si hay problemas. Muchos problemas comunes se tratan aquí .
Luego actualice la preparación 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
Los antiguos bash
y sh
aún existen en /bin
, así que después de instalar, cambiará el nombre de los archivos ejecutables antiguos a un archivo nuevo.
$ sudo mv /bin/bash /bin/bash_old
$ sudo mv /bin/sh /bin/sh_old
Si eres muy paranoico, puedes eliminar los permisos de ejecución en el bash_old
$ sudo chmod a-x /bin/bash_old /bin/sh_old
Luego cree un enlace simbólico al nuevo bash 4.3.25 que se instaló.
$ 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
Reinicia y está completo.
Una advertencia: esto puede romper algunos scripts de shell que pueden depender de bash 3.2 o las diferencias que Mac sh
tiene sobre linux sh
. Hay una respuesta mucho más sofisticada para reemplazar bash y sh de fuentes en esta publicación.
En la mayoría de los casos, es mejor esperar las actualizaciones oficiales.
Como dijo @webmarc, no. Puede reemplazar /bin/bash
con algún otro shell, pero ciertamente romperá algunos programas porque bash tiene varias diferencias en su sintaxis que lo hicieron incompatible. No pude encontrar un shell alternativo compatible con bash. Sin embargo, me vinculé con el guión a /bin/sh
y no encontré ningún problema hasta ahora.
En cuanto al DHCP aquí hay un ataque de prueba de concepto.
El artículo es sobre dhcpcd
(un cliente de Linux). No estoy seguro de Mac OS X. En la discusión de 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 servidor git
debería estar seguro.
dash
contiene solo un pequeño subconjunto de los comandos encontrados en bash
e incluso sh
(que a su vez es un subconjunto de cosas en bash
). Reemplazar con dash
seguramente producirá scripts inoperables en su sistema y posiblemente romperá su sistema más de lo que protege su sistema.
Puede recompile bash para mitigar un poco de peligro potencial (en el momento en que se escribió esto) o espere a que Apple se lance y la solución oficial.
Desafortunadamente, no ... varias shells tienen sintaxis diferentes, lo que hace que los scripts escritos para una shell posiblemente sean incompatibles con otra 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.
Este no se aplica al OS X. En los sistemas Linux, generalmente se llama a un script de shell después de recibir una concesión 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 te refieres a / bin / sh, pero podría ser problemático, pero si quieres reemplazar a bash como / bin / bash o eliminar a bash por completo, básicamente no, aunque no es imposible, ya que los scripts son archivos de texto, puede editar cada script de shell y luego mantener el sistema usted mismo, por sí mismo, durante el resto del tiempo ... No hay un reemplazo directo para bash.
No, que reemplazar / bin / sh sería fácil, pero podría haber un final para ello. Si un script presupone que tu / bin / sh es en realidad bash, y usa cosas únicas para golpear, entonces el script que comienza #! / bin / sh ahora se rompería. Cambié el nombre de mi / bin / sh a /bin/sh.was.bash y luego hice un enlace a mksh, y el reinicio fue recibido con un # prompt. Reinicié de nuevo con la bandera verbosa, y encontré algunas líneas en / etc / rc - exportar -n, una cosa bash, el equivalente de shell korn es componer + x, Modifiqué el script rc, y, y arranqué, y con todo bien. El sistema en 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 desde Intel Linux, donde / bin / sh es bash, a intel-mac, donde / bin / sh también es bash, y un desarrollador podría fácilmente agregar bashismos para lanzar daemons y agentes de lanzamiento, y si no ahora, pero más tarde cuando se apuren a una actualización (para su aplicación), que ahora solo entrará en su sistema.
Entonces, tal vez debería decir muy problemático, porque debes tomarlo como una razón, NO para 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 haberlo hecho hoy, de todos modos.
Si quieres hacer algo, si piensas que puedes ser más vulnerable que otros, debido al software adicional, etc., puedes ver cada script que te preocupa y cambiar la primera línea (el shhbang) para hacer algo que no sea #! / 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 en realidad una cáscara tipo Korn, más que una cáscara de estilo bourne o ceniza, por lo que si desea mantener las ediciones triviales, use una cáscara Korn como un reemplazo. De hecho, en tiger / bin / ksh está el "NUEVO Korn Shell", si esto sigue siendo cierto, diría que con eso, entonces no necesita instalar nada y dejar / bin solo, lo cual no es una mala idea, solo cambie los scripts a #! / bin / ksh, elimine los bashismos para las características, comunes a korn shell, pero podría tener suerte y no habría ninguno.
Existe la posibilidad de que 'shhbang' se pueda ignorar, 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.