392635 - transparent wccp proxy ftp broken due to FTP PASV command security patch

Status: RESOLVED WONTFIX

(Core Graveyard :: Networking: FTP, defect)

Description

[Michael Krivacek]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070813 Fedora/2.0.0.6-3.fc8 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070813 Fedora/2.0.0.6-3.fc8 Firefox/2.0.0.6

"Bug 370559 (CVE-2007-1562) – security problem handling responses to FTP PASV command" seems to have changed the internal FTP handling code to ignore changes in the IP address of the server during the transaction.
I believe the "Expected Results" section failed to note that under a transparent proxy situation, the changing of the IP address sent in the PASV response is desired behavior.
More details on my specific situation:
I have a Cisco router running WCCP between it and 2 Bluecoat proxies.  In this transparent proxy configuration, the cisco redirects interesting packets to the bluecoat which then initiates the outbound web traffic.  Under passive FTP, this  seems to require that the proxy be able to instruct the browser to connect to a new IP address (as the PASV response seems to pass along.)
However, in appears from the description in Bug 370559, this behavior was modified so disable the ability to change IP addresses in the passive response.
I recognize that the changing of IP addresses in untrusted zones such as the internet would be a security risk.
Can some allotment be made for situations where this IP change in the PASV response is still honored?

Another point: Under "Expected Results" there is a note that says that "This seems to be what Internet Explorer 6 and 7 do."   I have an XP VM running Firefox (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6) as well as Internet Explorer 7.  Firefox under windows acts the same as under Linux (i.e. fails.)  But IE7 is able to handle the PASV ftp server redirect from the transparent proxy okay.


Reproducible: Always

Steps to Reproduce:
1. Configure WCCP between router and bluecoat proxy for HTTP and FTP.
2. Start firefox with network connection set to direct.
3. Try to access an Internet based ftp site through the browser.
Actual Results:  
Browser connects on command channel.  Never prompted with Save As dialog window, eventually times out. 

Expected Results:  
Data channel should have started between the browser and the transparent proxy.  File Save As dialog window should have been presented.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Is this a regression of bug 370559?

Comment 2

[Michael Krivacek]

I'm not sure exactly what that question means.
The patch to fix bug 370559 changed the behavior of firefox.  A side effect of this change is that transparent proxying using wccp no longer works.

Comment 3

[mozilla]

Just ran into the same problem using Firefox 3.0.6 and the frox transparent proxy. Probably any transparent FTP proxy is affected.

Ignoring the destination IP returned in the PASV command is a common way to enhance security. Examples are the Linux ip_conntrack_ftp module (option enabled by default) and the frox transparent proxy (option disabled by default). What about introducing an "about:config" option in firefox to disable fix of bug 370559 (which breaks the FTP RFC)?

Comment 4

[Patrick McManus [:mcmanus]]

We are in a period where ftp is clearly deprecated and in general, making changes to the code is riskier than letting it ride unless there is a patch and reviewer available to make a good judgment about it. So I'm going to wontfix ftp bugs related to enhancements, interop errors, etc.. We will be better off putting our energy into including a different js based ftp stack.