sanitize %ENV

[rurban]

See e.g. for a nice remote CGI exploit via
LD_PRELOAD: https://www.elttam.com.au/blog/goahead/

The env_sanitizer should probably go into a helper function.
That's up to you to decide where to.

I also haven't checked what Apache how does its ENV sanitizing.
I just hope it does.

[miyagawa]

The link you posted seems to describe a vulnerability in a particular web server implementation, and the existence of that CVE doesn't mean all CGI script implementation need to be patched. As you wrote, if Apache does not sanitize the external inputs and allows an attacker to change LD_PRELOAD, that's a vulnerability in Apache that needs to be fixed there.

That said it doesn't stop you from protecting from such a vulnerability in the CGI implementation side, and from hereon I assume that's your intent here.

For Plack::Handler::CGI, your patch deletes HTTP_AUTHORIZATION and REMOTE_HOST etc. which I do believe will break the existing applications which implements HTTP basic authentication.

I do not mind strongly about deleting LD_* environment names for precautions, but it could also break a valid use case where you host your CGI script with a pinned LD_PRELOAD environment variable to run, say, mysql client from a specific LD path.

For Plack::App::WrapCGI, it seems a bit more relevant since it is on the CGI executor side. However the patch again seems to have the same issue about the deletion of REMOTE_HOST and HTTP_AUTHORIZATION, and deletion of other variables could also break if it's explicitly set in the parent runner environment.

I think what we should look at instead is CGI::Emulate::PSGI to see if there's a possibility of turning user-supplied headers or parameters into an environment variable outside those prefixed with HTTP_.

I'm not convinced if this patch is necessary, or at least would break existing applications if applied without any optional behaviors to keep the current variables.