8422251 2002-05-10 15:27 +0000  /83 rader/ Marcell Fodor <m.fodor@mail.datanet.hu>
Sänt av: joel@lysator.liu.se
Importerad: 2002-05-11  03:55  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22225>
Ärende: wu-imap buffer overflow condition
------------------------------------------------------------
From: Marcell Fodor <m.fodor@mail.datanet.hu>
To: bugtraq@securityfocus.com
Message-ID: <20020510152713.25507.qmail@mail.securityfocus.com>



10.05.2002
SECURITY BUG REPORT


Affected version:

    * WU-IMAP 2000.283 default install
    * WU-IMAP 2000.284 default install
    * WU-IMAP 2000.287 default install
    * WU-IMAP 2001.315 compiled with RFC 1730 support

Overview:

Wu-imapd is an easy to set-up IMAP daemon created and
distributed by Washington University. Malicious user is able
to construct a malformed request which will overflow an
internal buffer, and run code on the server with uid/gid of
the e-mail owner. The vulnerability mainly affects free
e-mail providers/mail servers where the user has no shell
access to the system.

Description:

The bug in imapd.c code leads to internal buffer overflow.
It may happen when the user ask for fetching partial mailbox
attributes.

    request will cause server to SIG11  : A0666 PARTIAL 1
BODY[AAA...1052bytes..AAA] 1 1

imapd.c
-------
int main (int argc,char *argv[])
{
  unsigned long i,uid;
  long f;
  char *s,*t,*u,*v,tmp[MAILTMPLEN];
.
.
.

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.PEEK[",10) &&
             (v = strchr (t+10,']')) && !v[1]) {
          strncpy (tmp,t+10,i = v - (t+10));
.
.
.
-------

The bug is very similar to the one found in Kerberos4 ftp
client. No bound check prior moving user supplied data.
Since the attacker overwrites the  server's main stack,
overflow will occur when the user logs out.





Marcell Fodor
-------------
e-mail: m.fodor@mail.datanet.hu
web: http://mantra.freeweb.hu
(8422251) /Marcell Fodor <m.fodor@mail.datanet.hu>/-
Kommentar i text 8424693 av Jeff Franklin <jpf@cac.washington.edu>
8424693 2002-05-10 17:34 -0700  /97 rader/ Jeff Franklin <jpf@cac.washington.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2002-05-12  00:53  av Brevbäraren
Extern mottagare: Marcell Fodor <m.fodor@mail.datanet.hu>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22249>
Kommentar till text 8422251 av Marcell Fodor <m.fodor@mail.datanet.hu>
Ärende: Re: wu-imap buffer overflow condition
------------------------------------------------------------
From: Jeff Franklin <jpf@cac.washington.edu>
To: Marcell Fodor <m.fodor@mail.datanet.hu>
Cc: bugtraq@securityfocus.com
Message-ID: <Pine.WNT.4.50.0205101722550.776-100000@xp1_is.nebula.washington.edu>

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 --
(8424693) /Jeff Franklin <jpf@cac.washington.edu>/(Ombruten)
Kommentar i text 8427171