I tried to add the following to that PHP bug request, but it would not
allow me to do so:
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.
Here are details from the c-client source:
* 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.
*
* As a half-hearted attempt, these new compatability functions for the
* legacy interfaces limit what they write to size SENDBUFLEN and will
* fatal() if more than that is written. However, that isn't good enough
* since several of these functions *append* to the buffer, and return an
* updated pointer. Consequently, there is no way of knowing what the
* actual available space is in the buffer, yet the function will still
* write up to SENDBUFLEN bytes even if there is much less space actually
* available. The result is a buffer overflow.
*
* You won't get a buffer overflow if you never attempt to append using
* these interfaces, but you can get the fatal() if it tries to write
* more than SENDBUFLEN bytes.
*
* To avoid this problem, use the corresponding rfc822_output_???()
* functions instead, e.g., rfc822_output_address() instead of
* rfc822_address().
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.
The bottom line is that c-client fixed the problem, but you need to update
your application to use the new function calls which have a new interface
to permit buffer checking. It is impossible to fix it with the old
interface.
Here is a list of the c-client routines that should NOT be used:
void rfc822_header (char *header,ENVELOPE *env,BODY *body);
void rfc822_header_line (char **header,char *type,ENVELOPE *env,char
*text);
void rfc822_address_line (char **header,char *type,ENVELOPE *env,ADDRESS
*adr);
char *rfc822_write_address_full (char *dest,ADDRESS *adr,char *base);
void rfc822_address (char *dest,ADDRESS *adr);
void rfc822_cat (char *dest,char *src,const char *specials);
void rfc822_write_body_header (char **header,BODY *body);
Note all those char* and char** without any size markers. Note as well
that all of these are header generation string generation routines; you
don't really need to use c-client for that stuff. c-client is for mailbox
access and protocol negotiation; this stuff is fluff.
There are two other legacy routines which are safe to use (the char*t in
rfc822_output() isn't actually used), so in a pinch you don't have to
update these to the newer routines:
long rfc822_output (char *t,ENVELOPE *env,BODY *body,soutr_t f,void *s,
long ok8bit);
long rfc822_output_body (BODY *body,soutr_t f,void *s);
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
