MacOS X 10.10 and FreeBSD 10 Ftp Remote Comand Execution | Hacker News Reader

MacOS X 10.10 and FreeBSD 10 Ftp Remote Comand Execution

cxsecurity.com

113 pointsthefreeman22 comments

An entirely different RCE in wget today:

https://community.rapid7.com/community/metasploit/blog/2014/...

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.

Note that it’s in the ftp client.

Yeah, and I've used that exactly never. Whew.

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've wondered for some time why ftp does not actually use libfetch

Because ftp(1) was written long before libfetch(3), and nobody wanted to rewrite it.

Why would this be down-voted? I take it you are not supposed to wonder or ask anything on HN?

If not, looks like the mods need to hand out some infractions to these down-vote happy morons.

Not to mention, use it for HTTP...

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.

As an aside, this bug was fixed in OpenBSD's ftp(1) 5 years ago.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/fet...

http://marc.info/?l=openbsd-cvs&m=125128957525639&w=2

What possible reason could the authors have had to pass everything following a pipe into popen? Did they think they were writing a shell?

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.)

Very reminiscent of Shellshock, actually. Never treat data as code unless very explicitly told to.

Interactive ftp is a shell, for file transfer operations.

Interestingly, Windows' ftp.exe is BSD-derived also:

http://everything2.com/title/BSD+Code+in+Windows

It was rewritten from scratch in Vista.

The Windows 7 version of ftp.exe still has a University of California copyright string buried inside it...

So it seems.

Well, I was just stating the information I had.

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.

The exploit mechanism is a bit dodgy in TFA, so I wrote a proof of concept exploit using python for testing systems[1].

[1] - http://lab.dreamcats.org/ftp_exp.py

Reply on news.ycombinator.com