I posted this in a conversation in /r/netsec today as well. I don't agree that this is a bug. I'm all for having a discussion about whether this is a bug or not. I just hope that before the wget developers change anything they engage with those people who prefer this behavior.
This is a mirror operation, it's not the standard use of wget where we just download from an untrusted website. If I'm mirroring something I expect everything to copy.
Imagine a situation where I'm mirroring something for the purposes of backup. The original site goes down, and I need to restore from the mirrored copy I made with wget. In this instance I want those symlinks to be present. I want everything.
-m
--mirror
Turn on options suitable for mirroring. This option turns on recursion and time-stamping, sets infinite recursion depth and keeps FTP directory
listings. It is currently equivalent to -r -N -l inf --no-remove-listing.
--no-remove-listing
Don't remove the temporary .listing files generated by FTP retrievals. Normally, these files contain the raw directory listings received from
FTP servers. Not removing them can be useful for debugging purposes, or when you want to be able to easily check on the contents of remote
server directories (e.g. to verify that a mirror you're running is complete).
Note that even though Wget writes to a known filename for this file, this is not a security hole in the scenario of a user making .listing a
symbolic link to /etc/passwd or something and asking "root" to run Wget in his or her directory. Depending on the options used, either Wget will
refuse to write to .listing, making the globbing/recursion/time-stamping operation fail, or the symbolic link will be deleted and replaced with
the actual .listing file, or the listing will be written to a .listing.number file.
Even though this situation isn't a problem, though, "root" should never run Wget in a non-trusted user's directory. A user could do something as
simple as linking index.html to /etc/passwd and asking "root" to run Wget with -N or -r so the file will be overwritten.
I did a quick scan of libfetch (fetch(3)) and it seems clean. Thats sort of interesting to me because I've wondered for some time why ftp does not actually use libfetch. Can't say whether ftp not sharing the libfetch code is good or bad, in this case.
I bet a huge number of the population who has used the FTP client has never used it for HTTP because... using an FTP client for HTTP just doesn't make sense.
In OpenBSD the ftp(1) program /is/ the cli http client for the base system. wget is available in ports but not install by default. FreeBSD is probably similar
The wget-like utility present in the FreeBSD base system is fetch(1). It is a cli for the underlying libfetch, which provides HTTP/FTP client functions, and is used behind the scenes in a lot of places in the FreeBSD base, notably by all the package manager and ports systems.
The vulnerable ftp we're talking about here is a completely distinct piece of software, which is generally used only when you want to interactively browse a ftp server. But it doesn't seem to be related much to fetch(1). It has obviously common origins with the OpenBSD one, but I can't comment on how vulnerable the OpenBSD version is.
When you're using ftp interactively, at the 'ftp>' prompt, you can optionally supply a local file name to the 'get' command,
get remote-file [local-file]
and that local-file can begin with a '|' to indicate that you want the remote file piped to a command, e.g.
get README |less
Apparently this handling of the interactive local file name was mistakenly applied to local files names derived from remote file names after an HTTP redirect from the command line.
(Incidentally the interactive modes of ftp and telnet, with their 'command>' prompts, are the last vestiges in unix of TENEX on the ARPANET.)
This ftp is otherwise known as tnftp and originates with NetBSD.
It is part of their base install and is the only ftp/http client installed by default. It is the default client for installing packages.
Aside from the popen feature (-o"|utility" pipes output to utility), getting this program to segfault is quite easy. If you are concerned about security I would seek a workaround that you trust.
tnftp does not link to libfetch, but on NetBSD libfetch is still present (why? I am not sure), so a user could install fetch(1), the default ftp/http client from FreeBSD, which is available as a package, and it will work "out of the box". FreeBSD's fetch(1) does link to libfetch.
There is also example code for a libfetch-linked client in the NetBSD source tree.
Whether the fetch(1) client has security issues of it own, I do not know, but at least it does not implement the popen feature.
https://community.rapid7.com/community/metasploit/blog/2014/...