This site graciously hosted
by our friends at




Analysis of Topical Vulnerabilities

26 September 2003

Recently, a patch was released concerning a security vulnerability in the popular "wu-ftp" software package. (Wu-ftp is a widely used File Transfer Protocol (FTP) server program.) I looked at the vulnerability itself and think that it presents a fascinating example of why it is so vital to "scrub" all user input. Let's take a closer look...

The vulnerability has a Common Vulnerabilities and Exposures (CVE) id of CVE-1999-0997. It involves a wu-ftp feature whereby a remote user can enter a single command that instructs the server to gather up several files and directories into a single archive file and download that archive to the remote user. Sounds straight forward, right?

Well, the problem comes in due to the fact that wu-ftp did not adequately screen the user's input line to ensure that the command was properly formed and that it contained no unauthorized data. It turns out that a maliciously-inclined user (read "attacker") could issue a command to the wu-ftp daemon that would pass an arbitrary command to the downstream archiving program -- in this case, GNU Tar. The result was that an attacker could get the GNU Tar program to execute an arbitrary command on his behalf, and that command would in turn be executed with the same privileges that the wu-ftp daemon program runs under -- usually root, daemon, or similar.

What makes this vulnerability particularly fascinating, from my standpoint, is that it perfectly illustrates a cascading effect of misplaced trust. You see, the wu-ftp daemon program would execute another program (tar) on its behalf. That program, which had no knowledge of where it was being called from or by whom, correctly interpreted its "user's" command and faithfully executed its command line. The responsibility of screening the user's input was in the upstream program, wu-ftp. Thus, a flaw in wu-ftp was cascaded down to the tar program, complete with the privileges of the wu-ftp process.

Of course, we've all seen this sort of thing many times in the past. The issue of SQL insertion is conceptually identical to this, in fact. But that's another story for another time...

For this story, the moral that I see is that it is (yet again) absolutely vital to treat a user's input as potentially malicious until *proven* otherwise. This issue of "scrubbing" a user's input data is not a trivial one at all, and there are untold opportunities for making mistakes. That being said, though, it is absolutely vital to pay close attention to this problem.

Cheers,

Kenneth R. van Wyk
26 September 2003

Copyright (C) 2003, Mark G. Graff and Kenneth R. van Wyk. Permission granted to reproduce and distribute in entirety with credit to authors.


Site Contents Copyright (C) 2002, 2003 Mark G. Graff and Kenneth R. van Wyk. All Rights Reserved.
webmaster@securecoding.org