From owner-BUGTRAQ@LISTS.SECURITYFOCUS.COM Fri Jun 9 03:02:56 2000 Date: Fri, 9 Jun 2000 00:00:09 -0700 Reply-To: Bugtraq List Sender: Bugtraq List From: Automatic digest processor Subject: BUGTRAQ Digest - 7 Jun 2000 to 8 Jun 2000 (#2000-127) To: Recipients of BUGTRAQ digests Message-Id: <20000609070011.8F28F1EF0E@lists.securityfocus.com> <..skip..> -- Start of included mail From: Michal Zalewski 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 ;) 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. <=-----= -- End of included mail. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message