I've follow the thread about wuftpd and proftpd.
I remember that there were some postings about proftpd
last year in the bugtraq. But before I did search the
archive there came a fresh posting:
On Mon, 3 Jul 2000, lamagra wrote:
> ___________________________________________________
> http://lamagra.seKure.de: advisory #1
>
> Advisory: misc. bugs
> Programname: proftpd
> Versions: 1.2.0 <= pre10
> Vendor: proftpd.net
> Severity: high (root shell) and low
> Contact: [EMAIL PROTECTED]
>
> Bug1:
> void set_proc_title(char *fmt,...) in src/main.c
>
> <snippet>
> memset(statbuf, 0, sizeof(statbuf));
> vsnprintf(statbuf, sizeof(statbuf), fmt, msg);
>
> #ifdef HAVE_SETPROCTITLE
> setproctitle(statbuf);
> #endif /* HAVE_SETPROCTITLE */
> </snippet>
>
> setproctitle, defined setproctitle(char *fmt,...);, calls vsnprintf().
> This makes it vulnerable for formatattacks. By carefully outlining the
> attackbuffer it's possible to gain root priviledges.
>
> Fix: use setproctitle("%s",statbuf);
>
> Bug2:
> MODRET pam_auth(cmd_rec *cmd) in modules/mod_pam.c
>
> <snippet>
> /* Allocate our entries...we don't free this because PAM does this for
> us.
> */
> pam_user = malloc(strlen(cmd->argv[0]) + 1);
> if(pam_user == (char *)0)
> return pam_return_type ? ERROR(cmd) : DECLINED(cmd);
> sstrncpy(pam_user, cmd->argv[0], strlen(cmd->argv[0]) + 1);
>
> pam_pass = malloc(strlen(cmd->argv[1]) + 1);
> if(pam_pass == (char *)0)
> return pam_return_type ? ERROR(cmd) : DECLINED(cmd);
> sstrncpy(pam_pass, cmd->argv[1], strlen(cmd->argv[1]) + 1);
> </snippet>
>
> PAM doesn't do it for you though. Which leaves a nice memoryleak.
> But since USER/PASS is limited to 3 tries and user changing isn't
> supported.
> This can't be used as a Denial of service attack against proftpd, unless
> the administartor sets a different (higher) limit.
>
> Fix: pstrdup() or just use cmd->argv[0] and cmd->argv[1].
>
> Bug3:
> void logformat(char *nickname, char *fmts) doesn't check boundaries on
> it's
> local variable 'format'. As a result custom logformats could overflow the
> buffer. Just a really small thingie :) Could cause some problems though.
>
> Bug3:
> int dolist(cmd_rec *cmd, const char *opt, int clearflags) in
> modules/mod_ls.c
> <snippet>
> char pbuffer[MAXPATHLEN];
>
> if(*arg == '~') {
> struct passwd *pw;
> int i;
> const char *p;
>
> i = 0;
> p = arg;
> p++;
>
> while(*p && *p != '/')
> pbuffer[i++] = *p++;
> pbuffer[i] = '\0';
> </snippet>
>
> This function gets called by cmd_stat, with 'arg' being the argument of
> STAT.
> This looks really bad and ugly. But isn't really exploitable since the
> input
> buffer is only 1024 bytes. But it's still insecure programming.
>
>
> Copyright 2000-2001
> lamagra.seKure.de
>
-------------------------------------------------------------------------
Sending unsolicited commercial email to this address may be a violation
of the Washington State Consumer Protection Act, chapter 19.86 RCW.
Das Verschicken unverlangter kommerzieller email an diese Adresse ist
verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).
(Frank Meurer, <[EMAIL PROTECTED]>, PGP ID: 0x5E756DA8)
