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 <[EMAIL PROTECTED]> To: <debian-security@lists.debian.org> Sent: Thursday, July 06, 2000 12:39 AM Subject: [EMAIL PROTECTED]: proftp advisory] > ----- Forwarded message from lamagra <[EMAIL PROTECTED]> ----- > > Delivered-To: [EMAIL PROTECTED] > Approved-By: [EMAIL PROTECTED] > Delivered-To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > From: lamagra <[EMAIL PROTECTED]> > Subject: proftp advisory > X-To: [EMAIL PROTECTED] > 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: [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 > > ----- End forwarded message ----- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >