Restrict discoverability of protocol handlers [Tor 1623]

NEW
Unassigned

Status

()

Core
Networking
P3
normal
6 years ago
2 months ago

People

(Reporter: khuey, Unassigned)

Tracking

(Blocks: 1 bug, {privacy})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fingerprinting][probing][necko-backlog][tor], URL)

In the link, the presence of an extension that registers a protocol handler is detected by:

<img src="sacore:green.gif" onerror="alert('McAfee Site Advisor not Installed.')" onload="alert('McAfee Site Advisor Installed!')"></img>

This is then used to target an exploit against the extension's binary components.

Can we restrict discoverability of non-built-in protocol handlers from the web by not allowing loads from weird protocols with a content page can receive error/load events?
Keywords: privacy
Whiteboard: [fingerprinting][probing]
As far as I can tell, SiteAdvisor's latest incarnation doesn't register a protocol handler for 'sacore'.  I still think we should consider doing this though.
Isn't this up to the extension?  It can list the protocol as not loadable by untrusted sites.  So either sacore: was explicitly listed as loadable by untrusted sites, or the extension listed no security flags on the protocol at all (which defaults to the old "allow loads from anywhere" behavior) and got a warning in the console the moment someone tried to use the protocol in an untrusted page saying that the extension is not providing this information.

I suppose we could go ahead and default to "no load" if none of the protocol security flags are set now that we've had that warning for a few years.  Or we could move the warning earlier in the function so it happens even for loads from inside chrome and then give extension authors a cycle or two to catch any warnings from that, I suppose.  That comes at a performance cost, sadly.
Whiteboard: [fingerprinting][probing] → [fingerprinting][probing][necko-backlog]
Blocks: 1329996

Updated

10 months ago
Priority: -- → P2
Summary: Restrict discoverability of protocol handlers → Restrict discoverability of protocol handlers [Tor 1623]
Whiteboard: [fingerprinting][probing][necko-backlog] → [fingerprinting][probing][necko-backlog][tor]

Comment 3

7 months ago
http://pseudo-flaw.net/tor/torbutton/scan-protocol-handlers.html implies this may be fixed? On Firefox I got popups about two protocol handlers I had installed, but the page said that nothing was discoverable before I clicked cancel or otherwise interacted.
Priority: P2 → P1
Whiteboard: [fingerprinting][probing][necko-backlog][tor] → [fingerprinting][probing][necko-backlog][tor][fp:m1]
Whiteboard: [fingerprinting][probing][necko-backlog][tor][fp:m1] → [fingerprinting][probing][necko-backlog][tor][fp:m2]
The original Tor ticket: https://trac.torproject.org/projects/tor/ticket/1623

According to the Tor ticket and comment 3, nothing needs to be done for this issue.  Might be works for me or won't fix.
But let's move it to the backlog for tracking.
Priority: P1 → P3
Whiteboard: [fingerprinting][probing][necko-backlog][tor][fp:m2] → [fingerprinting][probing][necko-backlog][tor]
(In reply to Tom Ritter [:tjr] from comment #3)
> http://pseudo-flaw.net/tor/torbutton/scan-protocol-handlers.html implies
> this may be fixed? On Firefox I got popups about two protocol handlers I had
> installed, but the page said that nothing was discoverable before I clicked
> cancel or otherwise interacted.

There seems to be a small flaw in the test page.  It thinks it discovers a protocol when it catches an error that's not NS_ERROR_UNKNOWN_PROTOCOL, but it doesn't consider the case where no error occurred.

I tweaked the page a little bit, and now it can discover the smb handler on my laptop.
https://people-mozilla.org/~jhao/scan-protocol-handlers.html
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P3 → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.