re: [lamagra@DIGIBEL.ORG: proftp advisory]
Bug 1:
In proftpd you have the option of running as nobody so it shouldn't be much trouble.
So anyone running as root could easily change it...
Oh well, just my 5 cents
/Johan
----- Original Message -----
From: Chris Hanlon <chanlon@amavi.com>
To: <debian-security@lists.debian.org>
Sent: Thursday, July 06, 2000 12:39 AM
Subject: [lamagra@DIGIBEL.ORG: proftp advisory]
> ----- Forwarded message from lamagra <lamagra@DIGIBEL.ORG> -----
>
> Delivered-To: chanlon@AMAVI.COM
> Approved-By: aleph1@SECURITYFOCUS.COM
> Delivered-To: bugtraq@lists.securityfocus.com
> Delivered-To: bugtraq@securityfocus.com
> X-Mailer: Spruce 0.6.2 for X11 w/smtpio 0.7.6
> Date: Mon, 3 Jul 2000 12:40:54 CEST
> Reply-To: lamagra@digibel.org
> From: lamagra <lamagra@DIGIBEL.ORG>
> Subject: proftp advisory
> X-To: macgyver@tos.net
> To: BUGTRAQ@SECURITYFOCUS.COM
>
> ___________________________________________________
> 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: lamagra@digibel.org
>
> 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
>
> ----- End forwarded message -----
>
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: