Actualiza bash, y este problema específico desaparece.
Pero si desea saber si era vulnerable antes de esto, habrá rutas específicas de la aplicación para agregar a las vulnerabilidades genéricas (hasta que se haga un parche en el bash; es posible que luego se descubran nuevas vulnerabilidades que no sean de bash con el mismo patrón).
El problema específico está en permitir variables de entorno controladas por el atacante . Si el atacante puede obtener de forma remota una variable de entorno establecida en una definición de función seguida de un comando inmediato; el atacante podría esperar a que algún comando totalmente no relacionado se ejecute por bash. No importa qué programa bash sea, o si los argumentos se validaron (o están codificados, etc.).
Específicamente, bash tiene un punto de entrada principal como cualquier otro programa, y tiene esta firma:
int main(int argc, char** argv, char** arge); //bash's main entry point
Esta función principal se invoca como un detalle interno de invocar un exec. Si arge no se limpió de antemano, el principal de bash hará debidamente lo que se supone que debe hacer el shell bash. Una de esas cosas es analizar el entorno.
Todos tenemos el hábito de limpiar argc y argv para la limpieza. Pero la mayoría de la gente ignora totalmente lo que está en juego. Entonces, si un socket remoto ordenó a un proceso que estableciera una variable de entorno (es decir, HTTP_COOOKIE), entonces alguna entrada de arge tiene ese valor. Digamos que arge [42] tiene un valor:
HTTP_COOKIE=() { :; }; /usr/bin/eject
Luego, bash main ve que el valor de la cadena tiene los paréntesis de apertura / cierre, y adivina que esta debe ser una definición de función. Por lo tanto, define correctamente HTTP_COOKIE como una función, y también ejecuta el comando inmediato después de ello.
Entonces, si el entorno tiene esta variable, nada malo ha sucedido todavía. Pero fácilmente podrías estar llamando código Python inocuo que obviamente no está ejecutando bash. Esto es todo lo que ves:
Licensing().check()
Tal vez haya un binario que usa su empresa que verifique una licencia, y usted llame a esta función (no sabe lo que hace). Pero digamos que, en última instancia, lo que hace es esto (resuelto en la implementación de C):
//There are no arguments to this program so this is "safe"
execl("/bin/bash", "bash", "-c", "licensingWrapper", (char*)0);
Entonces comienza bash ...
//This is bash's main function
int main(int argc, char** argv, char** arge) {
....
parseEnvironment(arge); //!!!!
....
}
Luego, en parseEnvironment, en arge [42] ve una variable llamada 'HTTP_COOKIE' y la analiza. bash no tiene la menor idea de para qué es esta variable, pero ve que es una definición de función con algún comando ejecutado de inmediato; y simplemente lo hace. Este análisis de entorno es solo un requisito previo estándar para que el shell esté listo para ejecutar cualquier argumento que diga ejecutar.
Si piensa en esto un poco más profundo, es solo otro caso de no limpiar la entrada. Nadie limpia la entrada del medio ambiente. Para empeorar las cosas, las variables de entorno se interpretan de manera diferente según lo que se están transmitiendo a (bash, sh, java, ...). Por lo tanto, si tuviera una función genérica para limpiar el entorno, sería específica para los tipos de ejecutivos que espera ejecutar más adelante.
int main(int argc, char** argv, char** arge) {
BOOL isClean = TRUE;
isClean &= cleanseEnvironment(arge, BASIC_SANITY);
isClean &= cleanseEnvironment(arge, BASH_RULES);
if(isClean) {
parseEnvironment(arge);
}
else {
return -EBADENVIRONMENT;
}
...
}
Por lo tanto, sería muy sospechoso de que las variables de entorno se configuren en valores contaminados por el atacante. Luego, simplemente asuma que algún shell que no había pensado se ejecutará en ese entorno más adelante. Tienes un problema obvio si puedes demostrar que finalmente se ejecuta bash. Pero podría ser fácilmente una ruta indirecta, como tcl que se está ejecutando, luego tcl hace que se invoque a bash.