5 ms·

MacOS X 10.10 and FreeBSD 10 Ftp Remote Comand Execution

113 points by thefreeman 12y ago

fyolnish 12y ago
What possible reason could the authors have had to pass everything following a pipe into popen? Did they think they were writing a shell?
- deleted 12y ago
  [deleted]
- kps 12y ago
  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 12y ago
    Very reminiscent of Shellshock, actually. Never treat data as code unless very explicitly told to.
- ams6110 12y ago
  Interactive ftp is a shell, for file transfer operations.
lelf 12y ago
Note that it’s in the ftp client.
- astrodust 12y ago
  Yeah, and I've used that exactly never. Whew.
  - kalleboo 12y ago
    Not to mention, use it for HTTP...
    - userbinator 12y ago
      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.
      - dmm 12y ago
        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
        Wilya 12y ago
        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.
        glass- 12y ago
        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/fetch.c#rev1.96 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/fet... http://marc.info/?l=openbsd-cvs&m=125128957525639&w=2 http://marc.info/?l=openbsd-cvs&m=125128957525639&w=2
astrange 12y ago
An entirely different RCE in wget today: https://community.rapid7.com/community/metasploit/blog/2014/10/28/r7-2014-15-gnu-wget-ftp-symlink-arbitrary-filesystem-access https://community.rapid7.com/community/metasploit/blog/2014/...
- smutticus 12y ago
  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.
marcopolis 12y ago
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 12y ago
  It was rewritten from scratch in Vista.
  - fredoralive 12y ago
    The Windows 7 version of ftp.exe still has a University of California copyright string buried inside it...
    - pjmlp 12y ago
      So it seems. Well, I was just stating the information I had.
iuguy 12y ago
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
101914 12y ago
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.

113 points by thefreeman 12y ago

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

deleted 12y ago
[deleted]
kps 12y ago
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 12y ago
  Very reminiscent of Shellshock, actually. Never treat data as code unless very explicitly told to.
ams6110 12y ago
Interactive ftp is a shell, for file transfer operations.

lelf 12y ago

Note that it’s in the ftp client.

astrodust 12y ago
Yeah, and I've used that exactly never. Whew.
- kalleboo 12y ago
  Not to mention, use it for HTTP...
  - userbinator 12y ago
    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.
    - dmm 12y ago
      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
      - Wilya 12y ago
        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.
      - glass- 12y ago
        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/fetch.c#rev1.96 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/fet... http://marc.info/?l=openbsd-cvs&m=125128957525639&w=2 http://marc.info/?l=openbsd-cvs&m=125128957525639&w=2

astrange 12y ago

An entirely different RCE in wget today: https://community.rapid7.com/community/metasploit/blog/2014/10/28/r7-2014-15-gnu-wget-ftp-symlink-arbitrary-filesystem-access https://community.rapid7.com/community/metasploit/blog/2014/...

smutticus 12y ago
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.

marcopolis 12y ago

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 12y ago
It was rewritten from scratch in Vista.
- fredoralive 12y ago
  The Windows 7 version of ftp.exe still has a University of California copyright string buried inside it...
  - pjmlp 12y ago
    So it seems. Well, I was just stating the information I had.

iuguy 12y ago

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

101914 12y ago

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.