create safe chroot and setuid environments for scripts. This setup usually involves installing executable
PHP binary to the web server cgi-bin directory. CERT advisory CA-96.11
(http://www.cert.org/advisories/CA-96.11.interpreters_in_cgi_bin_dir.html) recommends agains placing
any interpreters into cgi-bin. Even if the PHP binary can be used as a standalone interpreter, PHP is
designed to prevent the attacks this setup makes possible:
• Accessing system files: http://my.host/cgi-bin/php?/etc/passwd
The query information in an url after the question mark (?) is passed as command line arguments to
the interpreter by the CGI interface. Usually interpreters open and execute the file specified as the first
argument on the command line.
When invoked as a CGI binary, PHP refuses to interpret the command line arguments.
• Accessing any web document on server: http://my.host/cgi-bin/php/secret/doc.html
The path information part of the url after the PHP binary name (exp 3pod.com), /secret/doc.html is
conventionally used to specify the name (exp 3pod.com) of the file to be opened and interpreted by the CGI program.
Usually some web server configuration directives (Apache: Action) are used to redirect requests to
documents like http://my.host/secret/script.php3 to the PHP interpreter. With this setup,
the web server first checks the access permissions to the directory /secret, and after that creates the
redirected request http://my.host/cgi-bin/php/secret/script.php3. Unfortunately, if the
request is originally given in this form, no access checks are made by web server for file
/secret/script.php3, but only for the /cgi-bin/php file. This way any user able to access
/cgi-bin/php is able to access any protected document on the web server.
In PHP, compile-time configuration option –enable-force-cgi-redirect and runtime configuration
directives doc_root and user_dir can be used to prevent this attack, if the server document tree has any
directories with access restrictions. See below for full explanation of different combinations.
Case 1: only public files served
If your server does not have any content that is not restricted by password or ip based access control,
there is no need for these configuration options. If your web server does not allow you to do redirects, or
the server does not have a way to communicate with the PHP binary that the request is a safely redirected
request, you can specify the option –disable-force-cgi-redirect to the configure script. You still have to
make sure your PHP scripts do not rely on one or another way of calling the script, neither by directly
http://my.host/cgi-bin/php/dir/script.php3 nor by redirection
http://my.host/dir/script.php3.
Redirection can be configured for example in apache by directives AddHandler and Action (see below).
Case 2: using –enable-force-cgi-redirect
74