I'm seeing a non-terminating loop in ssl_io_input_getline(). We used a 3rd party tool to send a request to our Apache server. The tool tried to present an expired certificate to a SSL enabled vhost and Apache correctly refused the correction. But, it set Apache to spin out of control. I'm a complete outsider of the Apache/mod_ssl code. But this is what I found. As mentioned, Apache did shutdown the filter's SSL connection. However, it continued to read in GETLINE/blocking mode the rest of the request. Here comes the problem. ssl_io_input_getline() calls ssl_io_input_read() to read to a LF or the max. of the buffer can handle, whichever comes first. But, ssl_io_input_read() realizes the filter's SSL connection has been shutdown, it returns with the last known status of the BIO which was created to read from this SSL connection. It also set the returned length to 0. Unfortunately, the caller get APR_SUCCESS return code and because the returned length is 0, the remaining buffer length does not get changed at all. Because the return code is always APR_SUCCESS and because the returned length is always 0 and the buffer is not full, ssl_io_input_getline() keeps calling ssl_io_input_read(). It goes on forever!
Created attachment 12060 [details] ssl_io_input_read fix
Thanks for the report and analysis. Can you try the patch attached above?
Thanks for the quick response. We thought about this before I submitted the bug report. We thought APR_EOF or APR_EGENERAL or in fact any return code other than APR_SUCCESS would have been sufficient to prevent Apache from spinning out of control. We could not decide on either, however. We are not super familiar with the Apache/mod_ssl code and, more important, this is the most exercised part of the server as far as we're concerned. It is important that the return code does what it is supposed to do _and_ does not cause any un-expected side- effect.
APR_ECONNRESET, APR_EGENERAL or APR_EOF would all be reasonable choices. Doing any of these would clearly be better than the status quo; opt for APR_EGENERAL to be conservative. I couldn't reproduce the issue here from in brief attempt, so if you could confirm that the patch does fix the issue that would be helpful.
We patched Apache as suggested and it does fix the problem. We're in the process of conducting more thorough tests and if anything unexpected crops up, I'll report here. Thanks for the response.
The fix checked in is slightly different: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/ssl/ssl_engine_io.c?r1=1.124&r2=1.125 this will be proposed for backport for the next 2.0 release. This issue has been assigned CVE CAN-2004-0748.