Bug 29964 - non-terminating i/o
non-terminating i/o
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl
All other
: P3 critical (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
Depends on:
  Show dependency tree
Reported: 2004-07-07 23:50 UTC by Francis Wai
Modified: 2004-11-16 19:05 UTC (History)
0 users

ssl_io_input_read fix (273 bytes, patch)
2004-07-08 11:04 UTC, Joe Orton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Francis Wai 2004-07-07 23:50:51 UTC
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!
Comment 1 Joe Orton 2004-07-08 11:04:23 UTC
Created attachment 12060 [details]
ssl_io_input_read fix
Comment 2 Joe Orton 2004-07-08 11:04:56 UTC
Thanks for the report and analysis.  Can you try the patch attached above?
Comment 3 Francis Wai 2004-07-08 19:30:44 UTC
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-
Comment 4 Joe Orton 2004-07-13 19:40:21 UTC
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.
Comment 5 Francis Wai 2004-07-13 19:45:18 UTC
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.
Comment 6 Joe Orton 2004-08-11 13:25:55 UTC
The fix checked in is slightly different:


this will be proposed for backport for the next 2.0 release.  This issue has
been assigned CVE CAN-2004-0748.