OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: BUGTRAQ Digest - 7 Jun 2000 to 8 Jun 2000 (#2000-127)
From: Automatic digest processor (LISTSERVLISTS.SECURITYFOCUS.COM)
Date: Fri Jun 09 2000 - 02:00:09 CDT

<..skip..>

-- Start of included mail From: Michal Zalewski <lcamtufTPI.PL>

Date: Wed, 7 Jun 2000 13:40:26 +0200
Subject: Yet another heap overflow in wu-ftpd and so on...

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 [lcamtuftpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
-- End of included mail.

<skip>

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message