Closed
Bug 465
Opened 27 years ago
Closed 15 years ago
FTP PORT (active) command support
Categories
(Core :: Networking: FTP, defect, P3)
Core
Networking: FTP
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
Comment 1•26 years ago
|
||
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Updated•26 years ago
|
Component: NetLib → Networking Library
Product: MozillaClassic → Browser
Updated•26 years ago
|
Target Milestone: M6 → M7
Comment 2•26 years ago
|
||
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.
Updated•26 years ago
|
Target Milestone: M7 → M8
Comment 3•26 years ago
|
||
necko first landing is M8
Comment 4•26 years ago
|
||
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.
Updated•26 years 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. ;-)
Updated•26 years ago
|
Component: Networking-Core → OJI
Summary: Add preference to use PORT ftp instead of PASV ftp → FTP PORT command support
Comment 7•26 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M10 → M14
Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.
Updated•25 years ago
|
Target Milestone: M14 → M16
Comment 11•25 years ago
|
||
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF
bugs
QA Contact: paulmac → tever
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
*** Bug 45126 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
*** Bug 70442 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
Is there an "option" to force necko to use passive ftp?
Comment 19•24 years ago
|
||
*** Bug 70863 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
we will never support PORT. read rfc 2577 for reasons against PORT.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
Comment 23•24 years ago
|
||
SPAM: ccing self
Comment 24•24 years ago
|
||
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.
Comment 25•23 years ago
|
||
*** Bug 100125 has been marked as a duplicate of this bug. ***
Comment 26•23 years ago
|
||
*** Bug 136351 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
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?
Comment 28•23 years ago
|
||
I think someone duped it away recently. I'll try to fix that at some point when
I look at some duplicate prevention...
Comment 29•23 years ago
|
||
a good overview of the problem can be found here:
http://cr.yp.to/ftp/security.html
Comment 30•23 years ago
|
||
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?
Comment 31•23 years ago
|
||
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
Comment 32•23 years ago
|
||
*** Bug 145018 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
*** Bug 145018 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 70442 has been marked as a duplicate of this bug. ***
Comment 35•23 years ago
|
||
*** Bug 73427 has been marked as a duplicate of this bug. ***
Comment 36•23 years ago
|
||
*** Bug 146166 has been marked as a duplicate of this bug. ***
Comment 37•23 years ago
|
||
*** Bug 160688 has been marked as a duplicate of this bug. ***
Comment 38•22 years ago
|
||
*** Bug 177053 has been marked as a duplicate of this bug. ***
Comment 39•22 years ago
|
||
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. :)
Comment 40•22 years ago
|
||
*** Bug 185125 has been marked as a duplicate of this bug. ***
Comment 41•22 years ago
|
||
I found one site that rejects PASV, and it looks like for recent builds, we hang
open and do not error. See bug 197287.
URL: ftp://ftp.sun.com
Keywords: testcase
Comment 42•22 years ago
|
||
*** Bug 199123 has been marked as a duplicate of this bug. ***
Comment 43•22 years ago
|
||
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.
URL: ftp://ftp.sun.com
Keywords: testcase
Comment 44•21 years ago
|
||
*** Bug 232088 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
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
Comment 46•21 years ago
|
||
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
Comment 47•21 years ago
|
||
(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
Comment 48•21 years ago
|
||
*** Bug 212117 has been marked as a duplicate of this bug. ***
Comment 49•20 years ago
|
||
*** Bug 271254 has been marked as a duplicate of this bug. ***
Comment 50•19 years ago
|
||
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).
Comment 51•19 years ago
|
||
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.
Comment 52•19 years ago
|
||
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.
Updated•16 years ago
|
QA Contact: benc → networking.ftp
Comment 54•16 years ago
|
||
Since FireFTP is a solution to this bug, maybe resolve WONTFIX?
Comment 55•15 years ago
|
||
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 ago → 15 years ago
Resolution: --- → WONTFIX
Comment 56•15 years ago
|
||
"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.
Comment 57•15 years ago
|
||
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.
Description
•