FTP PORT (active) command support

RESOLVED WONTFIX

Status

()

Core
Networking: FTP
P3
normal
RESOLVED WONTFIX
20 years ago
4 years ago

People

(Reporter: cls, Unassigned)

Tracking

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
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

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 1

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

Updated

19 years ago
Component: NetLib → Networking Library
Product: MozillaClassic → Browser

Updated

19 years ago
Assignee: gagan → valeski
Status: ASSIGNED → NEW
Target Milestone: M6

Updated

19 years ago
Target Milestone: M6 → M7

Comment 2

19 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

19 years ago
Target Milestone: M7 → M8

Comment 3

19 years ago
necko first landing is M8

Comment 4

19 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.
(Reporter)

Comment 5

19 years ago
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

19 years ago
Target Milestone: M8 → M10

Comment 6

19 years 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. ;-)

Updated

19 years ago
Depends on: 4320

Updated

19 years ago
Blocks: 12834

Updated

19 years ago
Component: Networking-Core → OJI
Summary: Add preference to use PORT ftp instead of PASV ftp → FTP PORT command support

Comment 7

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

Updated

19 years ago
No longer blocks: 12834

Updated

19 years ago
Assignee: valeski → gagan
Component: OJI → Networking-Core

Comment 8

19 years ago
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

19 years ago
Assignee: gagan → valeski

Updated

19 years ago
Target Milestone: M10 → M14

Comment 9

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

Updated

18 years ago
Target Milestone: M14 → M16

Comment 10

18 years ago
Moving to M17 (also beta2).
Target Milestone: M16 → M17

Comment 11

18 years ago
spam, changing qa contact from paulmac to tever@netscape.com on networking/RDF 
bugs
QA Contact: paulmac → tever

Comment 12

18 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

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

Comment 14

18 years ago
robert-- welcome to necko!
Assignee: valeski → rjc

Comment 15

18 years ago
can't make it for nsbeta3. 
Target Milestone: M17 → Future

Comment 16

18 years ago
Hi dougt, welcome to necko :)
Assignee: rjc → dougt

Updated

18 years ago
Blocks: 62355
*** Bug 70442 has been marked as a duplicate of this bug. ***

Comment 18

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

Comment 19

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

Comment 20

17 years ago
we will never support PORT.  read rfc 2577 for reasons against PORT.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 21

17 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

17 years ago
>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?

Comment 23

17 years ago
SPAM: ccing self

Updated

17 years ago
Depends on: 92928

Comment 24

17 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.
*** Bug 100125 has been marked as a duplicate of this bug. ***
*** Bug 136351 has been marked as a duplicate of this bug. ***

Comment 27

16 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

16 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

16 years ago
a good overview of the problem can be found here:

http://cr.yp.to/ftp/security.html

Comment 30

16 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

16 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
*** Bug 145018 has been marked as a duplicate of this bug. ***
*** Bug 145018 has been marked as a duplicate of this bug. ***

Comment 34

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

Comment 35

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

Updated

16 years ago
Blocks: 136351

Comment 36

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

Comment 37

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

Updated

16 years ago
Blocks: 140253

Comment 38

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

Comment 39

16 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. :)
*** Bug 185125 has been marked as a duplicate of this bug. ***

Comment 41

15 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.
Keywords: testcase
*** Bug 199123 has been marked as a duplicate of this bug. ***

Comment 43

15 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.
Keywords: testcase

Updated

14 years ago
Keywords: relnote

Comment 44

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

Comment 45

14 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

14 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

14 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

14 years ago
*** 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).

Comment 51

12 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.
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.

Comment 53

11 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
Status: REOPENED → NEW

Updated

9 years ago
QA Contact: benc → networking.ftp

Comment 54

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

Comment 55

9 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
Last Resolved: 17 years ago9 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.