

MacOS X 10.10 and FreeBSD 10 Ftp Remote Comand Execution - thefreeman
http://cxsecurity.com/issue/WLB-2014100174

======
astrange
An entirely different RCE in wget today:

[https://community.rapid7.com/community/metasploit/blog/2014/...](https://community.rapid7.com/community/metasploit/blog/2014/10/28/r7-2014-15-gnu-
wget-ftp-symlink-arbitrary-filesystem-access)

~~~
smutticus
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.

------
lelf
Note that it’s in the ftp _client_.

~~~
astrodust
Yeah, and I've used that exactly _never_. Whew.

~~~
bch
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.

~~~
cperciva
_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.

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

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

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

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

[http://everything2.com/title/BSD+Code+in+Windows](http://everything2.com/title/BSD+Code+in+Windows)

~~~
pjmlp
It was rewritten from scratch in Vista.

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

~~~
pjmlp
So it seems.

Well, I was just stating the information I had.

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

------
iuguy
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](http://lab.dreamcats.org/ftp_exp.py)

