435464 - When running firefox over SSH 2nd and greater instances are created as children of first instance window.

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[sphantom]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5

When running firefox on a remote machine via SSH and displaying contents locally, 2nd and later firefox windows ALL run on the same machine (and thus have the same internet connection) where the first window was started.

It would appear that Firefox is using
See steps to reproduce below for specifics.

Reproducible: Always

Steps to Reproduce:
There are two scenarios. One where firefox is always run locally, and another where firefox is always run remotely. I will only illustrate the first scenario here. The second is identical to the first, except that you start firefox on the remote system before running any firefox windows on your local system.

1. Close ALL firefox windows.
2. Terminate any SSH sessions you may have running.
3. Launch firefox on your local box.
4. In firefox browser, navigatate to "whatismyip.com" (or your favorite site that tells you your public IP) and note the IP shown on the page.
5. SSH (using "ssh -Y <machine>..." to a machine on a different network than your local box. The remote network should have a web server that is only accessible to the remote machine for testing/verification purposes.
6. Run firefox on the remote machine.
7. In the browser that is "supposedly" running on the remote machine, navigate to whatismyip.com (or the site you chose in step 4) and note that it shows the same public IP that you got for your local machine.

(If 1-7 doesn't convince you...)
8. In the supposedly remote firefox window type the URL of a site that is only accessible to the remote machine. Note that the request cannot be resolved. (Because you are actually NOT interacting with a remote firefox process.)
9. Close both firefox windows.
10. Run firefox on the remote host from your SSH session.
11. Navigate to whatismyip.com (or the site you chose for step 4) and note that you are now seeing the public IP for your remote system.
12. Launch firefox on your local system. (Note the significant delay, almost like it's running remotely)
13. In the supposedly local firefox window, navigate to whatismyip.com (or the site you chose for step 4) and note that the external IP of the remote machine is now displayed in the "local" firefox window.
14. In the supposedly local firefox window, navigate to the web site that is only accessible to the remote system. Note that you are now able to connect to it because you are actually running two remote firefox sessions.

Actual Results:  
Actual results are integrated with the steps to reproduce.

Expected Results:  
Remote window be running on remote system, local window to be running on local system.

Comment 1

[Benjamin Smedberg]

This behavior is by design. When it is launched, Firefox will search for an existing Firefox window and forward to the existing window if found. To suppress this behavior use the -no-remote commandline flag.

Comment 2

[Juliano F. Ravasi]

I request that this bug be reopened, and considered a serious security issue.

If this behavior is by design, according to Benjamin Smedberg in comment 1, then the design is wrong and must be fixed. This is a major security vulnerability.

Firefox (and this holds true for any Unix application) should never, ever receive commands coming from other applications running on the same X display, without checking that they both are processes running in the same computer and from the same user account. Just because two processes are running on the same X display doesn't mean that they have the same trust level.

I have a secondary, unprivileged user account specifically designed to run programs that I don't trust running on my primary account. I got really scared when I clicked on an untrusted link on an IRC client running in this separate account and the page was loaded on the Firefox instance running on my primary account. This is by far not standard Unix application behavior.

The problem is even worse over an SSH connection. I don't trust all my remote SSH accounts, but I have to export my X display (tunneled over SSH) nevertheless. I expect that my local processes are smart enough to reject commands from other windows on the same display, or at least check that the source user credentials match.

This have pretty much the same potential (and very similar attack procedure) of the cross-browser vulnerability found in Firefox 2.0.0.4.