I have recently seen a number of stuck processes on an Apache server I run. The problem is associated with events which appear to be attacks by the Slapper worm. The server's OpenSSL has been upgraded, so actual penetration by Slapper does not occur. However the stuck processes are inconvenient, and threaten DoS.
I have analysed the problem and discovered that incorrect manipulation of the handling of alarm signals by mod-perl is causing some Apache timeouts to fail. Software versions: Solaris 8 (SPARC 64 bit) Apache 1.3.26 perl 5.6.1 mod-perl 1.26 (source shows same problem in 1.27) mod-ssl 2.8.10 OpenSSL 0.9.6e The details of the problem are as follows: If the processing of a request to the server involves any perl handlers, mod-perl attempts to save and restore the Apache's handler for SIGALRM. The handler is saved at line 408 of perl_config.c and restored at line 1122 of mod_perl.c. (line numbers are from mod-perl version 1.26). The save/restore is done using the perl utility functions rsignal_state and rsignal. In perl 5.6.1, rsignal sets the SA_RESTART flag regardless of the saved state (util.c line 2509). The original SIGALRM state is set by Apache by a call of the libc function signal. This does leaves SA_RESTART clear. Thus, the first use of mod-perl in the life of an Apache child process changes the handling of SIGALRM. Thereafter, some, but not all, Apache timeouts fail to work. Two timeouts which I know to be affected by this are the timeout associated with the configuration directive KeepAliveTimeout, and that associated with the mod-ssl warning message "mod_ssl: SSL handshake timed out". Signal handling is greatly changed in perl 5.8. I believe that this problem will not occur with that version of perl unless it is compiled with PERL_OLD_SIGNALS. I think that it is the code in perl itself which is wrong. However, I also believe that the problem is serious enough to warrant a maintenance release of mod-perl which programs round the broken behaviour of rsignal in the perl versions which are actually in use at present. -- Charles Jardine - Computing Service, University of Cambridge [EMAIL PROTECTED] Tel: +44 1223 334506, Fax: +44 1223 334679
