[ Search ] [ What's New? ] [ About ]
[ Bugs ] [ Misc ] [ Mailing Lists ] [ Newgroups ] [ NewsWire ] [ Papers ] [ People ]
[ Pictures ] [ Publications ] [ Responce Teams ] [ Tools ] [ Upcoming Events ] [ Web Sites ]

In its original form, the vulnerability was not enabled by default. However, certain distributions of Linux contain a wu.ftpd that has been compiled with a vulnerable configuration. This vulnerable configuration is distributed and run by default.

Non-Linux systems running wu-ftpd should also be checked to determine if the configuration is vulnerable. The pre-compiled binaries shipped for Linux Slackware distributions are vulnerable. The variable _PATH_EXECPATH has been set to "/bin" in the configuration file src/pathnames.h when the distribution binary was built. _PATH_EXECPATH should be set to "/bin/ftp-exec" or a similar directory that does not contain a shell or command interpreter. The source code shipped with the Linux distributions contains the correct value ("/bin/ftp-exec") (which should be verified before recompiling), despite the incorrect distribution binary. The documentation states that the directory defined by _PATH_EXECPATH is relative to ~ftp. This is misleading. The pathname is relative to ~ftp for anonymous users only. It is relative to "/" for normal user sessions.

To test your configuration to see if you are vulnerable, you can execute the following commands:

srchost> ftp ftphost
Connected to ftphost

220 ftphost FTP server (Version wu-2.4(2) Mon Apr 18 09:12:35 GMT+1000 1994) ready.

Name (srchost:user):

331 Password required for user.

Password:

230 User user logged in.

ftp> quote site exec echo problem

200-echo problem

200-problem

200  (end of 'echo problem')

ftp> quit

221 Goodbye.

If you receive the line "200-problem", then your site is vulnerable. Note that this does not work for anonymous ftp access, or for all vulnerable configurations.

Anonymous users may also gain root access but certain criteria must be meet. This include: 1) The site must have GNU tar in the SITE EXECable directory. 2) There must be a world writable directory for the attaker to upload a file. 3) The site must not disable chmod. The core of the problem is that the site exec command does not reset the real uid before executing a command. Thus, all commands are executed with real uid/gid of 0.

The way to exploit this problem is to compile a small program that does a seteuid(0), calls chmod(0755, "/bin/ftp-exec") and copies its standard input to stdout. You upload this to /incoming along with a tar archive of your favorite tools (including e.g. a statically linked xterm and bash), chmod the program to 0755 with `site chmod', go to /bin/ftp-exec and invoke tar with the following options:

site exec tar --use-compress-program /incoming/hackme -xf /incoming/tools.tar

This unpacks all your tools into /bin/ftp-exec. From then on, all you have to do is execute xterm to get shell access to the FTP area and break out of the chroot jail (possibly using rlogin to another host on the target machine's LAN, or by accessing the hard disk directly).

diku-ftp does not have this problem.

wu-ftpd 2.4 source code: The correctly configured wu-ftpd 2.4 server for Linux can be obtained at the following URLs:

ftp://linux.nrao.edu/pub/people/alex/wu-ftpd-2.4-fix/

In addition to the source code of patched wu-ftpd 2.4 you can get the patch that would create a "fixed" tree from the original wu-ftpd 2.4 and the wu-ftpd 2.4 itself. All files have their MD5 checksums in the file CHECKSUMS in the same directory.