Open Bug 1641357 Opened 5 years ago Updated 2 years ago

Allowing access to localhost web servers in private tabs from non-local pages can unexpectedly leak identity

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Version:
78 Branch
Type:
defect

Tracking

()

People

(Reporter: kittens, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

The MEGASync client somehow hooks browser clicks even without an extension, even in private mode. There is no download dialog and open with... handler, and I have no automatic instant downloading enabled. So how does the client creepily pop up when I just click a link on a website, immediately? It seems like firefox should at least try to fight this, if possible.

  1. Install mega.nz client (free albeit not open source I think)
  2. Open any mega.nz folder link in firefox, can be in private mode even when not logged in
  3. Click download on any of the cloud share files

Actual results:

Browser window loses focus, suddenly see a native MEGAClient popup box asking me what to do with this file

Expected results:

At the very least, a prompt by firefox of any sort that I am invoking a local program that asks me to confirm first, e.g. a protocol handler open prompt.

Local programs running with the same privilege level can hook each other using OS calls. This is intended for good (e.g. accessibility devices, anti-virus) but is also functionality used by malware and viruses.

Group: firefox-core-security

I don't understand, is it doing a DLL override? Is Firefox providing an API for this? Some IPC mechanism for accessibility? I don't run MEGASync as root, so I don't think it can just inject things into Firefox's memory. As a start it would be great to know what it is even doing

(In reply to Ellie from comment #2)

I don't understand, is it doing a DLL override?

Maybe.

Is Firefox providing an API for this? Some IPC mechanism for accessibility?

No.

(In reply to Ellie from comment #0)

  1. Open any mega.nz folder link in firefox, can be in private mode even when not logged in
  2. Click download on any of the cloud share files

I don't use "mega.nz" (whatever that is), so I don't really understand, but is step 3 on "mega.nz" still? And is that the same website that makes the client? The loaded-in-your-browser website can probably communicate with the client by making script it runs on the page make a websocket or http connection to localhost, or doing an external protocol request that is handled by the client.

It's also possible they've messed with something in the Firefox profile folder, or that there's a dll injection.

Without further details (which I'm not in a position to gather given there aren't enough steps to describe how to reproduce - even the OS is not clear, given comment #0 says Linux but you're talking about dlls) I don't think this is a Firefox bug.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

but is step 3 on "mega.nz" still?

Yes

by making script it runs on the page make a websocket or http connection to localhos

Wouldn't allowing a random external page communicate with a random localhost port be a quite security breach too?

doing an external protocol request that is handled by the client.

Impossible, I was in private mode so there is no way it could have connected it to my account. And I don't have any mega.nz addons.

I think what is going on is possibly very concerning, it seems to me like this shouldn't be possible. I think there is some tampering going on here which possibly Firefox should prevent. I would suggest at least leaving it open until it is cleared as something innocent, because if it's not I think this really needs fixing

Ok, I found the MEGASync source code. I think the problematic thing is going on here, and confirms your localhost theory:

https://github.com/meganz/MEGAsync/blob/master/src/MEGASync/platform/linux/LinuxPlatform.cpp#L314

I think at least for a private tab this is unexpected. This connected my IRL identity to the private tab, which is the exact thing a private tab is supposed to prevent. I therefore suggest private tabs should block access to local addresses unless the page itself is a local address, even when the targeted local server has a same origin header that allows it.

Summary: MEGASync client somehow hooks browser clicks even without an extension, security hole? → Allowing access to localhost web servers in private tabs from non-local pages can unexpectedly leak identity

(In reply to Ellie from comment #5)

Ok, I found the MEGASync source code. I think the problematic thing is going on here, and confirms your localhost theory:

https://github.com/meganz/MEGAsync/blob/master/src/MEGASync/platform/linux/LinuxPlatform.cpp#L314

I think at least for a private tab this is unexpected. This connected my IRL identity to the private tab, which is the exact thing a private tab is supposed to prevent. I therefore suggest private tabs should block access to local addresses unless the page itself is a local address, even when the targeted local server has a same origin header that allows it.

No web browser, to my knowledge, currently blocks this type of thing, and it is only possible because you cooperated with the "attacker" by installing their software which is listening locally. bug 354493 has tracked this type of issue for a long time.

Anne, do you think we should treat private tabs differently here, or a web compat reason why we might want to start there or something?

Flags: needinfo?(annevk)

Yeah I agree, in a normal tab this is expected to work. But I think in a private tab there is a point for not allowing it at all, because in my case it definitely leaked my identity to the page. Or maybe a middle ground could be found with a warning prompt that requires to confirm before the request goes through?

It might be easier to deploy something in private browsing mode because of web compatibility reasons, but

  1. It would still require quite a bit of design and engineering work I suspect as well as ensuring there is organizational buy-in to distinguish between these types of IP addresses.
  2. Preventing software that is already on your computer from interfering seems hard and it's not clear to me that addressing this through distinguishing between types of IP addresses would resolve that problem conclusively.
Flags: needinfo?(annevk)

Preventing software that is already on your computer from interfering seems hard a

I would suggest to totally forget about that "manipulation" angle, this is IMHO not the problem and I overreacted because it creeped me out in private mode in particular.

I think the "manipulation" here is desired by most users, and the actual problem is that MEGASync cannot conceptually know that Firefox is accessing it from a private tab. Therefore, I think it is the browsers responsibility here to block this from a private tab to save both the MEGASync software and the user from themselves in this scenario.

This would also give an easy way to discover users are in private tab. That doesn't seem great.

Would it, if Firefox just blocked it in a way pretending the target port is just not open? (Rather than block it with an "unavailable in private tab" error)

It would of course allow Mega to know that I'm possibly in a private tab ONCE I AM LOGGED IN in that tab, but I might also not have launched their client right now, so not even with 100% certainty. And I don't think this is a vector worth protecting against, because obviously at that point they already identified me anyway.

Yeah, the timing would be way different.

Ah, of the fake connection refused, because no actual connection attempt was made? Good point, that could be a problem. Hmmm...

Since a "true" connection refused should also be at least ALMOST instant if it's local since there is no wire transfer - this leads me to think that a quite minimal amount of randomized delay for localhost connections could help with this. Of course it's admittedly also a quite conceptually complex solution and a bit of a hack. An alternative, cleaner way I can think of would be treat access to any LAN or localhosts as a website permission like camera (could be named permission to "Access local network/local computer web resource" or something along the lines). Always prompting about this would remove the distinction of private tab or not, and also increase security in normal tabs. This would also solve the problem.

Yes, that's bug 354493 and I agree with that conclusion.

Honestly, I can't tell what bug 354493 is really about, and its conclusion seems to have been an about:config option. I think that isn't helpful, because that breaks legitimate uses like MEGASync entirely because nobody will bother to constantly toggle a global option. It really would need to be a per-website permission defaulting to "Always Ask", and I suggest in private mode the setting should revert back to its default in a newly started private session separate from the normal mode setting. (Not sure if this is what permissions already do in private mode, but this would be both required to reduce permissions-based finger printing and to protect users in private mode better even if they otherwise want to use MEGASync-like software and specified "Allow" in non-private mode previously.)

An additional note: after reviewing, I think Chrome's solution https://www.chromestatus.com/feature/5733828735795200 also doesn't help here, because relying on headers from the local server again puts the burden on MEGASync which doesn't have the necessary info for a sensible decision. The private tab situation IMHO can only really be solved by either blocking it by default always no matter what the local server says, or giving the browser user a choice inside the browser when in private mode.

Since bug 354493 seems to be about a mechanism that doesn't resolve the situation at hand (after all MEGSync would likely implement the headers to allow localhost access from the browser) would it make sense to reopen this?

I think the solution should be to always block connections to localhost from private tabs, and optionally allow an opt-in setting to enable it. Even with services that want to be discovered locally (which is what bug 354493 is about) these services cannot tell if the browser is in private mode, so there is an additional distinction required to avoid unintended identity leaks. This is why I think this bug would be useful to remain open to track the solution to the specific private tab related issues.

Sure.

Status: RESOLVED → REOPENED
Depends on: 354493
Ever confirmed: true
Resolution: INVALID → ---

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

/me slaps relmanbot around with a trout.

Component: Widget: Gtk → Networking
Priority: -- → P3
Whiteboard: [necko-triaged]

The severity field is not set for this bug.
:michal, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(michal.novotny)
Severity: -- → S3
Flags: needinfo?(michal.novotny)
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.