...

Mitigation: run as few services on the machine besides httpd as possible.  Be alert to publically known httpd vulnerabilities and patch them as quickly as possible.

 It may be possible to use SELinux to minimize the potential impact of an httpd or other service exploit.  More research is required.

 2. Web application exploits

...

Private static content (anything protected by a .htaccess file) must be readable by the apache user if httpd is going to be able to serve it normally.  This means making those files world-readable, which is an issue if it allows other users to read the content without going through httpd access controls.  If all users are placed within the same group, the files can be protected against other users by making them not group-readable--assuming users have no ability to read the content from the apache account using dynamic content features (see below).  Again, it may be necessary to protect users against themselves.

RecommendationsMitigation measures:

• Place all users in  the same group.
• Set the default homedir mode to 701 and the default public_html subdir mode to 705.
• Set the default umask to 073072.
• Run a system-scanning process which masks all user file permissions with ~073 ~072 (removing all group permissions and all world-write permissions except reading) unless the user opts out by placing a magic flag file in the top level of the home directory.
• Do not allow users to execute dynamic content using the apache uid.

...

It is traditional in web hosting services to execute dynamic content as the apache account, possibly within the httpd worker process itself.  This practice is grossly insecure; although the apache account may be unable to modify any system files, all user dynamic content becomes undifferentiated in terms of what actions it can take.  If my dynamic content can read my database password from a file in my home directory, your dynamic content can do the same.  The commercial Some web hosting provider I evaluated provided providers give the option of executing dynamic content as your own uid (using something like cgiwrap) so that you could protect files from other users, but none of the any cookie-cutter installation scripts they provided made use of this feature.provide generally do not set up this feature.

Our architecture will be to evalute all dynamic content as the uid of the content owner, not as the httpd account.  There are a variety of technologies to do this with; so far the best option appears to be a combination of the built-in Apache httpd suexec mechanism and FastCGI.  In the future, httpd 2.x may provide more comprehensive support for this architecture, allowing httpd worker processes to adopt the uid of the content owner and then process content through standard mechanisms such as mod_php.  Idle worker processes could be reused if they match the target uid of a new request, eliminating the need for FastCGI.

3c. Cookie theft

(Unfinished) 

3d. HTTP Basic auth password theft

Basic auth is a rudimentary password protection system built into HTTP.  Most web applications do their own password management, but static content is sometimes protected with Basic auth.  Once a user enters a password for a given resource, the browser caches the password, so that the user does not have to reenter it each time the resource is accessed.

A Basic auth resource is identified by the domain part of the URL and a server-provided realm.  In a shared hosting environment, the normal Apache httpd mechanisms for doing Basic auth allow each content owner to pick the realm used for each resource.  An attacker can steal passwords from users of another content owner's resource by choosing the same realm name as the other content owner.

 Mitigation options include:

• Deny users the ability to use Basic auth; make them use Digest auth instead.  Digest auth does not provide the server with the user's password.
• Allow users to use Basic auth, but force the realm to include the username as a prefix.

More research is required to determine which of these options is most feasible.  Note that disabling or restricting the normal Apache auth mechanisms may not be sufficient; it may be possible to circumvent them with CGI scripts.

4. Local root vulnerabilities

A local root vulnerability could allow a regular user to take control of the entire hosting service, or could allow an attacker who has taken control of a user account (or the apache account) to take control of the entire service.  Addressing a compromise of this sort would require disrupting the web hosting service, possibly for an extended period of time, while the server is reinstalled and user content is restored from backup.

It may be possible to use SELinux to reduce the likelihood of a local root privilege escalation.<incomplete>