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

See also
http://archives.devshed.com/forums/networking-100/new-message-writing-ro
utines-in-imap-2005t-1639473.html

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;

I am using imap c-client 2007a with php-5.2.5.

I am working with an extensively modified version of:
http://migrationtool.sourceforge.net

I ran into this issue migrating people's mailboxes in Exchange Server. 
I wanted to confirm that the patch submitted by sborrill at precedence
dot co dot uk appears to have fixed the buffer overflow bug.

Thank you very much.

I use Horde Groupware Webmail Edition 1.0.6 with Apache/1.3.41 (Unix)
PHP/5.2.5 mod_ssl/2.8.31 OpenSSL/0.9.8g.

I had the same bug.

I tried sborril patch: it fix the problem also in my environment. I
appreciate if could be added to next release of php.

Regards

Over 7 months and two releases have passed, yet no developer even
commented on this *security* issue (according to the c-client devs). So
what's up with this, are there any problems with the patch? If yes,
would you mind pointing them out, so that one can try to fix them?

This is CVE-2008-2829.

please fix 008_imap-bufferoverflows.patch to include the typedef for
RFC822BUFFER.

/* Output buffering for RFC [2]822 */

typedef long (*soutr_t) (void *stream,char *string);

typedef struct rfc822buffer {
  soutr_t f;			/* I/O flush routine */
  void *s;			/* stream for I/O routine */
  char *beg;			/* start of buffer */
  char *cur;			/* current buffer pointer */
  char *end;			/* end of buffer */
} RFC822BUFFER;

I will give it some love while working on the imap lib.

Looking at the current code, it looks like there's no actual overflow,
but rfc822_write_address is limited so the abort happens. I am not
seeing code path that would lead to rfc822_write_address writing more
data than buffer size, unless I misunderstand how _php_imap_address_size
works. 
Is this impression correct? If so, we still need to fix it since abort()
is a nasty things, but it doesn't seem to be a security issue. 

Also, what is the requirement for using rfc822_output_address_list -
what is minimal c-client lib version that has it supported?

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.