[15664] in bugtraq
Re: ProFTPD Advisory
daemon@ATHENA.MIT.EDU (MacGyver)
Thu Jul 6 15:26:56 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <FOELKJMHFODMNIMFLGPFEENHCOAA.macgyver@tos.net>
Date: Wed, 5 Jul 2000 16:23:23 -0500
Reply-To: MacGyver <macgyver@TOS.NET>
From: MacGyver <macgyver@TOS.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <D13DAF831949D3119F8600C0F03CB186737D67@mail.lifeplususa.com>
A couple of things:
That advisory was actually sent out by mistake. These issues were known,
and are addressed in the latest CVS version of ProFTPD. They are relatively
minor, in general, and if you're using sound security policies in the first
place (including following some of the advice given on the web site
(http://www.proftpd.net/security.html), any potential problems are already
non-issues.
There was a miscommunication between myself, Aleph 1 (Maintainer of
BugTraq), and Lamagra, and so the advisory was mistakenly posted already. I
had asked Lamagra to hold off until this weekend (which he graciously agreed
to do), since I had planned to release 1.2.0 later this week.
That said, they are issues, and they need to be addressed, regardless of how
remote the possibility of an exploit is. For those extremely concerned,
feel free to grab the latest CVS version of ProFTPD, which addresses these
issues.
I hope this clarification helps, and as I said, ProFTPD 1.2.0 will be
released later this week, and contains this, and many other
fixes/enhancements. Then, I can get on rewriting a few core pieces of
ProFTPD to focus more heavily on performance enhancements, flexibility, and
FTP security extensions.
-MacGyver.
>
> something tells me that you may already know this, but in any case here it
> is straight off of securityfocus.
>
> matt
>
>
>
>
> -----Original Message-----
> From: lamagra [mailto:lamagra@DIGIBEL.ORG]
> Sent: Monday, July 03, 2000 7:41 AM
> To: BUGTRAQ@SECURITYFOCUS.COM
> Subject: proftp advisory
>
>
>
> ___________________________________________________
> 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
>
> --
> To unsubscribe, send mail to proftpd-request@proftpd.net with
> "unsubscribe"
> in the subject field of the message.
>
> Please read the documentation and the FAQ before posting a
> question -- chances
> are it's already been answered.
>
> http://www.proftpd.net -- The Official ProFTPD web site.
> http://bugs.proftpd.net -- Bug reporting and feature requests.
> http://www.proftpd.net/docs/ -- The latest ProFTPD
> documentation and FAQ.
