Bug 118137

Summary: PHP imap_open crashes when remote servers used CRAM-MD5
Product: Red Hat Enterprise Linux 3 Reporter: Per Steinar Iversen <persteinar.iversen>
Component: imapAssignee: John Dennis <jdennis>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dowdle, jorton, orkcu
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-05-12 01:24:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Per Steinar Iversen 2004-03-12 12:46:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Description of problem:
The following little script works fine when run from the cli:

<html>
<body>
<?
$mbox =imap_open('{imap.hio.no/notls/norsh}INBOX.Trash','user','secret')
        or die("Could not connect to imap server");

echo $mbox,"\n";

imap_close($mbox);
?>
</body>
</html>

A typical output:

# php imap.php 
Content-type: text/html
X-Powered-By: PHP/4.3.2

<html>
<body>
Resource id #1
</body>
</html>

If the script is served through apache there is no output, and no
entry in the access-log. In the error-log there is the following:

[Fri Mar 12 13:41:59 2004] [notice] child pid 1972 exit signal
Segmentation fault (11)

Some testing shows that this does not occur when the imap server
allows plaintext logins, CRAM-MD5 seems to be the problem.
Sniffing with ethereal shows that the script starts the imap
connection and then dies before completing the login.

I am not sure if this is a php, httpd og imap-2002d problem.



Version-Release number of selected component (if applicable):
php-4.3.2-8.ent

How reproducible:
Always

Steps to Reproduce:
1. Use imap_open from php against imap server that does not allow
plaintext logins
2. The script dies 
3.
    

Actual Results:  Nothing apart from entries in the error log.

Expected Results:  At least some output in my browser.

Additional info:

Comment 1 Joe Orton 2004-03-12 12:55:35 UTC
Thanks for the report.  To speed up investigation can you get a core
dump and a backtrace?

echo "ulimit -c unlimited" >> /etc/sysconfig/httpd
echo "CoreDumpDirectory /tmp" > /etc/httpd/conf.d/core.conf

then restart httpd, and trigger the error.  To get a backtrace, run:

gdb /usr/sbin/httpd /tmp/core.<pid>

and post the results of entering "where" into gdb.

Comment 2 Per Steinar Iversen 2004-03-12 13:06:44 UTC
I did this now, but no core files:

# service httpd stop 
Stopping httpd:                                            [  OK  ]
# cat /etc/sysconfig/httpd
ulimit -c unlimited
# cat /etc/httpd/conf.d/core.conf
CoreDumpDirectory /tmp
# service httpd start
Starting httpd:                                            [  OK  ]

# wget http://localhost/imap.php
--14:10:24--  http://localhost/imap.php
           => `imap.php'
Resolving localhost... done.
Connecting to localhost[127.0.0.1]:80... connected.
HTTP request sent, awaiting response... 
End of file while parsing headers.
Retrying.

In the log:

[Fri Mar 12 14:10:25 2004] [notice] child pid 2468 exit signal
Segmentation fault (11)
[Fri Mar 12 14:10:26 2004] [notice] child pid 2469 exit signal
Segmentation fault (11)

But no files in /tmp :
# ls -al /tmp
total 12
drwxrwxrwt    3 root     root         4096 Mar 12 14:10 .
drwxr-xr-x   21 root     root         4096 Mar  1 12:45 ..
drwx------    2 root     root         4096 Jan  1  1970 orbit-root







Comment 3 Joe Orton 2004-03-12 13:12:19 UTC
Apologies, those instructions weren't right for RHEL3.  Can you try:

# service httpd stop
# ulimit -c unlimited
# /usr/sbin/httpd

Comment 4 Per Steinar Iversen 2004-03-12 13:32:46 UTC
#0  0xb719fe00 in strnlen () from /lib/tls/libc.so.6
#1  0xb716e1f2 in vfprintf () from /lib/tls/libc.so.6
#2  0xb718a04c in vsprintf () from /lib/tls/libc.so.6
#3  0xb7174d3d in sprintf () from /lib/tls/libc.so.6
#4  0xb648a52f in auth_md5_client () from /usr/lib/php4/imap.so
#5  0xb64b77e2 in imap_auth () from /usr/lib/php4/imap.so
#6  0xb64b6e54 in imap_open () from /usr/lib/php4/imap.so
#7  0xb649766f in mail_open () from /usr/lib/php4/imap.so
#8  0xb647b0e2 in zm_info_imap () from /usr/lib/php4/imap.so
#9  0xb647b33e in zif_imap_open () from /usr/lib/php4/imap.so
#10 0xb6d696c8 in execute () from /etc/httpd/modules/libphp4.so
#11 0xb6d5b026 in zend_execute_scripts () from
/etc/httpd/modules/libphp4.so
#12 0xb6d2fc73 in php_execute_script () from /etc/httpd/modules/libphp4.so
#13 0xb6d6e338 in execute () from /etc/httpd/modules/libphp4.so
#14 0x0807480c in ap_pass_brigade ()
#15 0x0807c349 in ap_core_translate ()
#16 0x08068685 in ap_run_handler ()
#17 0x08068c9f in ap_invoke_handler ()
#18 0x08065326 in ap_process_request ()
#19 0x0806095c in _start ()
#20 0x08271d58 in ?? ()
#21 0x00000004 in ?? ()
#22 0x08271d58 in ?? ()
#23 0xb6f722f7 in modperl_process_connection_handler () from
/etc/httpd/modules/mod_perl.so
#24 0x08072165 in ap_run_process_connection ()
#25 0x08066ba1 in ap_graceful_stop_signalled ()
#26 0x08066cf4 in ap_graceful_stop_signalled ()
#27 0x08066e16 in ap_graceful_stop_signalled ()
#28 0x0806763d in ap_mpm_run ()
#29 0x0806daef in main ()


Comment 5 Joe Orton 2004-04-06 16:30:37 UTC
This appears to be a bug due to poor coding practice in two unrelated
packages.

The function called immediately prior to this sprintf was hmac_md5().
 There is a symbol conflict on hmac_md5(), since it is also defined by
libsasl.so.7, so when imap.so is loaded, the wrong hmac_md5() might be
called.

The simplest place fix this is in the UW imap package, by making all
the functions in auth_md5.c static.

Comment 16 Per Steinar Iversen 2004-04-13 07:49:34 UTC
Is it likely that this will be patched in the UW imap package?

Comment 17 John Dennis 2004-04-13 15:55:42 UTC
A UW imap package was produced and Joe will be testing with it. If
successful it will likely going into U3, its too late for U2. If you
are stuck in the water and would like to test you can ftp the patched
rpm here:

ftp://people.redhat.com/jdennis/imap-2002d-8.i386.rpm

Comment 18 Per Steinar Iversen 2004-04-14 10:04:33 UTC
I picked up this rpm and installed it but the PHP code still crashes
when run through apache but not from the command line, the traceback
looks the same as before too - is it necessary to rebuild php-imap
also? In that case the imap-devel package is probably necessary too.


Comment 19 Joe Orton 2004-04-16 13:13:37 UTC
Updated PHP packages which have bene rebuilt against the fixed imap
packages are now available for test purposes from here:

http://people.redhat.com/jorton/Taroon-php/

if you have further issues please let us know.

Comment 20 Roger Pena-Escobio 2004-04-19 13:57:02 UTC
hi, those php packages also resolve an "inconvenient" behaivor, i 
couldn't test it with RHEL because i can't access to it, so i use 
Whitebox for my servers. One of them is just for webmail, so i have 
instaled in it apache+php+Horde/IMP+mysql , the problem come when 
imap server goes down for whatever reason, apache reach the 
MaxClients Limit and never return to live by it self, i have to 
restart it by hand :-( 
today i was luck, i found this bug (because taroon message) and also 
my imap server goes down so i test the new php package and apache 
reach the MaxClient limits but, this time, it manage to survive and 
recover great from these imap server crash :-) 
big thanks to you Joe Orton!!! 

Comment 21 Roger Pena-Escobio 2004-04-19 15:12:29 UTC
happiness will not be forever in the poor's house :-( 
 
my problem is still present :-( 
 
right now i got another imap server crash (two in one day, very 
uncommon but it happen) and the apache reach the limits and never 
come back from it, even when the imap server is back ... 
i don't know if i should enter a bug in bugzilla because maybe is a 
HORDE/IMP problem (but with apache-1.3.27-3.7.2 and php-4.1.2-7.2.6, 
same horde, same imap server i never had this problem), and also, i 
couldn't reproduce it making call to php pages in a "for" cicle. 
 
what do you think? 
sorry make you troble, i know this is not the rigth forum/way to ask 

Comment 22 John Flanagan 2004-05-12 01:24:50 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-214.html


Comment 23 Scott Dowdle 2004-09-10 15:10:56 UTC
Ok, I'm running RHEL AS 3 U3 and it upgraded the following packages:  
  
imap-2002d-9  
and  
php-4.3.2-14.ent  
and  
php-imap-4.3.2-14.ent  
  
Yet I appear to get the same issue reported here.  I haven't jumped  
through all of the hoops with the crash dumps etc... but I can state  
that the function imap_open function call is not working... not as  
documented by the PHP developers  
(http://us4.php.net/manual/en/function.imap-open.php) and not even  
with the added parameters that seemed to work with RHEL AS 3 U2   
  
$mbox = @imap_open ("{localhost:143/imap/notls/user=" .  
$username ."}INBOX", "$username", "$password");  
  
Any idea HOW to make this function work?  I have several PHP scripts  
that are relying on the imap_open function for authentication... and  
not really to pick up email.  Any work around, including a suggestion  
on a different function call to use... would be helpful.  

Comment 24 Joe Orton 2004-09-10 15:28:47 UTC
Scott, I think that should be /notls/norsh/, otherwise it will try to
use rsh - that behaviour should not have changed since RHEL3 U2. 
Please file a separate bug if you're still having issues.

Comment 25 Scott Dowdle 2004-09-10 18:01:14 UTC
Thanks, tacking on norsh/ to the end worked great!