Bugzilla – Bug 64572
VUL-0: CVE-2005-0372: directory traversal bug in gftp
Last modified: 2021-11-02 16:06:16 UTC
We received the following report via full-disclosure. This issue is not public yet, please keep any information about it inside SUSE. The reporter talks about IE but gftp has the same bug. Date: Thu, 30 Dec 2004 15:56:41 +0100 From: Albert Puigsech Galicia <ripe@7a69ezine.org> To: bugtraq@securityfocus.com Subject: 7a69Adv#17 - Internet Explorer FTP download path disclosure Reply-To: ripe@7a69ezine.org User-Agent: KMail/1.7.1 <NOTE FOR BUGTRAQ MODERATOR> Excuseme if you have recibed this mail reapeated, but I had some problems on my mail server some days ago, and I have sent this mail 3 or 4 times. Sorry :) Delete this note to post to the list. Thank's you. </NOTE FOR BUGTRAQ MODERATOR> - ------------------------------------------------------------------ 7a69ezine Advisories 7a69Adv#17 - ------------------------------------------------------------------ http://www.7a69ezine.org [23/12/2004] - ------------------------------------------------------------------ Title: Internet Explorer FTP download path disclosure Author: Albert Puigsech Galicia - <ripe@7a69ezine.org> Software: Microsoft Internet Explorer Versions: >= 6.0.3790.0 Remote: yes Exploit: yes Severity: Medium-High - ------------------------------------------------------------------ I. Introduction. Internet Explorer is a well-known HTTP browser, and like others it can use more protocols, for example FTP. The security historial of this navigator is really cool and we are glad for the excelent work done by Microsoft. We love your (in)security features. II. Description. When you save a file from an FTP server to a local folder it is saved on 'local_folder/file_name', consequently if the name of the file contains '../', the real destination of the file changes. Despite it is imposible to create a file with '../' characters an FTP server can reply a LIST request with this char on filenames, so a malicious FTP server can modify the folder where the downloaded file will be stored. Of the three possible ways of downloading a file only two are affected by this bug; the left-click and save-as procedure and dragging the file. The one that is unaffected is the double-click procedure. III. Exploit You can use the very-tiny and malicious FTP server attached in this mail to check the vulnerability. It's easy to use './ftpd-iexpl localfile remotefile', where localfile is a file on the FTP server and localfile is the path where the will be stored on the attacked system. If you try to overwrite a file the Internet Explorer show a confirmation message, so is better for explotation purposes to create new files, but It's not a problem to execute arbitrari code because you can create, for example, startup files on 'C: \Documents and settings\All Users\Start menu\Programs\Start' that will be executed after next user login. However Internet Explorer shows the complete name of the file, including the '../' characters so It's unlikely that it will not arise suspicions, but you can put the malicious file into a FTP folder and waiting for victim dragging the folder. IV. Patch Don't use Internet Explorer and turn to Firefox world. V. Timeline 06/12/2004 - Bug discovered 23/12/2004 - Advisor released 25/12/2004 - Noel; uoh! ouh! ouh! VI. Extra data You can find more 7a69ezine advisories on this following link: http://www.7a69ezine.org/avisos/propios [spanish info]
Created attachment 27358 [details] sample malicious ftp server modified version of the reporter's ftp server. run e.g. ./ftpd-iexpl /etc/motd /tmp/foo and connect on localhost:2121. Click on the left arrow to download the file into your home and find yourself having /tmp/foo instead.
Working on patch.
What's the plan to 'fix' it? Looks like other ftp clients either don't display such files at all or don't allow to do anything useful with it. Are you in contact with upstream?
I wanted to save it as strrchr ("/", filename). Another problem of gftp is, that file exist check for this file is negative, even if destination file exists. Not yet in contact with upstream. Should I contact author in private mail or is author already informed? (Brian Masney <masneyb@gftp.org>).
Bug for IE is public: http://secunia.com/advisories/13704/
* This comment was added by mail. Yes, please contact the upstream author. I'll notify vendor-sec.
The IE stuff is public, yes. It came via full-disclosure and gets quite some public attention (see www.heise.de).
From Brian Masney <masneyb@gftp.org>: I was already notified about this. To fix this, I plan on running strrchr() on the filename in the *_get_next_file() functions. I will do this in lib/rfc959.c, lib/sshv2.c and lib/fsp.c (not in CVS yet). In lib/rfc2068.c, files that have a .. in them will generate a warning and they will be ignored. I am planning on releasing 2.0.18 by the 15th. I am leaving this evening for Alabama to go caving underground and I won't be back in town until Sunday night. Brian
swampid: 103
any news?
Author did not release promised update. I will look at code and try to write a fix.
Created attachment 27732 [details] gftp-directory-traversal.patch Draft of the patch. The patch has one drawback - it cannot download file containing '/' from server (with exception of proof of concept server), because it sanitizes also GET string. Fixing this will require duplication of file item to safe_file_name and server_file_name. Another solution is skipping such files at all or mangling file names as "ALERT...". Yet another solution is revertable sanitizing using % notation for these strings.
Created attachment 27767 [details] gftp-path.patch From Brian Masney <masneyb@gftp.org> To: Stanislav Brabec <sbrabec@suse.cz> Subject: Re: security: Directory traversal bug in gftp Hi, Here is the patch that I commited to CVS a little bit ago. I added the necessary checks to gftp_get_next_file(). gftp_parse_ls() is not used by all protocols, namely it isn't used by the SSH and FSP protocols. Let me know if you run into any problems with this patch. I also have my latest CVS code online at http://www.gftp.org/gftp-test.tar.bz2 (MD5SUM 5182d34745a43cf1e5b045e860485083) Brian
Created attachment 27768 [details] gftp-path-backport.patch There is a problem: The fix works with proof of concept FTP server, but does not work with servers with real files - it sends RETR /foo, not RETR /../../../../../../../../../../../tmp/foo. I don't know FTP standard. Is such file legal? If not, we can ignore it.
* This comment was added by mail. I don't know. I think it's pretty much not standardized. Other ftp clients don't show such a file at all so who cares as long as it doesn't overwrite files it shouldn't :-)
Fix submitted for 8.1, 8.2, 9.0, 9.1, 9.2, SLES9-SLD, STABLE and PLUS.
CAN-2005-0372
packages released
CVE-2005-0372: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:P/I:N/A:N)