Created by Christopher Seawood (cls@seawood.org) on Tuesday, June 30, 1998 10:25:16 AM PDT Additional Details : I noticed the function call NET_UsePASV(bool) already exists in network/protocol/ftp/mkftp.c but nobody uses it. As my firewall does not let any random high port connection through, using the ftp feature of Netscape/Mozilla hangs. Updated by (aoki@netscape.com) on Monday, August 17, 1998 9:31:39 AM PDT Additional Details : This would be a netlib issue. Reassigning to gagan

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

I am setting the Target Milestone to M7, since I am assuming that the landing of the Necko code will need to take place before this enhancement can be seriously considered.

necko first landing is M8

netlib tries pasv and port commands. if one fails, the other is attempted. you can get into a deadlock scenario if your firewall doesn't allow incomming connections on the pasv port, and the ftp server you're trying to connect to doesn't allow incomming data connections (very rare case). are you unable to connection to _any_ ftp servers? note: PORT will not be supported in necko until nspr server sockets are supported XP, and the socket transport reflects this.

This enhancement is no longer relevant for me. I don't recall netlib trying port after pasv failed but that was almost a year ago.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

changing summary from: "Add preference to use PORT ftp instead of PASV"

This appears to be a networking bug, not an OJI bug. I wonder if it got mis-assigned at some point? I hope I'm sending this bug off to the right place, since I don't see any mention of Java or OJI here.

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.

Moving to M17 (also beta2).

spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF bugs

after giving this some more thought, we're going to have to modify the socket transport such that it can wait for a connection (server mode). currently this isn't supported at all.

*** Bug 45126 has been marked as a duplicate of this bug. ***

robert-- welcome to necko!

can't make it for nsbeta3.

Hi dougt, welcome to necko :)

*** Bug 70442 has been marked as a duplicate of this bug. ***

Is there an "option" to force necko to use passive ftp?

*** Bug 70863 has been marked as a duplicate of this bug. ***

we will never support PORT. read rfc 2577 for reasons against PORT.

qa to me. -> ftp updated summary for searchability set milestone to 1.0 +relnote VERIFIED: this won't be fixed before Mozilla 1.0, so I'll have it release noted. I'm going to convert a duplicate (bug 7342) to a futured RFE.

>VERIFIED: >this won't be fixed before Mozilla 1.0, so I'll have it release noted. >I'm going to convert a duplicate (bug 7342) to a futured RFE Benjamin you mean bug 70442? Or some other bug?

SPAM: ccing self

RELNOTE NS 6.1: Active FTP (PORT) connections are not supported in this version. You will not be able to connect to Active-only FTP servers.

*** Bug 100125 has been marked as a duplicate of this bug. ***

*** Bug 136351 has been marked as a duplicate of this bug. ***

Doug: I read (very) quickly RFC 2577 <http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/25xx/2577> and I found just reasons for server side to don't support/disable PORT command. Could you point me to a parts relevant for this bug? Benjamin Chuang: What is number of futured RFE which you promised in comment 21?

I think someone duped it away recently. I'll try to fix that at some point when I look at some duplicate prevention...

a good overview of the problem can be found here: http://cr.yp.to/ftp/security.html

Doug, thanx for link, I suppose, that you mean part starting with 'After a client sends PORT, an attacker can connect to the client's TCP port before the server does.' With this info sounds your verdict very reasonable. Are available any numbers about count of running FTP servers which can not handle passive connections? If this number is about 5% and bigger, will be IMHO better for users if developers support this 'obsoled' connection. It could be enabled only via Preferences with big disclaimer about security impact. If you and other developers still think, that there is no way to implement this, is possible to inform user, that he have to use other programm and why, when FTP connection fails because FTP server doesn't support passive connection?

okay. maybe i was too hard on this feature. When 92928 lands, I will make this work with the condition that it will be disabled via a pref, and when enabled there is some dialog that asserts the associated risk.

*** Bug 145018 has been marked as a duplicate of this bug. ***

*** Bug 145018 has been marked as a duplicate of this bug. ***

*** Bug 70442 has been marked as a duplicate of this bug. ***

*** Bug 73427 has been marked as a duplicate of this bug. ***

*** Bug 146166 has been marked as a duplicate of this bug. ***

*** Bug 160688 has been marked as a duplicate of this bug. ***

*** Bug 177053 has been marked as a duplicate of this bug. ***

I'm not sure I see the threat here. Please point out anything I've overlooked. From the web page linked above, the main aspect of the problem is summarized this way: "After a client sends PORT, an attacker can connect to the client's TCP port before the server does." I don't see how that could happen... since it's TCP, the attacker can't simply send a small malicious file in a single packet and the victim won't fully establish a TCP connection with the attacker (unless the attacker has assumed the IP of the ftp server and is blocking the ftp server's traffic to the victim in which case the attacker can do anything they could do anything they want even without the victim using PORT). Provided Moz is smart enough to only accept connections that originate from the same IP that the PORT command was sent to, we should be safe from that part, right? Next point they make: "Connection Laundering". This would seem to be pretty close to impossible to pull off. The first hinderance is that the ftp server has to allow PORTs to a 3rd party (don't most disable that now?). What really makes this hard is that the attacker has to see the victim's PORT, and somehow send a PORT to the same ftp server and get it to reply to the victim using the attacker's PORT command *before* it processes the reply to the victim's own PORT command (which had a head start). Granted that under heavy network load and high CPU usage, it's within the realm of possibility, but it's based on an unlikely roll of chance under unusualy circumstances on a poorly configured server. The third thing the mention is the case where the attacker and victim are on the same multi-user system. I don't see how this makes it any easier for the attacker unless the attacker is root. If the attacker is root (rightfully or otherwise), the victim won't be protected by running a PASV ftp client. If there's something that I've overlooked that does present a real security concern, please point it out so I can revise my thinking. Having said all that, I have no personal interest in active ftp, passive works just fine for me. :)

*** Bug 185125 has been marked as a duplicate of this bug. ***

I found one site that rejects PASV, and it looks like for recent builds, we hang open and do not error. See bug 197287.

*** Bug 199123 has been marked as a duplicate of this bug. ***

According to the FTP message, ftp.sun.com will no longer be available starting sometime in July. Not to mention the fact that is says explicit permission is required to access that server. Removing from URL; Removing testcase keyword.

*** Bug 232088 has been marked as a duplicate of this bug. ***

I really this the priority of this bug should be increased from "enhancement", to "normal", or even "major". > This is not an "enhancement request". FTP handling does not adhere to the published RFCs.... FTP sites are not REQUIRED to support passive mode. > Since FTP handling is broken, I think this should be raised to "major". > Don Russell

Don, severity in this bug report doesn't matter much. To avoid squabbling I will make the severity normal -- there are worse bugs. Now, there are arguments for and against _supporting_ PORT. Many experts suggest that client should _not_ support PORT for obvious reasons. See D. J. Bernstein ftp security page at http://cr.yp.to/ftp/security.html.

(In reply to comment #46) > Don, severity in this bug report doesn't matter much. To avoid squabbling I > will make the severity normal -- there are worse bugs. > Now, there are arguments for and against _supporting_ PORT. Many experts > suggest that client should _not_ support PORT for obvious reasons. See D. J. > Bernstein ftp security page at http://cr.yp.to/ftp/security.html. Perhaps I've misunderstood THIS bug. I originally entered http://bugzilla.mozilla.org/show_bug.cgi?id=232088 which was then marked as a duplicate of this one. Perhaps THAT diagnosis is incorrect, and 232088 needs to be fixed. Thanks, Don

*** Bug 212117 has been marked as a duplicate of this bug. ***

*** Bug 271254 has been marked as a duplicate of this bug. ***

How complecated to make an option for that? Can Ff's extension hook on opening of FTP link? One thing is when you want both PORT and PASV working for cleanness sake. Another thing is my broken corporate firewall which requires PORT but reports no error for PASV. Since PASV is default one (obviously) - ftp downloads in browsers never really work over here. What I'm trying to say: please look at the problem not only from philosophical point of view (e.g. comment #46) but also from technical pov: some firewall support only PORT/active ftp (bug #136351).

I am here for that very reason. Last week our network admins shut off passive FTP access to the outside world for our 80,000+ node network. Now Firefox is useless for FTP. Of course IE has the option to use either active or passive.

Try FireFTP Ff extension. It has passive/active option. P.S. It doesn't work for me since due to other Ff bugs it can't international filenames. And I need them all the time.

mass reassigning to nobody.

Since FireFTP is a solution to this bug, maybe resolve WONTFIX?

Given that active FTP is pretty much a legacy technology and won't pass through most common NATs/firewalls without custom configuration, I think this is WONTFIX and is up to extensions to provide support through server sockets if desired.

"Given that active FTP is pretty much a legacy technology and won't pass through most common NATs/firewalls without custom configuration [...]" ... I'm not sure what planet you live on. Definitely not on the Earth. Most (if not all) corporate firewalls allow FTP. It's preconfigured by default and remains fastest way to transfer huge files around. Only *once* (in small private company) I have seen a firewall which was allowing SSH/SFTP/SCP.

He was talking about *active* FTP, not the vastly more common (and supported by Firefox) *passive* FTP.