...

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

...

and cookie injection

A well-behaved web application will send cookies to clients containing a proper path value, so that the cookies are only sent back to the same web application which generated them.  Many web applications, however, set a cookie path of "/", which will cause the cookies to be transmitted to any other application in the same domain.  A malicious application merely has to inspect the cookies received from a client in order to steal any privileged information contained within.

In a similar vein, a well-behaved web application will check that all received cookies contain the expected domain and path values, but some applications do not check.  If an application does not check, it is easy for a malicious application in the same domain to inject a cookie containing a value controlled by the attacker.

There is no systemic mitigation for these risks other than encouraging the use of virtual domains.  They should be treated as application security issues.  Note that cookie injection is not a problem unique to applications running within the same domain; any attacker controlling content on a foo.mit.edu host can inject cookies into all .mit.edu hosts if the victim applications do not check cookie domains.

(Unfinished) 

3d. HTTP Basic auth password theft

...

• 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.
• Allow Basic auth, but only in the context of a virtual domain.

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.

3e. PHP session hijacking

We should be sure to arrange for each user to use a separate PHP session directory, probably in a mode-700 subdir of the user's homedir, to avoid the possibility of users hijacking one another's sessions.

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 Recovering from 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.

 Mitigation options:

• Audit the system for setuid programs and remove any unnecessary packages containing them.  Turn off the setuid bit on the remaining setuid programs which don't need to be setuid.
• Keep the system up to date.
• Treat kernel security updates as high-priority updates; schedule a reboot to install kernel updates on the evening of the upstream kernel package release at the latest.

It may be possible to use SELinux to reduce the likelihood of a local root privilege escalation.  More research is required.