Full_Name: Jarod Jenson Version: Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.6 OS: Solaris 8 Submission from: (NULL) (192.152.140.9) Using a SYSV semaphore to protect a shared memory instance of the SSL session cache, can leave the semaphore in a inconsistent state creating the possibility of a DoS (or at least a corrupted SSL session cache). In this case ssl_mutex_on() basically calls through ssl_mutex_sem_acquire() resulting in a semop() to manipulate the state of the semaphore (avail/unavail). semop() is an interruptible system call (SIGPIPE for instance). If this happens, it is possible that the semaphore read/acquisition fails. This returns back into ssl_mutex_on() which returns (with no value) to the caller. The caller proceeds to read/modify the SSL session cache and then calls ssl_mutex_off() while in fact that may not "hold" the semaphore. If this happens at the correct time, then an incorrect call is made to decrement the semaphore and if I understand the Solaris implementation correctly, this will result in the next call to semop(), with a decrement, to cv_wait_sig() until someone increments the semaphore. This is the semi DoS (it will at least slow the SSL portion of the server down tremendously). While my analysis may not be perfect (I looked at the code for the first time today), it is fairly easy to reproduce this by having a client immediately close the connection after SSL negotiation and then the server performance drops dramatically. (You will see the "Failed to acquire ...." messages logged). It appears that one should retry the semaphore operation if it fails as well as having a return status from ssl_mutex_[on|off] so you can decide what to do with the connection should it fail. -Jarod ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
