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 <jpf@cac.washington.edu>
Networks and Distruted Computing University of Washington
---------- Forwarded message ----------
Date: Fri, 10 May 2002 11:24:13 -0700 (PDT)
From: Mark Crispin <MRC@CAC.Washington.EDU>
To: Marcell Fodor <m.fodor@mail.datanet.hu>
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 --
