Bug 67798 - imap_open() causes apache to segfault sig (11)
imap_open() causes apache to segfault sig (11)
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-02 01:50 EDT by Scott Russell
Modified: 2007-04-18 12:43 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-07 10:40:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott Russell 2002-07-02 01:50:04 EDT
This bug has been opened at bugs.php.net as well, REF #18104. This may however
be a specific Red Hat issue so I'm opening this here as well. 

This is NOT A DUPLICATE issue of Red Hat bug 65190. This segfault can be
replicated easily with or without imaps running.

Description:
------------

  With php 4.2.1 or 4.1.2-7 RPM and c-client 2001a or current c-client devel
snap shot I cannot use any imap_open() calls to cyrus 2.1.5. Attempted
imap_open() calls result in an error being logged by apache in
error_log:

[notice] child pid 27897 exit signal Segmentation fault (11)
[notice] child pid 27902 exit signal Segmentation fault (11)
[notice] child pid 27901 exit signal Segmentation fault (11)

followed by a 'Page contains no data' error in the browser.

Environment:
------------

  Red Hat 7.3
  php-4.2.1 compiled from src
  imap-2002.DEV.SNAP-0206241612 (c-client) compiled from src
  cyrus-sasl-2.1.5 compiled from src
  cyrus-imapd-2.1.5 compiled from src

Also Tried:
-----------

  php-4.1.2-7 RPMS from Red Hat 7.3
  imap-devel 2001a (c-client) RPM from Red Hat 7.3

Config:
-------

  I have RH 7.3 with Cyrus IMAP and Cyrus-SASL compiled from source and
installed fine. IMAP clients, Mozilla, Evo, fetchmail, etc, have no
problems connecting to my imapd via imap or imaps. I am using a self
signed cert but have tested with imaps and cyrus tls_cert_* options
disabled. (ie: I've tested without cyrus master loading any type of
imapd -s processes which enable SSL/TLS support.)

Test Case and Results
----------------------

  I have the following test.php script running with php 4.2.1/4.1.1 and
c-client 2002 DEV SNAP / imap-devel 2001a on the same Red Hat 7.3 server with
Cyrus IMAPd 2.1.5 installed:

<pre>
<?php
$ref = imap_open("{localhost:143}", "lnxgeek", "passwd", "OP_HALFOPEN")
  or die ("Failed imap_open with: ".imap_last_error());
print "imap connection opened!";
imap_close($ref);
?>
</pre>

I have also tried the following $server parms for imap_open(). The
results of each test are listed in [].

{localhost:143} [self cert err]
{localhost:143/imap} [self cert err]
{localhost:143/imap/notls} [segfalt sig 11]
{localhost:143/imap/novalidate-cert} [segfault sig 11]
{localhost:143/imap/notls/novalidate-cert} [segfault sig 11]
{localhost:993} [no connect]
{localhost:993/imap} [no connect]
{localhost:993/imap/ssl} [self cert error]
{localhost:993/imap/ssl/novalidate-cert} [segfault sig 11]
{localhost:993/imap/tls/novalidate-cert} [no connect]

The imtest client provided with cyrus has no problems connecting via
imap or imaps using DIGEST, CRAM, or PLAIN passwords.

Additional Trouble Shooting
----------------------------

  With the cyrus imapd running imap and imaps on the host
'ogg.raleigh.ibm.com', I attempted the same test script from a stock Red
Hat 7.3 install on another system (bzimage). By default Red Hat 7.3 uses
imap-devel 2001a (c-client) and php-4.1.2-7. Repeating the same tests as above
on the bzimage system but using ogg.raleigh.ibm.com instead of localhost as the
server name resulted in the same errors shown.

Checking the logs of my cyrus server I can see that all connections were
always accepted but no authentication appears to be attempted. For example I
will typically see:

Jul  2 00:33:11 ogg imapd[28137]: mydelete: starting txn 2147483718
Jul  2 00:33:11 ogg imapd[28137]: mydelete: committing txn 2147483718
Jul  2 00:33:11 ogg imapd[28137]: mystore: starting txn 2147483719
Jul  2 00:33:11 ogg imapd[28137]: mystore: committing txn 2147483719
Jul  2 00:33:11 ogg imapd[28137]: starttls: TLSv1 with cipher
DES-CBC3-SHA (168/168 bits new) no authentication

This shows a good connection has been made but at this point the apache
child segfaults. Eventually the cyrus imapd session times out and
closes.
Comment 1 Scott Russell 2002-07-02 15:13:51 EDT
I've narrowed this down even further.Specificly, if c-client trys to use
CRAM-MD5 sasl mech against Cyrus 2.1.5 / SASL 2.1.5 server apache will segfault.
The PLAIN mech works fine. c-client defaults to CRAM-MD5 if the imapd server
advertises it.

I don't think this is a bug in c-client / imap-devel yet. If I take the 7.3
imap-devel src package and built it on a 6.2 box then that 6.2 box has no
problems connecting with CRAM-MD5 to the 7.3 server with cyrus 2.1.5 on it.

The same imap-devel / c-client package built on a 7.3 box will segfault apache
when using CRAM-MD5 to connect to a Cyrus 2.1.5 / SASL 2.1.5 server.

Apparently there is some odd interaction with building c-client CRAM-MD5 support
on Red Hat 7.3 that didn't exist on Red Hat 6.2. Yes, I know that 6.2 is crusty
but it's the only other Red Hat Linux box I have to test with at this point.
Comment 2 Scott Russell 2002-07-02 15:14:59 EDT
If someone can provide instructions for having apache dump a core file I'll can
do a gdb backtrace and post it here. We might be able to see what's going on then.
Comment 3 Scott Russell 2002-07-03 00:00:08 EDT
I've narrowed the problem down to issues with php 4.2.1 /
4.1.2 imap module. The segfault will ONLY happen when trying to use
CRAM-MD5 mech for authentication. If the imapd does not advertise
CRAM-MD5 auth then PLAIN auth is used and everything works as expected.

That said, I checked out the mtest tool provided with imap-2001a and
verified that mtest will correctly login to an imap server with
CRAM-MD5. PHP however continues to segfault when trying to do the same
login with CRAM-MD5. (Since RH doesn't install the mtest tool by default I
compiled it by doing an RPM --rebuild imap-2001a and then running
/usr/src/redhat/BUILD/imap-2001a/mtest/mtest. This way I think I'm using the
same libs and compile settings as the installed imap-devel RPM provides.)

I'm fairly certain this narrows the issue down to somethig having to do
with MD5 auth in php4/ext/imap/imap.c and NOT the imap-2001a c-client
libs.

For a simple test case I recomend the script posted in this bug report
and to verify it works against an imapd server that advertises MD5-CRAM.
I'm using Cyrus IMAPd 2.1.5 with SASL 2.1.5 for my tests. I have not yet been
able to test php imap_open() with CRAM-MD5 auth against another imapd other than
Cyrus.

Comment 4 Scott Russell 2002-07-03 00:48:30 EDT
rebuild php 4.2.1 on Red Hat 7.3 with --enable-debug. Ran /usr/sbin/httpd -X
-DHAVE_PHP4 and attached gdb to the process. Triggered segfault and then did a
backtrace. Here is the output. If I need to rebuild php-4.1.2-7 and give you a
bt from that please let me know. (Both php 4.2.1 and the Red Hat RPM php-4.1.2-7
give the same segfault so this should be good enough I think.)

#0  0x42080c14 in strnlen () from /lib/i686/libc.so.6
#1  0x42051e42 in vfprintf () from /lib/i686/libc.so.6
#2  0x4206dbf3 in vsprintf () from /lib/i686/libc.so.6
#3  0x4205a257 in sprintf () from /lib/i686/libc.so.6
#4  0x4096f751 in auth_md5_client (challenger=0x4098aa10 <imap_challenge>,
responder=0x4098aab0 <imap_response>, 
    service=0x409f4cad "imap", mb=0xbfffcdb0, stream=0x8190be8,
trial=0xbfffcd18, user=0xbfffd150 "lnxgeek") at auth_md5.c:107
#5  0x4098a690 in imap_auth (stream=0x8190be8, mb=0xbfffcdb0, tmp=0xbfffd550
"00000001 AUTHENTICATE CRAM-MD5", 
    usr=0xbfffd150 "lnxgeek") at imap4r1.c:884
#6  0x40989b58 in imap_open (stream=0x8190be8) at imap4r1.c:666
#7  0x40962226 in mail_open (stream=0x0, name=0x8190bb4
"{ogg.raleigh.ibm.com:143/imap/notls}", options=0) at mail.c:1058
#8  0x4094f1c0 in php_imap_do_open (ht=4, return_value=0x819317c, this_ptr=0x0,
return_value_used=1, persistent=0) at php_imap.c:844
#9  0x4094f2cc in zif_imap_open (ht=4, return_value=0x819317c, this_ptr=0x0,
return_value_used=1) at php_imap.c:874
#10 0x4043aef1 in abuf.0 () from /etc/httpd/modules/libphp4.so
#11 0x4044bb24 in abuf.0 () from /etc/httpd/modules/libphp4.so
#12 0x4045e402 in abuf.0 () from /etc/httpd/modules/libphp4.so
#13 0x40458d92 in abuf.0 () from /etc/httpd/modules/libphp4.so
#14 0x40459c00 in abuf.0 () from /etc/httpd/modules/libphp4.so
#15 0x40459c7a in abuf.0 () from /etc/httpd/modules/libphp4.so
#16 0x0805475d in ap_invoke_handler ()
#17 0x080671fc in process_request_internal ()
#18 0x08067273 in ap_process_request ()
#19 0x0805f4f7 in child_main ()
#20 0x0805f69a in make_child ()
#21 0x0805f7dd in startup_children ()
#22 0x0805fe30 in standalone_main ()
#23 0x08060723 in main ()
#24 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6
Comment 5 Scott Russell 2002-07-06 13:23:51 EDT
I tried building SNAP php4-200207060900 for testing but it fails to link
mysqlclient libs correctly. Based on that I tried the following:

1) untar php-4.2.1.tar.gz
2) cp php4-200207060900/ext/imap/* php-4.2.1/ext/imap/
3) ./configure; make; make install;
4) restart httpd with -X and run gdb against it.

Here is the resulting back trace from php 4.2.1 with updated imap ext
from php4-200207060900. 

I do NOT think this is a problem with c-client since the mtest program
provided with c-client has NO problems logging in with CRAM-MD5. The
php4 imap extention however will core apache every time when using
CRAM-MD5. PLAIN mechs work fine in both mtest and php4.

#1  0x42051f32 in vfprintf () from /lib/i686/libc.so.6
#2  0x4206dce3 in vsprintf () from /lib/i686/libc.so.6
#3  0x4205a347 in sprintf () from /lib/i686/libc.so.6
#4  0x40918a61 in auth_md5_client (challenger=0x40933d20
<imap_challenge>, 
    responder=0x40933dc0 <imap_response>, service=0x4099dfad "imap", 
    mb=0xbfffcc40, stream=0x811fd50, trial=0xbfffcba8, 
    user=0xbfffcfe0 "lnxgeek") at auth_md5.c:107
#5  0x409339a0 in imap_auth (stream=0x811fd50, mb=0xbfffcc40, 
    tmp=0xbfffd3e0 "00000001 AUTHENTICATE CRAM-MD5", usr=0xbfffcfe0
"lnxgeek")
    at imap4r1.c:884
#6  0x40932e68 in imap_open (stream=0x811fd50) at imap4r1.c:666
#7  0x4090b536 in mail_open (stream=0x0, 
    name=0x812110c "{ogg.raleigh.ibm.com:143/imap/notls}", options=0)
    at mail.c:1058
#8  0x408f823c in php_imap_do_open (ht=4, return_value=0x8153a3c, 
    this_ptr=0x0, return_value_used=1, persistent=0) at php_imap.c:863
#9  0x408f8354 in zif_imap_open (ht=4, return_value=0x8153a3c,
this_ptr=0x0, 
    return_value_used=1) at php_imap.c:893
#10 0x4043aef1 in abuf.0 () from /etc/httpd/modules/libphp4.so
#11 0x4044bb24 in abuf.0 () from /etc/httpd/modules/libphp4.so
#12 0x4045e402 in abuf.0 () from /etc/httpd/modules/libphp4.so
#13 0x40458d92 in abuf.0 () from /etc/httpd/modules/libphp4.so
---Type <return> to continue, or q <return> to quit---
#14 0x40459c00 in abuf.0 () from /etc/httpd/modules/libphp4.so
#15 0x40459c7a in abuf.0 () from /etc/httpd/modules/libphp4.so
#16 0x0805475d in ap_invoke_handler ()
#17 0x080671fc in process_request_internal ()
#18 0x08067273 in ap_process_request ()
#19 0x0805f4f7 in child_main ()
#20 0x0805f69a in make_child ()
#21 0x0805f7dd in startup_children ()
#22 0x0805fe30 in standalone_main ()
#23 0x08060723 in main ()
#24 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

Comment 6 Scott Russell 2002-07-06 23:15:11 EDT
Also tested against wu-imapd server with CRAM-MD5 enabled. Again, apache will
segfault. Here is a backtrace from Red Hat 7.3 with php 4.2.1 compliled against
the default stock imap-devel-2001 package. This confirms that the problem is not
specific to cyrus-imapd CRAM-MD5 authentication.

#0  0x42080d04 in strnlen () from /lib/i686/libc.so.6
#1  0x42051f32 in vfprintf () from /lib/i686/libc.so.6
#2  0x4206dce3 in vsprintf () from /lib/i686/libc.so.6
#3  0x4205a347 in sprintf () from /lib/i686/libc.so.6
#4  0x40918751 in auth_md5_client (challenger=0x40933a10
    <imap_challenge>, responder=0x40933ab0 <imap_response>,
    service=0x4099dcad "imap", mb=0xbfffcd80, stream=0x80b40c8,
    trial=0xbfffcce8, user=0xbfffd120 "test")
    at auth_md5.c:107
#5  0x40933690 in imap_auth (stream=0x80b40c8, mb=0xbfffcd80,
    tmp=0xbfffd520 "00000000 AUTHENTICATE CRAM-MD5",
    usr=0xbfffd120 "test") at imap4r1.c:884
#6  0x40932b58 in imap_open (stream=0x80b40c8) at imap4r1.c:666
#7  0x4090b226 in mail_open (stream=0x0, name=0x812591c
    "{213.243.182.199:143/imap/notls}", options=0)
    at mail.c:1058
#8  0x408f81c0 in php_imap_do_open (ht=3, return_value=0x80b495c,
    this_ptr=0x0, return_value_used=1, persistent=0)
    at php_imap.c:844
#9  0x408f82cc in zif_imap_open (ht=3, return_value=0x80b495c,
    this_ptr=0x0, return_value_used=1) at php_imap.c:874
#10 0x4043aef1 in abuf.0 () from /etc/httpd/modules/libphp4.so
#11 0x4044bb24 in abuf.0 () from /etc/httpd/modules/libphp4.so
#12 0x4045e402 in abuf.0 () from /etc/httpd/modules/libphp4.so
#13 0x40458d92 in abuf.0 () from /etc/httpd/modules/libphp4.so
#14 0x40459c00 in abuf.0 () from /etc/httpd/modules/libphp4.so
#15 0x40459c7a in abuf.0 () from /etc/httpd/modules/libphp4.so
#16 0x0805475d in ap_invoke_handler ()
#17 0x080671fc in process_request_internal ()
#18 0x08067273 in ap_process_request ()
#19 0x0805f4f7 in child_main ()
#20 0x0805f69a in make_child ()
#21 0x0805f7dd in startup_children ()
#22 0x0805fe30 in standalone_main ()
#23 0x08060723 in main ()
#24 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
Comment 7 Scott Russell 2002-07-08 01:07:39 EDT
I've further narrowed this problem down to a known non-reentrant SASL 1.5 issue.
On a clean Red Hat 7.3 workstation install this is easily duplicated trying to
connect with php 4.1.2 with imap_open() to any imapd server that advertises
CRAM-MD5.To duplicate one of the following situation needs to be true:

>> ldap.so and imap.so loaded with php4 imap_open() CRAM-MD5 auth

If you unload ldap.so from php then CRAM-MD5 auth works. If you use ldap.so and
imap.so with php and use PLAIN auth that also works. If you have all three
together apache will segfault.

This is a CLASSIC problem with cyrus-sasl-1.5.x non-reentrant problems. (source:
cyrus-sasl mailing list)

I really need to open discussions with someone at Red Hat about this bug. It can
be solved in several different ways but as it stands now it is clearly a build
problem on the Red Hat 7.3 system.

Please contact me as soon as possible. I would really like to work with you guys
to get some test packages built and to solve this. Thanks much.
Comment 8 Lee Howard 2002-09-30 16:28:45 EDT
I believe that I'm seeing this problem, also.  I'm using Horde IMP v3.0.  It 
was working fine with php-4.0.6 as provided by RedHat, but the minute up2date 
updated with php-4.1.2 then things went sour, and users cannot log into the 
imap system.  I'm seeing the child segfaults in Apache just as the reporter 
states.  If I 'rpm -Uvh --oldrpm' back to the old php-4.0.6 RPMs then I don't 
have a problem.

It's a shame no action by RedHat has been reported here in more than two months.
Comment 9 Lee Howard 2002-12-27 02:44:40 EST
After doing a fresh installation of RedHat 7.1 with the updates, including PHP 
4.1.2, and using Horde's IMP 3.1 I don't have the problem any more.  HOWEVER, I 
do see the following problem as long as mod_ssl is running:

[Sat Dec 21 18:18:07 2002] [notice] suEXEC mechanism enabled 
(wrapper: /usr/sbin/suexec)
[Sat Dec 21 18:18:07 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Sat Dec 21 18:18:38 2002] [error] PHP Warning:  No such host as 
imap.example.com (errflg=2) in Unknown on line 0
[Sat Dec 21 18:35:59 2002] [error] PHP Warning:  Retrying LOGIN authentication 
after AUTHENTICATE LOGIN failed (errflg=1) in Unknown on line 0
[Sat Dec 21 18:35:59 2002] [error] PHP Warning:  Retrying LOGIN authentication 
after AUTHENTICATE LOGIN failed (errflg=1) in Unknown on line 0
[Sat Dec 21 18:35:59 2002] [error] PHP Warning:  Can not authenticate to IMAP 
server: AUTHENTICATE LOGIN failed (errflg=2) in Unknown on line 0
[Sat Dec 21 18:38:39 2002] [notice] caught SIGTERM, shutting down
[Sat Dec 21 18:38:42 2002] [notice] Apache/1.3.27 (Unix)  (Red-Hat/Linux) 
mod_ssl/2.8.12 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.1.2 mod_perl/1.24_01 
mod_throttle/3.1.2 configured -- resuming normal operations
[Sat Dec 21 18:38:42 2002] [notice] suEXEC mechanism enabled 
(wrapper: /usr/sbin/suexec)
[Sat Dec 21 18:38:42 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Sun Dec 22 04:02:00 2002] [notice] SIGHUP received.  Attempting to restart
[Sun Dec 22 04:02:02 2002] [notice] Apache/1.3.27 (Unix)  (Red-Hat/Linux) 
mod_ssl/2.8.12 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.1.2 mod_perl/1.24_01 
mod_throttle/3.1.2 configured -- resuming normal operations
[Sun Dec 22 04:02:02 2002] [notice] suEXEC mechanism enabled 
(wrapper: /usr/sbin/suexec)
[Sun Dec 22 04:02:02 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Sun Dec 22 12:15:28 2002] [error] [client 24.138.31.25] client sent HTTP/1.1 
request without hostname (see RFC2616 section 14.23): /
[Sun Dec 22 12:15:38 2002] [error] mod_ssl: SSL handshake failed (server 
mailbox.mbcloans.com:443, client 24.138.31.25) (OpenSSL library error follows)
[Sun Dec 22 12:15:38 2002] [error] OpenSSL: error:1406B458:lib(20):func
(107):reason(1112)
[Sun Dec 22 14:48:13 2002] [error] [client 80.94.160.22] script not found or 
unable to stat: /var/www/cgi-bin/proxyhead.cgi
[Sun Dec 22 19:04:59 2002] [notice] child pid 21543 exit signal Segmentation 
fault (11)
[Sun Dec 22 22:31:10 2002] [error] [client 207.56.186.135] client sent HTTP/1.1 
request without hostname (see RFC2616 section 14.23): /
[Sun Dec 22 22:31:19 2002] [error] mod_ssl: SSL handshake failed (server 
mailbox.mbcloans.com:443, client 207.56.186.135) (OpenSSL library error follows)
[Sun Dec 22 22:31:19 2002] [error] OpenSSL: error:1406B458:lib(20):func
(107):reason(1112)
[Mon Dec 23 04:02:01 2002] [warn] child process 18850 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 18851 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 18852 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 18857 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 18860 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 18861 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 21129 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 21164 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 21535 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [warn] child process 21544 did not exit, sending 
another SIGHUP
[Mon Dec 23 04:02:01 2002] [notice] SIGHUP received.  Attempting to restart
[Mon Dec 23 04:02:02 2002] [notice] Apache/1.3.27 (Unix)  (Red-Hat/Linux) 
mod_ssl/2.8.12 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.1.2 mod_perl/1.24_01 
mod_throttle/3.1.2 configured -- resuming normal operations
[Mon Dec 23 04:02:02 2002] [notice] suEXEC mechanism enabled 
(wrapper: /usr/sbin/suexec)
[Mon Dec 23 04:02:02 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)

Obviously some of that is extraneous to the subject at hand, but I include it 
for your benefit.  I have disabled mod_ssl (by altering the file name of the 
object file), and I do not have the problem any more... obviously.
Comment 10 Joe Orton 2004-04-07 10:40:39 EDT
This bug just got tracked down in a more recent release: it's a symbol
conflict between libsasl and libc-client (bug 118137).  We'll have
this fixed for the next release, and in an RHEL3 update, at least.
Comment 11 Scott Russell 2004-04-07 11:04:19 EDT
Cool. 

Note You need to log in before you can comment on or make changes to this bug.