Representatives of the NetBSD Project has reported a serious vulnerability that has been discovered in File Transfer Protocol (FTP) client used by many Unix-Like (*NIX) Operating systems.

Being fairly old, the tnftp FTP client is found in Red Hat's Fedora , Debian , NetBSD, FreeBSD, OpenBSD, and even Apple's OS X Operating Systems.

A vulnerability has been discovered by Jared McNeill ,who is a software developer at the NetBSD Project, that can be exploited via a malicious Web server to cause tnftp to execute arbitrary commands.The CVE-2014-8517 identifier has been assigned the name to the flaw.

Here's an explanation by Alister Crooks, security officer at the NetBSD Project, as published in an advisory on the Full Disclosure mailing list:

"If you do 'ftp http://server/path/file.txt'; and don't specify an output filename with -o, the ftp program can be tricked into executing arbitrary commands". Further, "The FTP client will follow HTTP redirects, and uses the part of the path after the last / from the last resource it accesses as the output filename (as long as -o is not specified)".

See the advisory here: http://seclists.org/oss-sec/2014/q4/459

Also he added , "After it resolves the output filename, it checks to see if the output filename begins with a "|", and if so, passes the rest to popen(3)".

The list contains Debian, Novell (SuSE Linux), Red Hat, DragonFly, Gentoo, OpenBSD, FreeBSD and Apple operating system that developers appear to be aware of the vulnerability. Out of which each of the following have published advisories for the flaw: Debian, Gentoo, Red Hat, and Novell.

The latest version of Mac Operating System, OS X Yosemite 10.10, has been affected by the tnftp vulnerability. Though the Apple being notified, they showed "cold shoulder" in return , as told by Crooks.

Interesting thing We got to know from Stuart Henderson's answer to Crooks was that, this issue was fixed in OpenBSD some odd 5 years ago.

This is what Stuart Benderson replied to Alister Crooks's post, "I changed OpenBSD's ftp(1) a while ago to just use the 'filename' part of the original request, rather than taking a name from the redirection target (this also matches what curl -O does) - it's a bit less convenient in some cases, but it felt like a bad idea to allow the output filename to be under control of the remote host (though I was more thinking of the situation where someone might run it from their home directory and write to something like .profile)".