A correction: On Tue, Sep 30, 2025 at 07:23:52AM +0200, Solar Designer wrote: > A malicious HTTP client connects to the HTTP server and requests an URL > corresponding to the CGI script. It uses the PUT method. It passes a > header named GET_SHELL_FUNCTION with a value that defines a shell > function body, which ends up injected and executed.
This should be PUT_SHELL_FUNCTION in place of GET_SHELL_FUNCTION. On Tue, Sep 30, 2025 at 01:02:01AM -0500, Jacob Bachmeyer wrote: > On 9/30/25 00:23, Solar Designer wrote: > >[...] > >So is the vulnerability in the shell, like Shellshock was determined to > >be? [...] the shell maintainers may well dispute this CVE on > >such grounds as well as because the shell worked exactly as documented. > >[...] > > Small nit here: Shellshock was clearly a vulnerability in Bash and I am > unsure if the way Bash exports shell functions was documented at all. I agree, which is why I invented a different and documented alternative for the sake of this example. > If presented with an environment variable value having the correct form > for a shell function, but containing more text than the body of the > function, Bash would immediately execute the trailing text as commands > while importing the shell function from the environment. That was > Shellshock. Yes, there were multiple Shellshock-related code issues in bash, and several CVEs were rightly assigned against bash. No arguing about that. Also, the proper Shellshock was exposed as a vulnerability by far not only through HTTP servers, since it parsed variables of any names. My point is that a similar documented and correctly implemented feature could also become a vulnerability in some interactions. Now let's be winding this thread down, please. Alexander
