Security warning: Please don't use any version older than 1.11!

gzip_cnc Cache Conditional requests Program logic Program Status Codes Logging Effect Installation Security Project Table of contents Download

Security aspects when using gzip_cnc

The CGI interface for an Apache handler

As you can find in the description of the program logic gzip_cnc mainly evaluates the content of two Environment variables

• PATH_INFO (the URL path of the requested file) and
• PATH_TRANSLATED (the file name of the requested file after translations by Apache mechanisms).

Both are filled with corresponding values by the Apache server when a CGI application being embedded via the Addhandler Apache directive has been invoked.

Before this, the actual access to the requested file is subject to the normal security concepts of the Apache servers. Two examples for this may be named here:

• explicit access control by the concepts of the Apache modules mod_access rsp. mod_auth
• implicit access control by the Apache directive ScriptAlias (the content of a CGI directory specified this way will always be treated as CGI application and not served to the client)

Only after these tests gzip_cnc will be invoked as handler and is now accessing the content of the requested file directly, without furter checks. Being only a CGI script, it doesn't know the complete Apache configuration - so it has to trust the Apache server to already have done its job in this respect.

And if there were not other possibility to provide the corresponding information to gzip_cnc this would suffice ...

The problem with gzip_cnc 1.10 and earlier versions

... but unfortunately there is such a possibility. A CGI script being embedded via AddHandler is still a CGI script.

And if you invoke a CGI script and append the path of another file residing on this server to the URL - not as query string, but directly as path name as if the CGI script were a directory! - then the Apache server reacts almost as if this other file had been requested and the CGI script had been defined as a handler for it. The requests for

• /index.html via the defined handler /cgi-bin/gzip_cnc.pl and
• /cgi-bin/gzip_cnc.pl/index.html (!)

look absolutely identical in all aspects covered until now, from gzip_cnc.pl's point of view.

Actually der Apache web server internally implements this handler embedding by some redirection to exactly this URL, as you can verify yourself: If such a handler causes an error the URL composed this way will be displayed in the browser together with the error message.

But there is a decisive difference between both requests:

• In the first case the Apache web server checks the user's entitlement to access the URL /index.html,
• but in the second case it checks the entitlement to access the URL /cgi-bin/gzip_cnc.pl!

By this gzip_cnc until version 1.10 inadvertantly created a tunnel through each and every existing security mechanism of the Apache web server, because the server didn't recognize that the visitor is actually going to access a different file. The CGI script for its part didn't recognize that previous to its invocation no access control for the actually requested file has taken place. Each of tehse two relies upon the other one.

And the result is disastrous: If some attacker has outguessed the URL of some installed gzip_cnc.pl script then he can read every file within the URL space.

Detecting a direct access by gzip_cnc

But how can gzip_cnc identify any difference between two almost identical requests? The Apache documentation doesn't seem to provide any trustworthy method for this.

My own experiments with Apache 1.3.x versions have shown that the value of the Environment variable REDIRECT_URL seems to be set differently in these two cases:

• For any implicit access via the handler this variable contains the same URL as PATH_INFO,
• for any explicit access to the CGI script it contains the CGI script's URL.

Where the fact that even the directe Access to the CGI script causes some value for this REDIRECT_URL variable seems to mean that the truncation of the 'surplus' part of the URL is implemented by the Apache server using some internal forwarding as well.

Although this is no officially documented information, I have additionally implemented the test described here in gzip_cnc 1.11. gzip_cnc compares the value of the two Environment variables PATH_INFO and REDIRECT_URL and rejects the request with the HTTP status 403 and a short error message if they aren't identical.

During tests with two Apache versions (1.3.12 and 1.3.26) this modification provided the desired differentiation - but I explicitly want to make clear that I cannot make generally accepted statements for every Apache version.

Doublechecking gzip_cnc's the access check by the user

Therefore each gzip_cnc user should absolutely doublecheck whether the test has the desired effect for his installation. Most suitably for this seems to be the attempt to read the content of some installed CGI script (as exactly this should normally be prevented by the Apache server) - for example, the source code of gzip_cnc itself, by requesting some URL of the type /cgi-bin/gzip_cnc.pl/cgi-bin/gzip_cnc.pl.

If in this case even gzip_cnc 1.11 would display its own content then I strongly suggest not to use gzip_cnc for your web space. But even for the case of this doublecheck being successful I want to make clear out that using software from a foreign source is always done at your own risk ...

(Michael Schröpl, 2002-09-08)