On 2021-10-29 at 22:41 -0700, L A Walsh wrote: > > This is quite unfair. > Huh? It's true--look at how functions have to be stored in > the environment because someone was able to hack "their > own system" where they already have unrestricted shell access. > > If that isn't ugly or lame, what is? But it was the fault > of taking actions that a hacker could do on a system where > they already had shell access to corrupt their own environment.
No. The big issue was that web servers convert HTTP headers into environment variables when calling a CGI script (adding a HTTP_ prefix which didn't help here), but that allowing a *remote* user to set certain environment variables that lead to execution if the CGI itself was a shell script run under bash or bash got called from it. Two features were safe when taken separately, but turned out to be dangerous when combined. A bug that is only self-exploitable isn't really a security issue. > If permissions and paths were correctly set to never execute > files owned by that user, I don't see how that exploit > would gain root access and affect anyone other the user > who was injecting the code into their own function. That exploit didn't allow escalating to root (by itself). It would typically allow execution as a web user (www-data, apache…) or the owner of the CGI file. Escalation to root would need to be a separate step. Regards