Closed Bug 465 Opened 27 years ago Closed 15 years ago

FTP PORT (active) command support

Categories

(Core :: Networking: FTP, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: cls, Unassigned)

References

Details

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
Status: NEW → ASSIGNED
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Component: NetLib → Networking Library
Product: MozillaClassic → Browser
Assignee: gagan → valeski
Status: ASSIGNED → NEW
Target Milestone: M6
Target Milestone: M6 → M7
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.
Target Milestone: M7 → M8
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.
Target Milestone: M8 → M10
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. ;-)
Depends on: 4320
Blocks: 12834
Component: Networking-Core → OJI
Summary: Add preference to use PORT ftp instead of PASV ftp → FTP PORT command support
changing summary from: "Add preference to use PORT ftp instead of PASV"
No longer blocks: 12834
Assignee: valeski → gagan
Component: OJI → Networking-Core
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.
Assignee: gagan → valeski
Target Milestone: M10 → M14
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
Target Milestone: M14 → M16
Moving to M17 (also beta2).
Target Milestone: M16 → M17
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF bugs
QA Contact: paulmac → tever
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!
Assignee: valeski → rjc
can't make it for nsbeta3.
Target Milestone: M17 → Future
Hi dougt, welcome to necko :)
Assignee: rjc → dougt
Blocks: 62355
*** 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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → VERIFIED
Component: Networking → Networking: FTP
Keywords: relnote
QA Contact: tever → benc
Summary: FTP PORT command support → FTP PORT (active) command support
Target Milestone: Future → mozilla1.0
>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
Depends on: 92928
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Target Milestone: mozilla1.0 → Future
*** 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. ***
Blocks: 136351
*** Bug 146166 has been marked as a duplicate of this bug. ***
*** Bug 160688 has been marked as a duplicate of this bug. ***
Blocks: 140253
*** 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.
Keywords: relnote
*** 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.
Severity: enhancement → normal
(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.
Assignee: dougt → nobody
Status: REOPENED → NEW
QA Contact: benc → networking.ftp
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.
Status: NEW → RESOLVED
Closed: 24 years ago15 years ago
Resolution: --- → WONTFIX
"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.
You need to log in before you can comment on or make changes to this bug.