Una explicación bastante acertada de como funciona el bashbug o shellshock que he leido de un usuario del otrolado.net:
La idea es que alguien malicioso, de alguna forma (hay varias formas, pero no entraré en eso ahora mismo porque no es relevante aún):
1) consiga modificar una "variable de entorno"
2) que dicha variable sea heredada por los procesos hijos (proceso hijo = cuando ejecutas un programa, tú a mano, o un script)
3) y que uno de esos procesos hijo sea el programa bash
Punto 1) Modificar una variable de entorno.
Si tienes ya acceso al equipo, hacer esto es trivial. Pero es que si tienes ya acceso al equipo... qué más quieres? Ya puedes intentar escalar privilegios con algun exploit del kernel, borrar todos los archivos del usuario actual, o lo que quieras.
Lo jugoso es conseguir modificar una variable de entorno sin tener ya acceso previo al equipo. Es decir, acceso remoto al equipo. Por eso todo el mundo habla de "remoto", porque ahí está el mayor peligro.
Punto 2) Conseguir que los procesos hijo hereden variables de entorno
Muchos programas almacenan información en variables de entorno, como método para comunicarse con procesos hijo.
Un ejemplo es los scripts CGI ejecutados con el servidor web apache: apache pone ciertos valores en variables de entorno, y el script cgi (y sus hijos) pueden leer dichas variables. Si un script CGI quiere saber qué navegador está usando el usuario que visita la web cgi, apache le pasa el User-Agent en una variable de entorno.
De esta forma, si yo modifico mi firefox para que el user-agent no sea "Mozilla blah blah", sino que ponga "() {:;}; date", ese churro de caracteres raro va a acabar en una variable de entorno del script CGI.
Se menciona mucho los CGI porque, por diseño, se utiliza variables de entorno para comunicarse entre apache y el cgi. Una web normal (web que no sea CGI) generalmente no las utiliza. CGI es una tecnologia obsoleta, pero es util y aún existen muchos CGIs por el mundo.
Aparte, no tiene por qué ser apache+cgi. Puede que existan otras formas de conseguir el punto 1) y 2), como un servidor DHCP (del atacante) que consigue modificar las variables de entorno del cliente DHCP (del ordenador atacado), etc.
Hay 4 o 5 posibles puntos de ataque similares (aparte de apache-cgi, y de dhclient), y seguramente se vayan descubriendo más con el tiempo.
Punto 3) Que uno de los hijos ejecute bash.
Primero, aclarar que lo único necesario es ejecutar bash. No es necesario que bash haga nada en particular: por el mero hecho de haber sido ejecutado, bash ejecutará el código de las variables de entorno.
Por tanto, aquí no se trata de que el hacker consiga modificar el equipo atacado, para que ejecute bash.
Más bien lo contrario: se trata de que el hacker busca a ver qué programa hace uso de bash durante su ejecución normal. Si está intentando usar CGIs, el hacker intentará localizar un CGI que haga uso de bash. Una forma fácil de localizar cgis válidos, es simplemente intentar realizar el ataque contra todos los cgis que existan. Con suerte alguno usará bash, y podrá liarla parda.
Si no tiene suerte, el equipo, aún teniendo una versión vulnerable de bash, será inatacable por esa vía. Tendra que ver si consigue hacerlo por otro método (en vez de cgis de apache, pues con dhclient, u openssh, o lo que sea)
Total, que si hemos localizado un programa que se apoye en bash para cualquier tarea, y le hemos podido tocar las variables de entorno al programa para que bash las herede al ser ejecutado, hemos completado el ataque: podemos ejecutar lo que queramos.
En esencia, es como si hemos conseguido sacar la contraseña de acceso del usuario que ejecuta ese programa.
Si apache tiene acceso a una base de datos, en ese momento nosotros tambien tenemos acceso a la base de datos, y podemos echarle un vistazo. O podemos borrar archivos del sistema al tuntún para tumbarlo. O lo que sea.
Fuente: www.elotrolado.net usuario: SteNyak