Confío en su palabra de que Apple fue el último en parchar, pero debemos tener en cuenta que pusieron a disposición versiones fijas de bash antes de que formara parte de una actualización general de software. Por lo tanto, las personas que ejecutaban servicios en un sistema en el que había algún tipo de ruta de inyección desde el servicio hasta una invocación de bash podían obtener la solución antes de tiempo.
Como otros han señalado, la mayor parte del peligro era para las personas que ejecutaban servicios de red expuestos en sus sistemas. (Sin embargo, no estoy seguro de si un servidor DCHP malintencionado podría haber explotado shellshock en OS X, lo que habría hecho que todos fueran vulnerables a una red maliciosa de cafeterías, etc.) Hubo parches que no son de Apple disponibles casi de inmediato, por ejemplo, instalando golpear a través de algo como macports y luego vincular a eso desde / bin / sh y / bin / bash. Por lo tanto, aquellos que ejecutan servicios vulnerables configurados de manera vulnerable podrían reemplazar a bash rápidamente.
Vale la pena señalar que cuando Apple actualizó agregaron una medida de seguridad adicional para restringir las funciones dentro de las variables de entorno a solo variables especialmente nombradas.
- ¿Cómo acelerarías el proceso de un ataque de diccionario?
- ¿Cuál es la mejor manera de lanzar un ataque DDos o DoS?
- Vulnerabilidad de Linux: cualquiera puede iniciar sesión tocando Retroceso 28 veces. ¿Cómo este método omite la contraseña?
- ¿Es seguro usar Samsung J2 sin un antivirus?
- ¿Cómo afectan los virus informáticos a los teclados?
Debemos recordar que el shellshock es un error en una característica de bash que simplemente no debería existir en primer lugar. (No sabía que existía la característica hasta que la leí.) Sabía que cosas como HTTP CGI establecerían variables de entorno de fuentes externas (y por lo tanto hostiles), pero eso también es terrible.
El error en bash no es el verdadero problema. El problema es una arquitectura de seguridad realmente terrible que permitiría que solo un error sea tan explotable. Hay muchas cosas que deben diseñarse incorrectamente para que el error bash sea peligroso. Hay muchas cosas que hemos diseñado incorrectamente en las últimas décadas.
Voy a citarme sobre esto en Shellshock es malo, las contraseñas únicas son buenas
- Los miembros de esta comunidad sabemos que no debemos pasar datos no confiables a varios otros procesos, sin embargo, hemos permitido que los sistemas que crean variables de entorno de shell (elementos diseñados para pasar por todas partes) provengan de las fuentes más no confiables de todos. [Por ejemplo, CGI, clientes DHCP, etc.].
- Nuestra comunidad sabe que engañar a los sistemas para que ejecuten “datos” es a menudo la forma en que ocurren los ataques, pero bash tiene una característica que permite deliberadamente ejecutar lo que normalmente se transmiten los datos.
- Ya sea que a los estudiantes de ciencias de la computación les guste o no, se les enseña que cuando los datos están en una clase particular de idiomas, es imposible validarlos, sin embargo, con bash hemos pegado un lenguaje Tipo 0 dentro de las variables.
- Los scripts y los programas deberían (en general) evitar invocar un shell como incluso la página de manual de Linux para el sistema (3) dice
No utilice
sistema
() de un programa con privilegios set-user-ID o set-group-ID, porque podrían usarse valores extraños para algunas variables de entorno para subvertir la integridad del sistema.
Sin embargo, llamar al sistema (3) es una práctica común porque es más fácil que invocar otros programas de la manera adecuada.
Cuando un sistema es víctima de Shellshock, es porque cada uno de esos principios y pautas ha sido ignorado. El primero está en el diseño de varios servicios de red (como servidores web). Los números dos y tres están en el diseño de bash, y el número cuatro aparece en innumerables guiones y programas. Ninguno de ellos trata sobre el error específico en bash. En cambio, del uno al tres se trata de características de diseño específicas de varios sistemas.
