PHP 4.0 Bug #6926 Updated: Segfault in imap_open()
| From: | sniper@php.net | Date: | Tue, 17 Oct 2000 15:49:13 +0000 |
| Subject: | PHP 4.0 Bug #6926 Updated: Segfault in imap_open() | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-35268@lists.php.net to get a copy of this message | ||
ID: 6926
Updated by: sniper
Reported By: rbs@bu.edu
Status: Closed
Bug Type: IMAP related
Assigned To:
Comments:
This is now fixed in CVS. Please try it out.
(The patch Chuck mentioned didn't quite fix this.)
--Jani
Previous Comments:
---------------------------------------------------------------------------
[2000-10-17 11:18:05] chagenbu@php.net
Please apply the following patch and test it. This works fine for me, but I have no Kerberized IMAP
servers to test against.
http://chuck.bitgroup.com/imap.patch
---------------------------------------------------------------------------
[2000-09-28 22:09:52] rbs@bu.edu
There is a conspicuous and fundamental programming error in the imap_open() function: it blithely
takes the username and password strings given to it by the caller and does a simple strcpy() to a
fixed-length storage field. Result: Segv - if you're lucky; else peculiar behavior that is very
hard to debug. Through malicious intention or by accident, it is all too easy for the programmer
writing PHP code to supply an overly long string. (We ran into this in using imap_open() to send a
192-char Kerberos authenticator to a kerberized IMAP server, for example. As a simple circumvention
I boosted the ext/imap/php_imap.h array length from 80 to 800.) Suffice to say that the PHP code
should be adaptive, and should either stick to using strings by reference instead of copying to
fixed-length fields, or do something like strdup(), as appropriate.
I have to say that we're very dismayed to see such amateurish programming in a facility
that is put out there for general use, including commercial use. Doing strcpy() of data that is
given to you from an external source violates basic programming tenets and jeopardizes security. I
would strongly recommend that you go through the PHP code and weed out basic problems like this. If
all the web security issues of past years have taught us anything, it is that software needs to
protect itself. It also seems that programming is being accepted without any code review process.
This is to the detriment of the otherwise wonderful facility that PHP is. Please, do what you can to
correct these problems.
thanks, Richard Sims, Boston University OIT
---------------------------------------------------------------------------
Full Bug description available at: http://bugs.php.net/?id=6926