¿Reemplazar a bash con otro shell es un paso prudente?

Para determinar definitivamente el grado en que esto podría o no ser "un paso prudente", creo que tendría que hacer una investigación de seguridad original sobre los posibles reemplazos, que incluyen:

• El guión de Debian
• ksh de OpenBSD
• ceniza de Busybox
• MirBSD / MirOS mksh
• ... y ciertamente otros

La respuesta de Mark sugiere que al menos OpenBSD ya ha recibido un escrutinio de seguridad, pero no estoy seguro de la extensión o si existe evidencia que respalde esto (claramente, no aplicaron ningún escrutinio a una piedra angular de la seguridad de las comunicaciones (OpenSSL ) hasta hace poco, cuando lo bifurcaron en LibreSSL). Por otro lado, para mí es bastante claro que nadie se había molestado en leer la fuente de seguridad de Bash hasta hace poco, o que se habría descubierto un "proyectil" hace mucho tiempo; Todo lo relacionado con la "función de importación" es una gran señal de advertencia que cualquier investigador de seguridad analizaría tan pronto como lo viera (y con suerte recomendaría la función completa para su eliminación). Pero para los demás, no es tan claro.

Lo que está claro, sin embargo, es que todo lo anterior tiene una superficie de ataque mucho más pequeña que Bash. Para que un atacante tome el control de un programa, tiene que haber algún canal de entrada. Por supuesto, estas pueden ser cosas no obvias como límites de recursos, reloj del sistema, etc., pero aún son entradas; un programa sin absolutamente ninguna entrada es trivialmente no vulnerable. El error de diseño de seguridad en Bash es que está tomando entradas no confiables (los contenidos de variables de entorno arbitrarias) y las somete a un procesamiento complicado (análisis como código). Por otro lado, que yo sepa, ninguno de los shells listados arriba realiza ningún procesamiento del contenido de las variables de entorno (excepto las individuales con un significado establecido específico como LANG y LC_* , ENV , IFS , PATH , PS1 , etc.) u otra entrada; simplemente tratan los contenidos como datos abstractos que se pasan.

Desde el punto de vista del diseño de seguridad, incluso sin auditar estas alternativas, estimaría que son opciones más seguras que Bash. Si eso seguirá siendo el caso no está claro. Ciertamente, Bash está recibiendo mucha atención en este momento, y es menos probable que otros shells reciban, por lo que podríamos terminar con la mayoría de los problemas en Bash, mientras que los problemas en otros shells siguen siendo desconocidos. Entonces tiene varios factores a considerar, como si es probable que sea un objetivo individual, en cuyo caso el uso de software menos convencional puede ser una responsabilidad.

Personalmente, uso Busybox ash en la mayoría de los lugares. Si nada más, tanto ash como dash usan aproximadamente 1/5 de la memoria de bash y comienzan de 2 a 8 veces más rápido, por lo que también son opciones muy prácticas desde un punto de vista no de seguridad.

El único shell que conozco que ha sido inspeccionado seriamente por problemas de seguridad es la variante de OpenBSD de ksh , y no sé si se puede instalar en un sistema Linux. Aparte de eso, la única ventaja de seguridad de cambiar el shell de su sistema es que al usar un shell menos común, menos personas lo atacarán, pero de la misma manera, menos personas buscarán errores en el shell elegido.

Debian / Ubuntu evitó la mayoría de los problemas porque tenían dash como shell de su sistema, y las distribuciones de enrutadores * WRT lo hicieron porque usan busybox , pero ninguno seleccionó su shell por razones de seguridad. En ambos casos, se seleccionó el shell alternativo para mejorar el rendimiento al reducir los tiempos de carga y la huella de memoria.

Es un poco ridículo reaccionar ante una vulnerabilidad que se encuentra en un producto al reemplazarlo por otro. Vea el clásico WW2 problema de la encuesta de supervivencia del bombardero por la razón. Esencialmente, estás reaccionando a un incidente raro e improbable como si fuera una prueba definitiva de la seguridad de Bash contra la de otros proyectiles.

Tenga en cuenta que los ataques visibles no dicen absolutamente nada sobre el número de no revelados y sobre el número de vulnerabilidades existentes en el software. Podría ser que Bash esté plagado de errores o que, después de pasar por un escrutinio, esté completamente libre de vulnerabilidades. El problema es que nadie puede hacer ninguna reclamación hasta que todos el código de todos se hayan examinado minuciosamente las carcasas o, incluso, se haya demostrado que son correctas.

Estaría mejor con métricas sobre la calidad del código que está escribiendo cada proyecto y su capacidad para detectar y corregir errores y para responder a incidentes críticos en lugar de especular sobre un puñado de vulnerabilidades.

Debian y Ubuntu ya lo hacen usando dash en lugar de bash para /bin/sh . Por supuesto, esto sustituye a una base de código menos inspeccionada en una pieza clave de la infraestructura del sistema, por lo que es una clara posibilidad de que tenga vulnerabilidades desconocidas de igual impacto que las recientes bash problemas.     

Todo lo que haga sobre esta vulnerabilidad debe basarse en un análisis de los vectores de riesgo potenciales reales. El simple hecho de usar el shell como su shell interactivo, para ser extremo, no conlleva riesgos por este error.

El error solo existe cuando algún programa permite que una parte hostil controle el contenido de las variables de entorno como se ve por una invocación del shell. Por ejemplo, un servidor web que establece una variable de entorno al valor del encabezado del agente de usuario desde una solicitud y no la desinfecta. Si ejecuta un servicio de este tipo, tiene sentido, con o sin este error, utilizar el shell más simple posible. Cuanto menos haya en el shell, menos lugares podrían haber exposiciones de seguridad. Por supuesto, sería mejor si el servidor web se estuviera ejecutando en una cárcel que resolviera toda esta cuestión. Por lo tanto, si debe ejecutar un servidor web o algo similar que inicie shells en entornos no aislados, reducir la exposición ejecutando el shell más simple disponible tiene sentido.