The code checks for that, and rejects a literal size greater than
0x7ffffffe.
Just to make sure I'm on the same page, is this the check you are
referring to, from imap4r1.c:4937
if ((i = strtoul (*txtptr,(char **) txtptr,10)) > MAXSERVERLIT) {
sprintf (LOCAL->tmp,"Absurd server literal length %lu",i);
mm_notify (stream,LOCAL->tmp,WARN);
stream->unhealthy = T; /* read and discard */
do net_getbuffer (LOCAL->netstream,j = min (i,(long) IMAPTMPLEN - 1),
LOCAL->tmp);
while (i -= j);
}
If so, then the check is working okay and the seg fault is actually
happening inside that block. Here's the end of my stack trace:
#0 0x00543ff1 in memcpy () from /lib/libc.so.6
#1 0x00ac70c7 in ssl_getbuffer (stream=0x8a68918, size=4294967295,
buffer=0x8a6251c) at osdep.c:694
#2 0x00ac8eb2 in net_getbuffer (st=0x8a98c30, size=4294967295,
buffer=0x8a6251c) at mail.c:6252
#3 0x00af62b6 in imap_parse_string (stream=0x8a621e0,
txtptr=0xbfedb3d0, reply=0x8a624c4, md=0xbfedb38c, len=0xbfedb3ac,
flags=0) at imap4r1.c:4941
If I'm reading it right, the seg fault is happening within the code that
is dealing with a literal greater than 0x7ffffffe. There's a min() call
that looks like it was intended to bring down the size:
min (i,(long) IMAPTMPLEN - 1)
But it returns 4294967295 instead of IMAPTMPLEN - 1 (which you probably
know is smaller and I confirmed for myself) because the min() function
takes both parameters as longs so 4294967295 is converted back into -1.
Then min() decides -1 is less than (IMAPTMPLEN - 1) and returns it.
That return is stored as an unsigned long which means its converted back
to 4294967295 and then is passed down through net_getbuffer and to the
memcpy that crashes.
If you still think that's just a weird compiling issue on my system,
alright, and I apologize for wasting your time. And maybe the imap
server shouldn't even be returning -1 in the first place; if I can build
a good test case I'll definitely send off a bug report and see what they
have to say about that. But it seems like some code was written here to
prevent such a crash, but this scenario is getting around it because of
casting issues.
Mark Crispin wrote:
That's bizarre. The code checks for that, and rejects a literal size
greater than 0x7ffffffe. The check works on every system that I've
tried. Whatever compiler built it on your system must be generating a
signed comparison.
-- 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.
------------------------------------------------------------------------
Date: Fri, 8 Aug 2008 13:58:46 -0400
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [email protected]
Subject: Re: [Imap-uw] Crash fetching an empty text part
Thanks for the reply. strtoul() is returning 4294967295 in this case.
The max value, I guess, instead of the min. Thanks again.
Mark Crispin wrote:
It's a bug in the IMAP server. It is sending a literal (a type of string)
with
a size count of -1. The size count for a literal is an unsigned, non-zero,
32-bit value.
I wonder what strtoul() does in this case. I would have expected it to
return a 0.
I have added defensive code for this case in Panda IMAP; but the real fix is
going to be to the IMAP server. You ought to report this bug to Zimbra
and the Cyrus people.
-- 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.
Date: Fri, 8 Aug 2008 13:24:27 -0400
From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
To: [email protected] <mailto:[email protected]>
Subject: [Imap-uw] Crash fetching an empty text part
Hello,
I've got a php app using the php-imap extension and a segmentation fault
occurs during a call to imap_fetchbody on a specific message and
section. I've attached an example email message that causes my crash. It
seems a multipart/mixed message that contains a text part with no text
will crash when I attempt to fetch the empty part. I tried a message
that wasn't multipart and contained only a single empty text part and no
crash occurred.
Debugging, I see the crash occurs in memcpy called from c-client. I
believe that the problem is in the imap_parse_string function. The crash
scenario calls imap_parse_string with the value "{-1}" in the txtptr
parameter. Later in the function the "-1" is extracted and passed to
strtoul which understandably isn't terribly happy about bing asked to
make a negative number unsigned. The crazy value returned from strtoul
is passed down to the memcpy which crashes.
At this point I am a bit stumped. I'm not sure where that "-1" is coming
from, though I suspect it could be from the imap server. We're using
Zimbra which uses cyrus (2.1.22.3) for imap. The php app is running on
Fedora 9 using php 5.2.6-2 and libc-client-2007b-1 both installed by
rpm.
If there's any help or advice anyone can offer I would appreciate it.
Let me know if you need any more info. Thanks!
_________________________________________________________________
Your PC, mobile phone, and online services work together like never before.
http://clk.atdmt.com/MRT/go/108587394/direct/01/
------------------------------------------------------------------------
Reveal your inner athlete and share it with friends on Windows Live.
Share now!
<http://revealyourinnerathlete.windowslive.com?locale=en-us&ocid=TXT_TAGLM_WLYIA_whichathlete_us>
_______________________________________________
Imap-uw mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
