Shellshock: Qué es, qué pasó, qué se puede hacer

Nunca es agradable reportar incidentes de esta clase, porque nos recuerdan qué tan inseguro puede ser un sistema más allá de las apariencias. Después de lo que fueron Heartbleed y otras vulnerabilidades de alto nivel, aparece Shellshock, un conjunto de bugs que afecta al mismísimo shell Bash, presente en plataformas Unix y múltiples sabores de Linux. La mayoría de los usuarios ya deberían estar protegidos, pero los servidores web y los sistemas integrados demandan otro tipo de atención…

Es probable que en los últimos días, la mayoría de los usuarios en la Web hayan sido expuestos a la noticia de un bug-problema-vulnerabilidad en Bash, y muchos de esos usuarios se estén preguntando qué es Bash exactamente. El término oficial para describir a Bash (Bourne-Again SHell) no es otro que el de intérprete de comandos. Es análogo al viejo command.com del MS-DOS, aunque Bash es mucho más avanzado, y acumula un tiempo de desarrollo más amplio. Bash ha estado entre nosotros durante los últimos 25 años, y su adopción está prácticamente fuera de toda discusión. Esto es en verdad lo que hace a Shellshock tan serio. Es posible encontrar a Bash en todas partes, y que alguien descubra varios agujeros de seguridad en él, automáticamente se transforma en un problema.

Una de las partes más complicadas de comunicar los efectos de Shellshock es, sin lugar a dudas, explicar el bug original. Stéphane Chazelas lo reportó el pasado 12 de septiembre, y se mantuvo bajo embargo durante doce días para dar tiempo a la creación de un parche. El bug se concentra sobre la manera en la que Bash interpreta variables. En una situación normal, las variables que el usuario configura son siempre “leídas” como texto plano y nada más, pero si se inserta una serie de caracteres al comienzo de la variable (específicamente “() { :;};”), Bash pasa a interpretar la variable como comando. Si a esto sumamos el hecho de que Bash es usado por muchos programas como intermediario para comunicarse entre sí y/o ejecutar scripts, si uno de esos programas invoca a Bash de forma poco segura, la temida “ejecución remota de código” se vuelve una posibilidad.

Apenas se iniciaron los trabajos para corregir a Shellshock, varios administradores descubrieron bugs adicionales en Bash, también asociados a la interpretación de variables. Como era de esperarse, si los administradores vuelan, los desarrolladores de malware van en cohete, y las compañías de seguridad están reportando la presencia de botnets que buscan servidores afectados. ¿Qué puede hacer el usuario final? En este caso, esperar que llegue el parche. Para variar, Shellshock no toca a las plataformas Windows, por lo que no deberíamos recibir ninguna clase de actualización de emergencia vía Windows Update. Las distros mayores de Linux ya distribuyeron sus parches, y lo mismo se extiende a Apple con OS X. El gran inconveniente lo presentan aquellos sistemas integrados con actualizaciones menos frecuentes, y los servidores web que necesitan atención directa. ¿Lo más triste? Aparentemente, ese bug ha estado en Bash desde el principio.