370559 - (CVE-2007-1562) security problem handling responses to FTP PASV command

Status: VERIFIED FIXED

(Core Graveyard :: Networking: FTP, defect)

Description

[Daniel Veditz [:dveditz]]

Mail received by [e-mail] from "mark". Got lost in the spam, originally sent on Jan 29
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The following bug affects Firefox 2.0.0.1.  I believe it also affects
previous versions.

The format of this mail is based on the "Guided" bug report web page.

Hardware platform
-----------------
PC


Operating System
----------------
Linux (but also tested on Windows XP)


Build Identifier
----------------
Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.1.1) Gecko/20070118
BonEcho/2.0.0.1


URL
---
N/A


Summary
-------
Firefox security problem handling responses to FTP PASV command


Details
-------
During a normal FTP conversation between Firefox and an FTP server,
Firefox will send the PASV command:
PASV
and the server will reply with an IP address and port number, e.g:
227 Entering Passive Mode (127,0,0,1,35,40)

Firefox then connects to the IP and port provided to retrieve data from
the FTP server (directory listing, file or whatever).

So far this is normal behaviour for an FTP client.  However, if the FTP
server is malicious, it could send back an IP address other than its
own.  This causes Firefox to connect to the IP address and port chosen
by the malicious FTP server.

The impact of this is discussed in the "Additional Information" section
below.


Reproducability
---------------
Happens every time.


Steps to Reproduce
------------------
1. Start a packet sniffer on the loopback interface, e.g: tcpdump -n -i lo

2. On the same host start a netcat listener on port 21: nc -v -n -l -p 21

3. On the same host open firefox and enter the URL: ftp://127.0.0.1/

4. netcat should now show an incoming connection, e.g:

# nc -v -n -l -p 21
listening on [any] 21 ...
connect to [127.0.0.1] from (UNKNOWN) [127.0.0.1] 37209

5. You now need to send a series of FTP commands to firefox.  In the
netcat session, first send an FTP banner "220 myftpserver".  After
pressing ENTER firefox should send a login name.  Reply with "230
Login successful.".  Continue as shown in the instructions below (note
that each response you need to send starts with 3 digits and the "SEND:"
part should not be typed).

SEND: 220 myftpserver
RECV: USER anonymous
SEND: 230 Login successful.
RECV: SYST
SEND: 215 UNIX Type: L8
RECV: PWD
SEND: 257 "/"
RECV: TYPE I
SEND: 200 Switching to Binary mode.
RECV: PASV
SEND: 227 Entering Passive Mode (127,0,0,99,35,40)

Now flick back to the packet sniffer you started in step 1.

Upon sending of the "227" response above, you should see firefox try
to connect to the address specified (127.0.0.99) - though this could
have been any address (even one on a client's internal network).


Actual Results
--------------
Firefox connect to the IP address supplied by the (possibly malicious)
FTP server.


Expected Results
----------------
(IMHO) Firefox should ignore the IP address supplied by the FTP server
in its PASV response.  Here's my reasoning...

In practice, the IP address sent in the PASV response (127,0,0,99 above)
should always be the same IP address to which the client connected
initially (i.e. 127.0.0.1 in the example above because the client
connected to ftp://127.0.0.1).  It therefore seem wise to ignore the IP
address sent in the PASV response (127,0,0,99 above) and instead use the
IP address the client connected to (127.0.0.1 above).

This seems to be what Internet Explorer 6 and 7 do.


Additional Information
----------------------
It is therefore possible for a malicious web page + malicious FTP server
to cause Firefox to connect to arbitrary ports on arbitrary hosts - even
ones on a client's internal network, and even ports on the banned list
(http://www.mozilla.org/projects/netlib/PortBanning.html).

Using JavaScript, it would be possible for the malicious website to have
information like the following sent back out by firefox to an attacker:

127.0.0.1:22 returned banner: SSH-2.0-OpenSSH_4.5%0A
10.0.0.1:21 returned banner: 220%20%28vsFTPd%202.0.4%29%0A

Note that javascript portscanning is not new.  It well documented here:
http://www.spidynamics.com/assets/documents/JSportscan.pdf

The new security problems posed by the PASV problem are:
- Bypassing of the banned ports list
- Grabbing of banners from other network services as show above

Please let me know if you need any further information.

Regards,

Mark

Comment 1

[Reed Loden [:reed]]

This vulnerability is now public, as per http://bindshell.net/papers/ftppasv paper.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: branch patch

I tested this patch on MOZILLA_1_8_BRANCH; should work on 1_8_0 too I think

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

HEAD:
Checking in netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.309; previous revision: 1.308
done

MOZILLA_1_8_BRANCH:
Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.296.8.5; previous revision: 1.296.8.4
done

MOZILLA_1_8_0_BRANCH:
Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <--  nsFtpConnectionThread.cpp
new revision: 1.296.8.1.2.3; previous revision: 1.296.8.1.2.2
done

Comment 6

[Bob Clary [:bc] (inactive)]

tested on Fedora Core 6

nc.txt:
220 myftpserver
230 Login successful.
215 UNIX Type: L8
257 "/"
200 Switching to Binary mode.
227 Entering Passive Mode (127,0,0,99,35,40)

term1: # /usr/sbin/tcpdump -n -i lo > tcp.log
term2: # cat nc.txt | nc -lnv 21
term3: firefox ftp://127.0.0.1

with firefox 1.5.0.10/2.0.0.2 tcp.log does contain 127.0.0.99
with firefox 1.5.0.11/2.0.0.3/trunk tcp.log does not contain 127.0.0.99

verified fixed on linux 1.5.0.11/2.0.0.3

wasn't sure about the interface names etc on Mac OS X.

Comment 7

[Bob Clary [:bc] (inactive)]

fyi, I also tested by setting up tcpdump, nc and the ftp commands on my linux box to use the network addresses on my local network 192.168.1.x then connected to the linux box's port 21 from a mac and a winxp box. The logs showed that 1.5.0.10 and 2.0.0.2 caused the linux box to send arp requests about the 192.168.1.99 while 1.5.0.11 and 2.0.0.3 did not. I assume this shows the fix worked on mac and winxp as well.

Comment 8

[juan becerra [:juanb]]

I followed steps in comment #6 and I observed similar results on linux. FF2001 showed 127.0.0.99, FF2002 showed 127.0.0.99, but FF2003rc1 showed 127.0.0.1

Comment 9

[Pascal Hambourg]

I'm afraid that the patch introduced a bug. I observed that when the FTP server name resolves to multiple IPv4 or IPv6 addresses, if Firefox 1.0.0.5 Win32 fails to establish the control connection to the first one, connects to the next one and it is IPv4, then it tries to establish the data connections to the wrong address.

In the following tethereal trace, the client is 192.168.0.246 and the FTP server name resolves to 2 IPv4 addresses, 192.168.77.77 (which is unreachable) and 10.0.0.1 (which works).

  0.003789 192.168.0.246 -> 192.168.77.77 TCP 2576 > ftp [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
  0.003982  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
[FF tries to connect to the same address a couple more times, then tries the next one]
  22.927733 192.168.0.246 -> 10.0.0.1     TCP 2577 > ftp [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 22.928141     10.0.0.1 -> 192.168.0.246 TCP ftp > 2577 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 22.928365 192.168.0.246 -> 10.0.0.1     TCP 2577 > ftp [ACK] Seq=1 Ack=1 Win=16872 Len=0
 22.951537     10.0.0.1 -> 192.168.0.246 FTP Response: 220 zenith FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready.
[...]
 47.550885 192.168.0.246 -> 10.0.0.1     FTP Request: PASV
 47.552513     10.0.0.1 -> 192.168.0.246 FTP Response: 227 Entering Passive Mode (10,0,0,1,6,113)
[Below you can see that FF tries to connect to the passive data port on the wrong IP address]
 47.573527 192.168.0.246 -> 192.168.77.77 TCP 2579 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 47.573676  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
 47.582035 192.168.0.246 -> 10.0.0.1     FTP Request: LIST
 50.815537 192.168.0.246 -> 192.168.77.77 TCP 2579 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 50.815738  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
 57.377511 192.168.0.246 -> 192.168.77.77 TCP 2579 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 57.377686  192.168.0.1 -> 192.168.0.246 ICMP Destination unreachable (Host unreachable)
[Eventually it gives up and connects to the next (and correct) address]
 70.501974 192.168.0.246 -> 10.0.0.1     TCP 2580 > 1649 [SYN] Seq=0 Ack=0 Win=16384 Len=0 MSS=1406
 70.502219     10.0.0.1 -> 192.168.0.246 TCP 1649 > 2580 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
 70.502437 192.168.0.246 -> 10.0.0.1     TCP 2580 > 1649 [ACK] Seq=1 Ack=1 Win=16872 Len=0
 70.510995     10.0.0.1 -> 192.168.0.246 FTP Response: 150 Opening BINARY mode data connection for '/bin/ls'.

This does not happen when the control connection uses IPv6. To my understanding it is because when the control connection uses an IPv6 address FF uses the same address for the data connections, whereas when the control connection uses an IPv4 address it does new name lookups to retrieve the address for the data connections, which is wrong.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Pascal, could you please file a new bug for the issue you've found, and CC me?