ID: 42862
Comment by: sborrill at precedence dot co dot uk
Reported By: Maylein at ub dot uni-heidelberg dot de
Status: Assigned
Bug Type: IMAP related
Operating System: Linux 2.6.22
PHP Version: 5.2.4
Assigned To: iliaa
New Comment:
php_imap.c uses rfc822_write_address() which, with imap-uw sources
since 2005, limits the complete returned address list to 16383 bytes in
length irrespective of the size of the buffer you pass into it (you
don't pass the length, so it can't know the actual size).
This means that if you have a large address lists in your To: or Cc:
headers, that would expand to more than 16383 characters, PHP will
core-dump with SIGABRT.
This affects PHP HEAD too.
rfc822_write_address is deprecated:
* WARNING: These routines are for compatibility with old software
only.
*
* Their use in new software is to be avoided.
*
* These interfaces do not provide satisfactory buffer checking. In
* versions of c-client prior to imap-2005, they did not provide any
* buffer checking at all.
The fix is to use rfc822_output_address_list().
Patch below (against 5.2.5):
--- php_imap.c.orig 2007-07-31 01:31:10.000000000 +0100
+++ php_imap.c 2008-03-04 17:48:30.000000000 +0000
@@ -70,6 +70,7 @@
static void _php_imap_add_body(zval *arg, BODY *body TSRMLS_DC);
static void _php_imap_parse_address(ADDRESS *addresslist, char
**fulladdress, zval *paddress TSRMLS_DC);
static int _php_imap_address_size(ADDRESS *addresslist);
+static void _php_rfc822_write_address_len (char *dest, ADDRESS *adr,
int len);
/* the gets we use */
static char *php_mail_gets(readfn_t f, void *stream, unsigned long
size, GETS_DATA *md);
@@ -2137,7 +2138,7 @@
}
string[0]='\0';
- rfc822_write_address(string, addr);
+ _php_rfc822_write_address_len(string, addr, sizeof(string));
RETVAL_STRING(string, 1);
}
/* }}} */
@@ -2906,13 +2907,13 @@
if (env->from &&
_php_imap_address_size(env->from) < MAILTMPLEN)
{
env->from->next=NULL;
address[0] = '\0';
- rfc822_write_address(address,
env->from);
+ _php_rfc822_write_address_len(address,
env->from,
sizeof(address));
add_property_string(myoverview, "from",
address, 1);
}
if (env->to && _php_imap_address_size(env->to)
< MAILTMPLEN) {
env->to->next = NULL;
address[0] = '\0';
- rfc822_write_address(address, env->to);
+ _php_rfc822_write_address_len(address,
env->to,
sizeof(address));
add_property_string(myoverview, "to",
address, 1);
}
if (env->date) {
@@ -3883,6 +3884,34 @@
/* }}} */
+/* {{{ _php_rfc822_soutr
+ */
+static long _php_rfc822_soutr (void *stream,char *string)
+{
+ return NIL;
+}
+
+/* }}} */
+
+
+/* {{{ _php_rfc822_write_address_len
+ */
+static void _php_rfc822_write_address_len ( char *dest, ADDRESS *adr,
int len)
+{
+ RFC822BUFFER buf;
+
+ buf.beg = dest;
+ buf.cur = buf.beg;
+ buf.end = buf.beg + len - 1;
+ buf.s = NIL;
+ buf.f = _php_rfc822_soutr;
+ rfc822_output_address_list (&buf, adr, 0, NIL);
+ *buf.cur = '\0';
+}
+
+/* }}} */
+
+
/* {{{ _php_imap_parse_address
*/
static void _php_imap_parse_address (ADDRESS *addresslist, char
**fulladdress, zval *paddress TSRMLS_DC)
@@ -3897,7 +3926,7 @@
if ((len = _php_imap_address_size(addresstmp))) {
tmpstr = (char *) pemalloc(len + 1, 1);
tmpstr[0] = '\0';
- rfc822_write_address(tmpstr, addresstmp);
+ _php_rfc822_write_address_len(tmpstr, addresstmp, len);
*fulladdress = tmpstr;
} else {
*fulladdress = NULL;
Previous Comments:
------------------------------------------------------------------------
[2007-10-30 17:15:29] [EMAIL PROTECTED]
Reclassified. (This is the correct place for this, it's imap related)
------------------------------------------------------------------------
[2007-10-22 11:44:14] Maylein at ub dot uni-heidelberg dot de
No one seems to care about a bug report in
the category 'imap related', so I put it now
in the category 'reproducible crash'.
------------------------------------------------------------------------
[2007-10-11 08:49:53] Maylein at ub dot uni-heidelberg dot de
Please tell me, if there will be a patch
for the imap-extension.
It's an security issue, isn't it?
If you don't plan to patch the imap extension
(as I understand from the answer on Bug #40925)
then you subsequently need to remove
this extension.
------------------------------------------------------------------------
[2007-10-11 08:20:14] Maylein at ub dot uni-heidelberg dot de
See also
http://archives.devshed.com/forums/networking-100/new-message-writing-routines-in-imap-2005t-1639473.html
------------------------------------------------------------------------
[2007-10-05 07:29:33] Maylein at ub dot uni-heidelberg dot de
Description:
------------
I am using the uw imap c-client-library with php-5.2.4 and apache
2.0.61 for my webmailer software TWIG.
Some actions causes the httpd child to crash:
httpd: IMAP toolkit crash: rfc822.c legacy routine buffer overflow
See also
http://bugs.php.net/bug.php?id=40925&edit=1
uw imap developers say that it is definitely a php issue
which you have been denying in former bug reports.
So please have a second thought on this issue.
Here is the response of the uw imap developers:
> PHP is calling c-client legacy RFC 822 header generation routines
> that write headers into a "big enough buffer". These routines were
> never intended for external use.
> There is no way in the old interface to know how much space is left
> in the buffer. Those routines were written in 1988 when that was
> "good enough". They were left unfixed because supposedly "nobody
> used them". When it became clear that people were using those
> routines after all, they were replaced by routines with proper
> buffer checking.
> The old routine names exist as compatibility interfaces into the new
> routines, but the old interface itself prevents proper checking.
> ...
> Let's be clear; if PHP calls these old routines, it is not just a
> core dump issue; it is a security bug. The abort catches some, but
> NOT all of the buffer overflows.
> ...
> In case it wasn't clear from the previous message, there is nothing
> to fix at the c-client end. That "legacy routine buffer overflow"
> is effectively the same thing as getting a SEGV from strcpy(). As
> the message says, it's a detected buffer overflow. But there is
> nothing that c-client can do to recover.
> The fix is not to call the routine that has the buffer overflow, but
> that has to be in PHP.
> I'm sorry that this is bad news for you, especially as the PHP
> developers seem to be unable to understand the issue (and thus are
> telling you to talk to me).
Actual result:
--------------
httpd child crashes with a buffer overflow
httpd: IMAP toolkit crash: rfc822.c legacy routine buffer overflow
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=42862&edit=1
