Closed Bug 1367728 Opened 8 years ago Closed 8 years ago

FF might leak between tabs, and thinks LAN not secure

Categories

(Firefox :: Untriaged, defect)

52 Branch
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: scratch65535, Unassigned)

Details

(Keywords: testcase-wanted)

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170517122419 Steps to reproduce: (This is really only a heads-up, since I killed the FF job immediately and did not try to reproduce the problem) A little earlier this morning, while loading a page from my server-of-all-work, the load appeared to wait on decenthat.com, a data-collecting site. Since I myself wrote every line in vanilla PHP and JS on the page I was loading, I knew there was no reference to that site unless it was somehow embedded in a font. Nor did I at the time know what the 'decenthat' site was, so I immediately killed the FF job. At the time, there was another tab open to a site (truthdig, iirc) that permits all kinds of capitalist **** to piggyback on their page loads, and the only thing I can suppose is that, somehow, there was some contamination between the two tabs such that decenthat thought it could snoop the page from my server too; that, or the notice belonged the other tab even though that tab had been open for awhile and should not still have been waiting on any site. While trying to figure out what had happened, I opened Tools->PageInfo resp. the page from my server and discovered that FF doesn't distinguish between intranet and internet even though it should realise that a reference without a TLD was to a local node, not a site. But it doesn't, and declared categorically that the connection to my server is insecure, which it's not unless FF is insecure: there's a dedicated pfsense box with snort sitting between the DSL modem and the LAN, and nothing gets in without an invitation. Probably FF should distinguish between node and site references, and qualify claims about insecurity where the reference is to a node. I checked the "security" box below because if there *is* some kind of between-tab contamination, it's potentially a pretty big problem.
The second part is not a problem. We're not declaring your site insecure, we're saying the connection is not private. If you know that you are on a completely protected internal network then you can decide that's not important, but there's no way for Firefox to know. Not all "internal" networks are secure (as Google found via the Snowden revelations). Since two issues in the same bug don't work very well let's just worry about your first issue. I'm not sure how to investigate your claim that the decenthat.com load happened from your page. It's possible our messaging was incorrect and that the background page was the one making the load. Is there a way we can test or reproduce this?
Group: firefox-core-security
The second part was meant to be an oh-by-the-way suggestion that, when seeing a local reference, FF probably should not make categorical statements (since if it can't know that the LAN is secure, it also can't know that it's insecure) but instead ask whether the system connecting to the internet is running firewall software to prevent intrusion and if the answer is No, point out that local HTTP connections are just as insecure as HTTP connections out to the inet. As to the contamination question, I didn't try to do any testing because, leaving aside my overburdened schedule, I don't have a scratch system that could safely be put at risk. My thought was that you guys probably *do* have test boxes for that purpose as well as the expertise to know where to begin looking for possible ways something could breach whatever inter-tab barriers there are. I've not read any announcement saying that your process-per-tab rewrite has been released, so I suppose the tabs are all still incestuously timesharing a single process. Since I'm sure everything's written in C (I've downloaded but not had time to look at the source), and I doubt cowboy programming has gone out of style since I retired, I bet there are some loose pointers still waiting to send the program counter off to godknowswhere :-}. If you guys can't test for it either, then at least if someone else reports something similar you'll have *2* vague data points :-)
Keywords: testcase-wanted
Closing this as incomplete due to inactivity and lack of test case to reproduce. If anyone can still reproduce it on latest versions, feel free to reopen the bug and provide more information. Thanks
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.