Dado que este error afecta a tantas plataformas, podríamos aprender algo del proceso mediante el cual se encontró esta vulnerabilidad: ¿fue un momento εὕρηκα (eureka) o el resultado de un control de seguridad?
Como sabemos que Stéphane encontró el error Shellshock, y es posible que otros también conozcan el proceso, nos interesaría la historia de cómo llegó a encontrar el error.
Respuesta1
Para tranquilizar a algunos, no encontré el error al observar los exploits, no tengo motivos para creer que haya sido explotado antes de ser revelado (aunque, por supuesto, no puedo descartarlo). Tampoco lo encontré mirando el bashcódigo de.
No puedo decir que recuerde exactamente lo que pensaba en ese momento.
Eso más o menos surgió de alguna reflexión sobre algunos comportamientos de algún software que encuentropeligroso(los comportamientos, no el software). El tipo de comportamiento que te hace pensar:eso no parece una buena idea.
En este caso, estaba reflexionando sobre la configuración común de ssh que permite pasar variables de entorno no saneadas por el cliente siempre que su nombre comience con LC_. La idea es que las personas puedan seguir usando su propio lenguaje cuando sshaccedan a otras máquinas. Una buena idea hasta que empieces a considerar lo complejo que es el manejo de la localización, especialmente cuando se incluye UTF-8 en la ecuación (y viendo lo mal que lo manejan muchas aplicaciones).
En julio de 2014, ya había informado de una vulnerabilidad en el manejo de localización de glibc que se combinaba con esa sshd
configuración, yotros doscomportamientos peligrososde la bashconcha
permitió a atacantes (autenticados) piratear servidores git siempre que pudieran cargar archivos allí y bashse utilizara como shell de inicio de sesión del usuario git unix (CVE-2014-0475).
Estaba pensando que probablemente era una mala idea usarlo bashcomo shell de inicio de sesión para los usuarios que ofrecen servicios a través de ssh, dado que es un shell bastante complejo (cuando todo lo que necesitas es analizar una línea de comando muy simple) y ha heredado la mayoría de los errores de diseño. de ksh. Como ya había identificado algunos problemas con bashel uso en ese contexto (para interpretar ssh ForceCommands), me preguntaba si potencialmente habría más allí.
AcceptEnv LC_*permite cualquier variable cuyo nombre comience con LC_y tuve el vago recuerdo de quebash funciones exportadas(apeligrosoaunque en ese momento era una característica útil) estaban usando variables de entorno cuyo nombre era algo así como
myfunction()y me preguntaba si no había algo interesante que ver allí.
Estaba a punto de descartarlo porque lo peor que se podría hacer sería redefinir un comando llamado, LC_something
lo que realmente no podría ser un problema ya que esos no son nombres de comandos existentes, pero luego comencé a preguntarme cómobash
importadoesas variables de entorno.
¿Qué pasaría si las variables se llamaran, LC_foo;echo test; f()por ejemplo? Entonces decidí echar un vistazo más de cerca.
A:
$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() { :
}
reveló que mi recuerdo estaba equivocado en que las variables no fueron llamadas myfunction()sino myfunction(y es el
valorque comienza con ()).
Y una prueba rápida:
$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'
confirmó mi sospecha de que el nombre de la variable no fue desinfectado y el código fue evaluadoal inicio.
Peor, mucho peor, elvalortampoco fue desinfectado:
$ env 'foo=() { :;}; echo test' bash -c :
test
Eso significaba quecualquierLa variable de entorno podría ser un vector.
Fue entonces cuando me di cuenta del alcance del problema, confirmé que también era explotable a través de HTTP ( HTTP_xxx/ QUERYSTRING... env vars), otros como servicios de procesamiento de correo, más tarde DHCP (y probablemente una larga lista) y lo informé (cuidadosamente) .