COMMAND
proftpd
SYSTEMS AFFECTED
Proftpd 1.2 (includinf RC1)
PROBLEM
Carlos Eduardo Gorges found several bugs in all the versions of
proftp (tested in proftp 1.2.0pre6, proftp 1.2.0pre10 and proftp
1.2.0rc1). All involve parse of characters, for example, connects
in a proftpd host and
ftp> quote %999s
Voyala! The children stops in segfail.
That is not quite as simple as it appears. Witness (server text
indented for clarity):
drow:~% nc -v 0 21
0: inverse host lookup failed: Unknown host
(UNKNOWN) [0.0.0.0] 21 (ftp) open
220 ProFTPD 1.2.0pre9 Server (ProFTPD) [hostname]
USER ftp
331 Anonymous login ok, send your complete e-mail address as password.
PASS dan@
230-Welcome, archive user ftp@hostname !
230-
230-The local time is: Tue Jul 25 15:19:50 2000
230-
230-This is an experimental FTP server. If have any unusual problems,
230-please report them via e-mail to <root@hostname>.
230-
230 Anonymous access granted, restrictions apply.
%999s
500 %999S not understood.
Vs:
drow@quaketop:~% socksify ftp hostname
Connected to hostname.
220 ProFTPD 1.2.0pre9 Server (ProFTPD) [hostname]
Name (hostname:drow): ftp
331 Anonymous login ok, send your complete e-mail address as password.
Password:
230-Welcome, archive user ftp@hostname !
230-
230-The local time is: Tue Jul 25 15:23:07 2000
230-
230-This is an experimental FTP server. If have any unusual problems,
230-please report them via e-mail to <root@hostname>.
230-
230 Anonymous access granted, restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote %999s
421 Service not available, remote server has closed connection
What's the difference, you ask? FTP is vulnerable to mishandling
% characters also. The format string gets expanded by the
client. This is something different than a format string bug.
In fact, from examination, it appears to be a bug of a whole
different class - a "paper bag" bug. A command of " " works just
as well. If the command is entirely (or far enough for ProFTPd
to discard the rest of it for safety, about 512 chars) blank, then
make_cmd will set newcmd->argv[0] to null, and dispatch_cmd will
try to dereference it. Embarrassing, maybe, but NOT A SECURITY
HOLE.
SOLUTION
Let's repeat that to get it perfectly clear: this is NOT A
SECURITY HOLE IN PROFTPD. It's not even a denial of service,
since only the forked child crashes. It produces disturbing
warnings in proftpd's log, but nothing more harmful than that.
It is fixed now.
For FreeBSD:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/ftp/proftpd-1.2.0rc2.tgz
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/ftp/proftpd-1.2.0rc2.tgz