Closed Bug 1640449 Opened 4 years ago Closed 1 year ago

Privacy and security features should prevent localhost and local network WebSocket abuse

Categories

(Core :: DOM: Networking, enhancement, P3)

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1481298

People

(Reporter: ch-bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fingerprinting][necko-triaged])

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

Steps to reproduce:

I recently read this blog post

https://nullsweep.com/why-is-this-website-port-scanning-me/

which described websites abusing WebSockets to port scan user's computers, possibly for fingerprinting purposes. In addition to the localhost fingerprinting risk, it seems this technique could be generalized to map and fingerprint devices on the user's (RFC1918) LAN, and potentially to attack on-LAN WS-capable endpoints that don't have publicly reachable addresses.

This seems like a privacy a issue that should be addressed as part of Firefox's anti-fingerprinting features, and a security issue that should be addressed to prevent hostile JavaScript from mapping the user's LAN and attacking LAN-based WebSocket devices that most network operators would ordinarily consider to be inside their security boundary.

I can't think of any legitimate reason for JavaScript content served from a routable IP address to access anything inside the user's RFC1918 address space, or for any website not served from localhost to access localhost resources. I think these access patterns should be blocked by default and only allowed using an about:config setting.

The user benefits from allowing these access patterns are so slim that another user-visible permission probably isn't necessary.

Actual results:

Firefox does not impose adequate security and privacy (anti-fingerptinting) constraints to prevent localhost and local network access abuse by hostile Javascript.

Expected results:

Firefox should restrict Javascript network access to non-routable addresses including localhost and RFC1918 blocks.

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

Component: Untriaged → Networking: WebSockets
Product: Firefox → Core

Hello Ethan,
Could you point me on how to let the fingerprint team triage this?

Flags: needinfo?(ettseng)

There is now a proof-of-concept exploit using this technique to exfiltrate information from front-end developers who are using React locally:

This overall risk of unrestricted WebSocket access is getting attention from other sources, including Bruce Schneier and StackExchange's infosec section.

(In reply to Junior from comment #2)

Hello Ethan,
Could you point me on how to let the fingerprint team triage this?

We specify a fingerprinting bug by two settings:

  1. Make the bug block the meta bug, Bug 1329996 - [META] Tor Uplift: Fingerprinting Resistance
  2. Add the whiteboard keyword [fingerprinting]

However, the fingerprinting team has shifted our priority and focus on other areas. The activity on our Fingerprinting Resistance project is pretty low at the moment.

Flags: needinfo?(ettseng)
Whiteboard: [fingerprinting]

P/S based on that websocket to a local host can be really useful. Preventing fingerprinting with websockets is not that much a networking bug. Moving to DOM.

Severity: -- → S3
Component: Networking: WebSockets → DOM: Networking
Priority: -- → P3

I would like, at minimum, to see an option to prevent websites from accessing localhost when Firefox is in an anonymous window. Websites like Discord use this to detect whether the desktop app is currently running, and it's not a good sight when you open Firefox anonymously, visit a Discord invite link (in my case to test whether the link would work for other people), and the website is able to detect and potentially communicate with the desktop app.

Whiteboard: [fingerprinting] → [fingerprinting][necko-triaged]
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: private-network-access
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.