[users@httpd] Hardening Apache against hijacking future requests

[Scott Gifford <sg...@suspectclass.com>]

Hello,

I'm helping to configure an Apache 1.3.x server (running on Debian
Linux) as securely as possible to protect data in a database from
unauthorized viewing (authorized viewing is done through a CGI
script).  I'm trying to ensure that even a bug in the CGI script or in
Apache which allows arbitrary code execution will not allow access to
any data outside of the current connection.

In addition to requiring all access to be password-authenticated over
an SSL connection with a client-side certificate, I've recommended
these steps to isolate a compromised Apache child or CGI script:

  * Database authentication credentials are entered by the client, and
    are sent in a cookie with each request, so they are not stored on
    the server (so a compromised Apache child or CGI script will have
    no access to any credentials besides the ones it received in the
    cookie).

  * Apache is run chroot to a directory with no write access allowed
    by the apache user, no setuid programs, no devices, no /proc, and
    the minimum necessary files; on a filesystem mounted readonly,
    nodev, and nosuid.  This prevents modifying the system in a way
    that could affect other sessions.  Apache drops to an unprivileged
    UID after the chroot, of course.

  * The minimum number of modules necessary are activated.

  * The grsecurity Linux kernel security patch is installed and
    configured, to reduce the risk of buffer overflows, breaking out
    of chroot, and intercepting other processes with strace/ptrace.

  * MaxRequestsPerChild is set to 1, so that a compromised Apache
    child cannot intercept data from a future connection.

However, I found that even with MaxRequestsPerChild set to 1, the
child process has access to the listen socket, and if it were
compromised it could request the next connection by doing an accept(2)
on the listen socket.

To prevent this type of attack, I have patched my copy of Apache so
that if MaxRequestsPerChild is set to 1, immediately after the
connection is accepted and before any user data is processed, the
child walks the ap_listeners linked list and close()'s any open
sockets (any listen_rec's with an nonzero fd member).  The intended
effect is that by the time any user data is processed, it is
impossible to hijack future sessions.

So, my questions are:

  * Does closing the listen sockets immediately after accept() if
    MaxRequestsPerChild is 1 seem like a basically sane and prudent
    thing to do?

  * Is anybody else interested in a patch that does this?  Should I
    clean it up and post it?

  * Anything other suggestions for hardening an Apache server against
    these sorts of attacks?

  * Any other ideas for sensitive items that an Apache child can drop
    its access to?  For example, can the SSL certificate be zeroed out
    in memory after a session key has been negotiated, so that a bug
    that occurs after that can't compromise the host certificate?

Thanks!

----ScottG.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org