1735034 - Firefox Relay extension renders privileged extension element in arbitrary site

Status: RESOLVED FIXED

(WebExtensions :: Developer Outreach, defect, P3)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 Safari/537.36

Steps to reproduce:

1. Install Firefox Relay extension (https://addons.mozilla.org/en-US/firefox/addon/private-relay/).
2. Go to https://attack.shhnjk.com/relay.html

Actual results:

If you are signed in, your Firefox relay emails will be generated infinitely until you reach the limit of generation.

If you are not signed in, it should open many sign up tabs. It should work, but I wasn't able to confirm this as I couldn't find a way to clear sign-in state in Firefox Relay extension.

Expected results:

Extension's buttons should be rendered in an extension's iframe.

Comment 1

[Frederik Braun [:freddy]]

I agree that it's undesirable to breaking the functionality of the relay feature, but a DoS like this seems like a sec-low as per our Severity Ratings page and is probably below the bar of issues that we need to heavily prioritize.

What I do find noteworthy is that the UI elements for sign-up and generating email address is observable. That is certainly something the team should look into.

P.S: Luke, can you help find the right component for this?

Comment 2

[Jun (Request needinfo for comment, I ignore other updates)]

Just clarify one point, this is slightly more than a DoS. Because any site will be able to obtain user’s relay email address without user action or knowledge.

Therefore, any site can contact the user :)

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

Based on the earlier comments (in particular comment 1 and a quick look to the extension sources at https://github.com/mozilla/fx-private-relay-add-on), this should be an issue that would have to be fixed on the extension side, and so I'm moving this issue into "WebExtensions :: Developer Outreach".

To avoid to allow the webpage to observe UI elements specific to Firefox Relay, the Firefox Relay content scripts may opt to inject an iframe element that points to an Firefox Relay extension page url.

The resulting iframe would have the same access to the extensions API that are accessible from the content script, but the webpage where the iframe element is injected into will be able to remove the iframe element (or change its positioning through css rules) but it would not be able to inspect its content.

Luke, would you mind to take a look into this?

Comment 4

[Daniel Veditz [:dveditz]]

A web site could contact a user, but doesn't really know who they are. Can't track the user because if they try it again they get another address. And the website could use up all their addresses which is a DOS.

I couldn't reproduce on Nightly, though it could be because of something I've tweaked. I get the console message

Security Error: Content at https://attack.shhnjk.com/relay.html may not load data from blob:https://attack.shhnjk.com/edbf022c-6610-2745-a8ff-a34fe7060028.

Comment 5

[Frederik Braun [:freddy]]

It looks like the click handler in https://github.com/mozilla/fx-private-relay-add-on/blob/1287214a33081db8bfedfbfc7afc750f6d41b503/src/js/add_input_icon.js#L187 could check that the passed event has isTrusted set to true.

Is that something you could look at, Maxx?

Comment 6

[Daniel Veditz [:dveditz]]

Follow-up to comment 3: check out the "create your UI with extension components" section at https://extensionworkshop.com/documentation/develop/build-a-secure-extension/ (thanks to Luca for the link).

Comment 7

[Luke Crouch [:groovecoder]]

Wow, bugzilla mail is a black-hole for me these days, sorry.

Comment 8

[Luke Crouch [:groovecoder]]

Added Relay add-on engineers to get into this.

Comment 9

[Maxime Veit]

To comment 5 I want to notice, that it's not only scripts as written in "create your UI with extension components" but also CSS which can "compromise" the extension (e.g. by stretching the invisible button over the whole page). This would mean that checking the "isTrusted" property would not solve the problem in its entirety.

Comment 10

[Maxx Crawford [:maxx]]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #3)

Based on the earlier comments (in particular comment 1 and a quick look to the extension sources at https://github.com/mozilla/fx-private-relay-add-on), this should be an issue that would have to be fixed on the extension side, and so I'm moving this issue into "WebExtensions :: Developer Outreach".

The iframe method Luca outlined looks like the way to go. I'm going to spend some time next week prototyping this. Not sure if that solves the issue entirely, but it is a start. Thanks!

(In reply to Frederik Braun [:freddy] from comment #5)

It looks like the click handler in https://github.com/mozilla/fx-private-relay-add-on/blob/1287214a33081db8bfedfbfc7afc750f6d41b503/src/js/add_input_icon.js#L187 could check that the passed event has isTrusted set to true.

Freddy: Absolutely. I'll file an issue separately in the repo to address this.

Comment 11

[Maxx Crawford [:maxx]]

(In reply to Frederik Braun [:freddy] from comment #5)

It looks like the click handler in https://github.com/mozilla/fx-private-relay-add-on/blob/1287214a33081db8bfedfbfc7afc750f6d41b503/src/js/add_input_icon.js#L187 could check that the passed event has isTrusted set to true.

Is that something you could look at, Maxx?

I have a patch up for review on GitHub for this. I also created a test page to validate this behavior.

Comment 12

[Frederik Braun [:freddy]]

Maxx, thank you for taking this on, I got a couple of questions:
Do you plan to solve the CSS aspect of this bug or does it depend on some bigger architecture changes?
Can you write automated tests that will make sure this can't happen again?

Comment 13

[Maxx Crawford [:maxx]]

(In reply to Frederik Braun [:freddy] from comment #12)

Maxx, thank you for taking this on, I got a couple of questions:
Do you plan to solve the CSS aspect of this bug or does it depend on some bigger architecture changes?
Can you write automated tests that will make sure this can't happen again?

I now have a WIP patch that refactors the content script so all of the Relay functionality/markup (outside of the icon to init it) is wrapped inside an iframe (with an internal page that ships with the add-on). I'll keep this bug posted on my progress.

Also note that the isTrusted check has been merged in and distributed in the latest version of the add-on.

Comment 14

[Frederik Braun [:freddy]]

Thanks Maxx. Please keep this bug updated once you consider the issue resolved, as we need it for bug bounty tracking.

Comment 15

[Maxx Crawford [:maxx]]

We have not yet fully implemented the iframe solution (though it will be released in the next major release), however, nothing is yet rendered without a user-activated click. I think we can mark this as resolved (as the original issue can no longer be replicated)