5176794 2000-06-08  20:30  /81 rader/ Postmaster
Mottagare: Bugtraq (import) <11208>
Ärende: Yet another heap overflow in wu-ftpd and so on...
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: squirrel.tpi.pl: lcamtuf owned process doing -bs
X-Nmymbofr: Nir Orb Buk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.LNX.4.10.10006071215070.9028-100000@squirrel.tpi.pl>
Date:         Wed, 7 Jun 2000 13:40:26 +0200
Reply-To: Michal Zalewski <lcamtuf@TPI.PL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Michal Zalewski <lcamtuf@TPI.PL>
To: BUGTRAQ@SECURITYFOCUS.COM

This is result of my 20 minutes long mini-audit of wu-ftpd 2.6.0
source code. I won't spend my time analysing source code nor doing
any debugging.  I simply issued command like:

grep -nE 'sprintf.*\%s|strcat|strcpy' *.c

Gosh... Not even thinking about many, many other dangerous functions
and mechanisms. Results? Yes, some:

1. heap overflow in S/Key authorization mechanism
-------------------------------------------------

The problem affects wu-ftpd installations with S/Key support
enabled. In fact, this mechanism, instead of increasing site
security, results in buffer overflow in the time of user login on
some machines. What is the problem?

Well...

-- ftpd.c --

#if defined(SKEY) && !defined(__NetBSD__)
 [...]
/* skey_challenge - additional password prompt stuff */
char *skey_challenge(char *name, struct passwd *pwd, int pwok)
{
    static char buf[128];
    char sbuf[40];
    struct skey skey;

    /* Display s/key challenge where appropriate. */

    if (pwd == NULL || skeychallenge(&skey, pwd->pw_name, sbuf))
        sprintf(buf, "Password required for %s.", name);
    else
        sprintf(buf, "%s %s for %s.", sbuf,
                pwok ? "allowed" : "required", name);
    return (buf);
}
#endif
-- EOF --

Well... Buffer (buf, size = 128 bytes) is placed on heap, and I'm not
sure it could be exploited any way (read: if there is any important
data on the heap at the time of authorization, or any data processed
later with assumption it will be zeroed - could be, I guess). Aah, an
example?;): USER <much-more-than-128-bytes> ;) No, no SEGV or crash,
simply overwritten piece of memory. Some debugging would be nice.

The problem does NOT affect systems without S/Key support compiled
into ftpd and does NOT affect NetBSD libskey (see #ifdefs).


2. i guess you'll be able to find it by yourself, so...
-------------------------------------------------------

More? Probably I'll be killed ;) but I guess almost anyone who issued
similar command as above 'grep' can see it clearly. It's rather
obvious that there's an overflow in optional feature introduced in
recent wu-ftpd versions, called 'internal ls'. But this problem has
been discovered by someone else (I'm not sure who did it, someone
from teso or Lam3rZ) days ago. Sorry, anyway :)

_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5176794) ------------------------------------------(Ombruten)