Cuando se presentó Shellshock, ¿qué tan malo fue ** entonces **?

¿Qué tan mal? No muy.

Cuando se introdujo el error, no existía ninguno de los vectores de ataque remoto comunes: el error de análisis "shellshock" es anterior a CGI y DHCP alrededor de un año, y es anterior a SSH entre dos y tres años. Los programas de acceso remoto como telnet y rsh no tienen la capacidad de restricción de comandos que SSH tiene, por lo que aunque un ataque "shell shock" probablemente se pueda montar contra ellos, no ganaría un atacante nada que no pudieran " t simplemente iniciando sesión normalmente.

En cuanto a los ataques locales de escalada de privilegios, por lo que puedo decir, Linux nunca ha soportado los scripts de setuid. No hay muchos programas setuid: en ese momento, habrían sido lo que ahora son los paquetes "util-linux" y "shadow". Estos programas forman parte de la especificación POSIX y no han cambiado en su funcionamiento fundamental en los últimos 20 años. De ellos, solo su , mount y umount son setuid y llaman a otros programas, y todos ellos lo hacen a través de exec*() . su pasó y aún pasa el entorno si se invoca sin - , pero no es un vector de ataque fácil de usar: necesita que su objetivo lo ejecute con un entorno bajo su control, y lo invoque como su - (que limpia el entorno) es una segunda naturaleza para muchos administradores de sistemas.

El gran comodín es otro de los sistemas similares a * nix. El territorio de usuario de GNU fue un reemplazo popular para los programas de proveedores de baja calidad, y algunos de los sistemas operativos similares a * nix soportaron scripts de setuid.