On 10 May 2002, Marcell Fodor wrote: > Description: > > The bug in imapd.c code leads to internal buffer overflow. > It may happen when the user ask for fetching partial mailbox > attributes. Below is the message sent in response to the bug report. Thanks for bringing this to our attention, and it should be emphasized that our release version for the past year is already not vulnerable. Jeff -- Jeff Franklin <jpfat_private> Networks and Distruted Computing University of Washington ---------- Forwarded message ---------- Date: Fri, 10 May 2002 11:24:13 -0700 (PDT) From: Mark Crispin <MRCat_private> To: Marcell Fodor <m.fodorat_private> Subject: imapd buffer overflow Hello - Thank you for your email. The patch given below should solve the problem. I would appreciate it if you clarify the following point on your web site and in any security alert. At the top level of your web page, you say that 2001.315 is affected. In the details you indicate "2001.315 compiled with RFC 1730 support". This is technically correct. However, it is unclear and may cause needless alarm; most copies of 2001.315 are safe. I think that something like the following is better: The vulnerability occurs in legacy RFC 1730 support, which is disabled by default in imap-2001 (imapd version 2001.313) and imap-2001a (imapd version 2001.315). Consequently, an unmodified imapd based upon imap-2001 or imap-2001a is not vulnerable. In particular, the prebuilt binaries distributed by the University of Washington for the past year or so are NOT vulnerable. To test if your copy of imapd is vulnerable, run imapd and give the command "x capability". If "IMAP4" does not show up as the first word after "CAPABILITY" in the response then your server is not vulnerable. Example of a vulnerable server: * PREAUTH ..... x capability * CAPABILITY IMAP4 IMAP4REV1 ... x OK CAPABILITY completed Example of a non-vulnerable server: * PREAUTH ..... x capability * CAPABILITY IMAP4REV1 ... x OK CAPABILITY completed You are also correct that the concern is primarily with servers which do not provide shell access, since the main impact of the problem is to get a shell logged in as the user. I am not certain what the point is in posting an exploit program. We know that these exploits are possible. It's an interesting twist to exploit a stack overflow on an automatic in the main() function, but imapd's main() function helpfully exits via "return 0" rather than "_exit (0)" so it's credible. Patch for the problem: 556,557c556,558 < else if (!strncmp (t,"BODY[",5) && (v = strchr(t+5,']')) && !v[1]){ < strncpy (tmp,t+5,i = v - (t+5)); --- > else if (!strncmp (t,"BODY[",5) && (v = strchr(t+5,']')) && > !v[1] && ((i = v - (t+5)) < MAILTMPLEN)){ > strncpy (tmp,t+5,i); 563,564c564,566 < (v = strchr (t+10,']')) && !v[1]) { < strncpy (tmp,t+10,i = v - (t+10)); --- > (v = strchr (t+10,']')) && !v[1] && > ((i = v - (t+10)) < MAILTMPLEN)) { > strncpy (tmp,t+10,i); -- Mark --
This archive was generated by hypermail 2b30 : Sat May 11 2002 - 15:32:30 PDT