Re: How to do secure coding and create secure software

[Solar Designer <solar () openwall com>]

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