ServerBuddies Support Blog

What is suEXEC?

The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Presently, suEXEC does not allow ‘root’ to execute CGI/SSI programs.

Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer’s security. If you aren’t familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

Enabling & Disabling suEXEC

Upon startup of Apache, it looks for the file “suexec” in the “sbin” directory (default is “/usr/local/apache/sbin/suexec”). If Apache finds a properly configured suEXEC wrapper, it will print the following message to the error log:

If you don’t see this message at server startup, the server is most likely not finding the wrapper program where it expects it, or the executable is not installed setuid root.

If you want to enable the suEXEC mechanism for the first time and an Apache server is already running you must kill and restart Apache. Restarting it with a simple HUP or USR1 signal will not be enough.

If you want to disable suEXEC you should kill and restart Apache after you have removed the “suexec” file.

Server Side Includes

Server Side Includes (SSI) present a server administrator with several potential security risks.

There are ways to enhance the security of SSI files while still taking advantage of the benefits they provide.

To isolate the damage a wayward SSI file can cause, a server administrator can enable suexec.

Enabling SSI for files with .html or .htm extensions can be dangerous. This is especially true in a shared, or high traffic, server environment. SSI-enabled files should have a separate extension, such as the conventional .shtml. This helps keep server load at a minimum and allows for easier management of risk.

SSI files also pose the same risks that are associated with CGI scripts in general. Using the “exec cmd” element, SSI-enabled files can execute any CGI script or program under the permissions of the user and group Apache runs as, as configured in httpd.conf.

The first risk is the increased load on the server. All SSI-enabled files have to be parsed by Apache, whether or not there are any SSI directives included within the files. While this load increase is minor, in a shared server environment it can become significant.

The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Permissions on Apache ServerRoot Directories

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises.

For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

If you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected

PHP Security

PHP as a module or as a CGI

Using PHP as a module is suitable for systems that are dedicated to a single purpose or for sites run by trusted groups of administrators and developers. Using PHP as a CGI (possibly with an execution wrapper) is a better option when users cannot be fully trusted.

When PHP is installed as a module, it becomes a part of Apache and performs all operations as the Apache user (usually httpd).

Using PHP as a CGI

Compiling PHP as a CGI is similar to compiling it for the situation where you are going to use it as a module. This mode of operation is the default for PHP, so there is no need to specify an option on the configure line.

Migrating from a module to CGI operation, therefore, requires modifying every script.

register_globals and allow_url_fopen

register_globals. This option is off by default as of PHP 4.2.0

allow_url_fopen, allows programmers to treat URLs as files.

Because of security reasons, we turn off these options in the php.ini file:

PHP uses modules to extend its functionality dynamically. Unlike Apache, PHP can load modules programmatically using the dl( ) function from a script. When a dynamic module is loaded, it integrates into PHP and runs with its full permissions.

Use the expose_php configuration directive to tell PHP to keep quiet.

Setting this directive to Off will prevent the version number from reaching the Server response header and special URLs from being processed:

The PHP configuration directives disable_functions and disable_classes allow arbitrary functions and classes to be disabled.

The most useful security-related PHP directive is open_basedir. It tells PHP which files it can access.

Given that web server root, here is how open_basedir should be set:

When PHP is compiled with a –enable-memory-limit, it becomes possible to put a limit on the amount of memory a script consumes. Consider using this option to prevent badly written scripts from using too much memory. The limit is set via the memory_limit option in the configuration file:

You can limit the size of each POST request. Other request methods can have a body, and this option applies to all of them. You will need to increase this value from the default value specified below if you plan to allow large file uploads:

The max_input_time option limits the time a PHP script can spend processing input.

The max_execution_time option limits the time a PHP script spends running.

File uploads can be turned on and off using the file_uploads directive.

Safe mode (http://www.php.net/manual/en/features.safe-mode.php) is an attempt of\PHP developers to enhance security of PHP deployments. Once this mode is enabled, the PHP engine imposes a series of restrictions, making script execution more secure.

PHP safe mode is a useful tool. We start by turning on the safe mode:

Safe mode puts restrictions on external process execution. Only binaries in the safe directory can be executed from PHP scripts:

The following functions are affected:

• exec( )
• system( )
• passthru( )
• popen( )

Some methods of program execution do not work in safe mode:

shell_exec( ) Disabled in safe mode.
backtick operator Disabled in safe mode.
dl( ) Disabled in safe mode.

Hardened-PHP (http://www.hardened-php.net) is a project that has a goal of remedying some of the shortcomings present in the mainstream PHP distribution.

Reference - http://www.php.net