1719203 - (CVE-2021-43532) Context-menu "Copy Image Link" leaks intermediate redirect paths if loading interrupted

Status: VERIFIED FIXED

(Firefox :: Security, task, P1)

Description

[Ademar Nowasky Junior]

Attachment: poc.html

Hello,

The "Copy Image Link" item in the context menu of an image copies the URL after redirects. This data potentially reveals information about the redirect that would not otherwise be known to the original site. This could be used by a malicious site to obtain sensitive information like usernames or single-sign-on tokens encoded within the target URLs.

In cases where the sensitive information is not present in the final URL but instead in a redirect chain, it's possible to use a CSP img-src directive to break the redirect chain where it's needed to leave the image link with the sensitive information.

To perform this attack the victim needs to copy and paste the image link into the attacker's page.

The POC demonstrates the redirect chain case in a scenario where the user can choose an avatar by copying and pasting its URL in an input field. Each avatar is loaded in a div as a background-image and the malicious image tags are loaded in front of it with opacity:0 to make them transparent. By right-clicking the avatar image to copy its link the victim will be instead interacting with the malicious image tag.

The POC redirect chain works as follow:

1. The image src is set to https://urlwee.com/foqfun1
2. The image src URL will redirect to the sensitive URL https://bit.ly/36esqPj?token=secret123
3. The sensitive URL will redirect to https://example.com

The goal is to leak the https://bit.ly/36esqPj?token=secret123. This is accomplished with the following CSP:

<meta http-equiv="Content-Security-Policy" content="img-src 'self' https://urlwee.com https://bit.ly">

As the CSP directive doesn't have the https://example.com URL it will block the redirect to it, leaving the image link as https://bit.ly/36esqPj?token=secret123

Video: https://youtu.be/R2kb3fph8PE

Firefox version: 90.0b12 (Windows)

Comment 1

[:Gijs (he/him)]

(In reply to Ademar Nowasky Junior from comment #0)

Thanks for the report.

To perform this attack the victim needs to copy and paste the image link into the attacker's page.

I'm a bit unclear on this. In the PoC in the video, the image is already present in the page. This means the attacker already has access to the pre-redirect URL (the foqfun1 one). Under what circumstances does the attacker have this pre-redirect URL while also being unable to determine the target of the redirect? That is, if token=secret123 is secret, why isn't the foqfun1 URL secret?

Is there a practical application here, ie do twitter/fb/forum software of some sort divulge secrets in URLs in a way that this lets you exploit?

Using a pre-redirect URL causes other issues - the relevant code is at https://searchfox.org/mozilla-central/rev/5b3444ad300e244b5af4214212e22bd9e4b7088a/browser/actors/ContextMenuChild.jsm#976-993 and trivial checks on blame suggest that using the pre-redirect URI may cause issues with caching, image blocking, and/or blob URIs. :-\

We fixed the image drag & drop version of this problem in bug 1189814. I don't know how intentional continuing to use the post-redirect URL for the context menu is. Dan/Mats, thoughts?

Comment 2

[Ademar Nowasky Junior]

Hello,

Thanks for the response.

OAuth and probably other authorization mechanisms would suffer from this. In the most common scenario, the initial authorization endpoint is publicly exposed, and later in the redirection chain the access token is passed in a URL parameter.

Implementations of the Single Sign-On are also affected. Google, for instance, uses the https://accounts.google.com/CheckCookie endpoint for authentication. Once the browser request this URL, a redirection chain initiates passing the authentication data in the SIDT parameter to authenticate the user into other sites (youtube, blogger, ...). One of the redirects would look like this:

https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=<SENSITIVE-DATA-HERE>&continue=https%3A%2F%2Faccounts.google.com%2FManageAccount%3Fnc%3D1&tcc=1&dbus=blogger&dbus=BR&dbus=googlesource

If the SIDT was not being invalidated after the first use, the attacker would be able to authenticate into the victim account through this attack.

Overall, the impact of this bug doesn't differ much from Bug 1687342, where Firefox was leaking the redirect URL via CSP reports. On that occasion, I made a video about how it could be used to compromise the Google account as previously described. You can check it @ https://youtu.be/FgdplWFBEso

Comment 3

[:Gijs (he/him)]

(In reply to Ademar Nowasky Junior from comment #2)

OAuth and probably other authorization mechanisms would suffer from this. In the most common scenario, the initial authorization endpoint is publicly exposed, and later in the redirection chain the access token is passed in a URL parameter.

OK, that more or less makes sense.

Implementations of the Single Sign-On are also affected. Google, for instance, uses the https://accounts.google.com/CheckCookie endpoint for authentication. Once the browser request this URL, a redirection chain initiates passing the authentication data in the SIDT parameter to authenticate the user into other sites (youtube, blogger, ...). One of the redirects would look like this:

https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=<SENSITIVE-DATA-HERE>&continue=https%3A%2F%2Faccounts.google.com%2FManageAccount%3Fnc%3D1&tcc=1&dbus=blogger&dbus=BR&dbus=googlesource

If the SIDT was not being invalidated after the first use, the attacker would be able to authenticate into the victim account through this attack.

Hm, and this works even when the requests are made from an img tag? Because I would have expected (a) that if the server response sends Content-Type: text/html (but maybe it doesn't for the redirect?) the browser stops the load and (b) that if the server sees a request Accept header of image/webp,*/*, and a Sec-Fetch-Dest: image header, it would not proceed...

Certainly seems like there's room for better defense in depth there, but I guess we might still have to investigate pasting the pre-redirect URI. This is unfortunate because besides the possibility of other issues I cited in my previous comment, it's less user-friendly for non-malicious cases...

Overall, the impact of this bug doesn't differ much from Bug 1687342, where Firefox was leaking the redirect URL via CSP reports. On that occasion, I made a video about how it could be used to compromise the Google account as previously described. You can check it @ https://youtu.be/FgdplWFBEso

And just to confirm, AIUI bug 1687342 involves no user interaction, whereas this requires convincing the user to right-click the image, copy the image link, and pasting it into the input field, right?

Comment 4

[Ademar Nowasky Junior]

Hm, and this works even when the requests are made from an img tag? Because I would have expected (a) that if the server response sends Content-Type: text/html (but maybe it doesn't for the redirect?) the browser stops the load

The browser will follow HTTP redirects regardless of the content-type value and will stop if it's blocked by the CSP or if the requested page returns another status code that isn't a HTTP redirect. This is what I experienced.

and (b) that if the server sees a request Accept header of image/webp,*/*, and a Sec-Fetch-Dest: image header, it would not proceed...

From my tests looks like servers don't care about the Accept and the Sec-Fetch-Dest headers.

Certainly seems like there's room for better defense in depth there, but I guess we might still have to investigate pasting the pre-redirect URI. This is unfortunate because besides the possibility of other issues I cited in my previous comment, it's less user-friendly for non-malicious cases...

Yeah, I agree. A solution that probably would no break non-malicious cases would be to paste the pre-redirect URI if the redirect(s) doesn't take to a valid image.

And just to confirm, AIUI bug 1687342 involves no user interaction, whereas this requires convincing the user to right-click the image, copy the image link, and pasting it into the input field, right?

You are right about this bug requiring user interaction. The similarity with Bug 1687342 is the data that is compromised and the final impact on the victim.

Comment 5

[Daniel Veditz [:dveditz]]

This is conflating "what the cross-origin page knows" (governed by the same-origin policy) and "what the user's agent (the browser) tells the user".

The document knows the original URL of the image it put in it's source. The same-origin policy says that's all that document should ever know about that URL -- any redirects on the network could be information from another context and should not be leaked back to that original page. This is not a perfect policy and some information is leaked such as whether the image loaded or was an error and that can sometimes be used to infer things about whether a redirect happened or not, but won't leak the full path back to the original document. Information can also be gleaned from applying CSP policies and what errors are returned, though you shouldn't be able to recover secrets that way.

"Copy Image URL" is information the browser knows (the real URL of the image) and shares with the user. Firefox believes that what the user most wants is the real source of that image after redirects since the redirects might be different in other contexts and result in a different image. Chrome, for one example, has chosen the original URL as the more useful value. But that is a feature of the browser and separate from the same-origin policy. This value is not leaked (by the browser) back to the containing page.

In this POC you're asking the user to share their information back with you, by interacting with the browser and then pasting the result back into a browser field. It is the user, via a "social engineering" attack, that has leaked the data to the page. To me, that part is not a Firefox "bug", and the Firefox "Copy Image URL" feature is more useful than Chrome's.

The above is not a security bug

A completely different problem, in my mind, is why we have a "Copy Image URL" menu item at all on an image that did not load! What the user is seeing is the background image, but if that's what's triggering the context menu item why aren't we giving the user the background image URL? Do we normally give the URL of broken images so the user can play with it in another context? Probably -- maybe a site prevents "deep-linking" but the image can be viewed directly?

I can accept that as useful, but then in this case we're stopping one URL short of where we know we redirected. Is that because the penultimate redirect was "successful" but the CSP block made the next one an error? But we're already letting the user in on the erroring image URL. Not sure if that's a bug or not, or if it is whether it's worth fixing. Not a security bug though, just a question of what's useful to the user.

Comment 6

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #5)

A completely different problem, in my mind, is why we have a "Copy Image URL" menu item at all on an image that did not load!

I think this was originally (20-25 years ago, when the web looked a bit different...) done for people who block images initially to speed things up, and then want to see specific ones by loading them separately. I think we still support this under the hood, though I'm pretty sure we removed most if not all of the UI...

What the user is seeing is the background image, but if that's what's triggering the context menu item why aren't we giving the user the background image URL?

Context menu code in general is pretty dumb; it uses the same model as web DOM event processing and just picks the "top" element, with no regard for transparency or anything else. Doing something different is possible, but not entirely straightforward (see for example all the bugs that got filed against our picture-in-picture overlay button, which attempts to ignore semi-transparent web elements). This is often what the user sees, but not always, like in this case.

Do we normally give the URL of broken images so the user can play with it in another context? Probably -- maybe a site prevents "deep-linking" but the image can be viewed directly?

This may be another angle, I'm not sure.

I can accept that as useful, but then in this case we're stopping one URL short of where we know we redirected. Is that because the penultimate redirect was "successful" but the CSP block made the next one an error?

AIUI this is the outcome of the image request's currentRequestFinalURI property, the implementation of which lives in DOM and imagelib...

But we're already letting the user in on the erroring image URL. Not sure if that's a bug or not, or if it is whether it's worth fixing. Not a security bug though, just a question of what's useful to the user.

Do you want to open this bug up? It kind of sounds like it, but you haven't. :-)

Comment 7

[Ademar Nowasky Junior]

In this POC you're asking the user to share their information back with you, by interacting with the browser and then pasting the result back into a browser field. It is the user, via a "social engineering" attack, that has leaked the data to the page. To me, that part is not a Firefox "bug", and the Firefox "Copy Image URL" feature is more useful than Chrome's.

It's an user interaction, just like the drag'n drop variant reported in Bug 1189814 that abused a browser feature to leak the redirect URL.

Indeed it's the user that is sharing the information, but the browser is allowing him to be tricked into doing so by copying the sensitive ULR from an image that is being shown as another one.

Comment 8

[Daniel Veditz [:dveditz]]

It's a fuzzy line. To me the drag-and-drop case was a plausible user interaction that could be conceptualized as a single movement (say in a game) that led to a surprising result because the browser, not the user, was revealing something. In this case the page has to ask the user to 1) right-click or "open the context menu", 2) explicitly chose "copy link" and then 3) give the link back to the page. That's unusual and suspicious, though I admit I am more suspicious than most.

Do you want to open this bug up? It kind of sounds like it, but you haven't. :-)

I'm not 100% sure so it's safer to leave it as a sec bug a bit longer. If we were returning the final URL of a valid image I'd say it's not even a bug, let alone a security one. I'm less keen on it when there are redirects and there were errors loading the image. CSP induced in this case, but there could be other reasons: for example, a facebook link redirecting to the user's profile wouldn't load as an image, but could reveal their username.

I was hoping to get a few other folks to chime in.

fwiw this behavior was added in bug 1406253, which seems suspiciously recent. Did Firefox really return the original src URL in its first decade plus?

Comment 9

[Ademar Nowasky Junior]

Attachment: poc2.html

(In reply to Daniel Veditz [:dveditz] from comment #8)

It's a fuzzy line. To me the drag-and-drop case was a plausible user interaction that could be conceptualized as a single movement (say in a game) that led to a surprising result because the browser, not the user, was revealing something. In this case the page has to ask the user to 1) right-click or "open the context menu", 2) explicitly chose "copy link" and then 3) give the link back to the page. That's unusual and suspicious, though I admit I am more suspicious than most.

I get your point, although my POC shows an unusual scenario that demonstrates the issue but certainly doesn't reflect how it could be abused in a real attack.

I took the time to create another one, where the user has the option to choose images from another site, which sends through post message to the opener the URL of the safe image that the user chooses. When the user pastes the chosen URL, which is in fact the sensitive URL, the site intercepts the paste operation and actually paste the safe image URL that was received before, updates the image preview and replaces the clipboard data with the safe image URL to clear up any trace. The sensitive URL is printed to the console.

Check the new attached POC.

Heres's a video of it: https://youtu.be/H3U_eOjMJ7Y

Comment 10

[Andrew McCreight [:mccr8]]

Marking it sec-low for now because it requires a lot of user interaction and isn't clear that the middle URL in a redirect chain is any worst than the last in general.

Comment 11

[Daniel Veditz [:dveditz]]

This PoC is more plausible, but it's still oddly "hard" for users for any serious site. yes, handwaving about a "partner" site, which yet isn't partner enough to make "click on the image you want" work? I'm sure it will work on some people.

Incidentally, if you "Copy Image" instead of copying the link you get the image you want out of this testcase without leaking anything :-) In Chrome, however, "Copy Image" is disabled (grey) because it's a broken image (so the background image can't be used to fool users).

Initially I was thinking that CSP blocking might be the problem, that if only blockages were handled differently we could return the innocuous blocked-by-CSP "https://example.org" rather than the redirect with the secret. But there's no guarantee the CSP block in this scenario is on the last URL. If we changed the behavior to return the "last known URL" then Ademar could simply change the testcase CSP to block bit.ly and we're back to leaking secrets if you can lure a user into copy/paste.

There aren't many people around who were involved in bug 1406253. I'm not entirely sure about the motivation, though I can guess it can be handy at times. This divergence from Chrome behavior has also caused problems for people writing extensions: see bug 1659155 (and other bugs where people complain about our behavior).

I see 3 main choices:

1. always report the in-source/pre-redirect URL.
   • pro:
     • matches Chrome; consistency is good for devs
     • no potential info leak
     • easy change
   • con:
     • undoes bug 1406253.
     • Not as easy to get the actual image URL for devs? I can't find much of a way to get the final URL of the image in DevTools after the fact. You pretty much have to open the console (logging requests) or the network tab before loading the page to see that the in-content src= redirects. Or you can open the Browser Console and try to pick it out amongst all the other messages from the browser chrome. You could also "open image in new tab" to see the final URL, if the final URL doesn't depend on the page context (an anti-deep-linking site might block the load).
2. report the pre-redirect URL for --broken-- images, the final URL for valid images
   • pro:
     • preserves the current convenience when it matters most
     • prevents attacks like this one or against non-image URLs like a social site homepages that redirect to something with your account name.
   • con:
     • can still leak final URLs of valid images, if any of those are sensitive (maybe avatar links?). Should be pretty limited though
     • Is it hard to detect that the image didn't load at the point we're setting this value? Is the onerror status saved anywhere handy?
3. Do nothing
   • pro:
     • least effort
     • preserves whatever bug 1406253 was doing
   • con:
     • luring attacks like this one, that are likely small scale given complexity and risk of detection if used on too many victims
     • possible that the in-source URL was more canonical and therefore more useful than the redirect which might be to some transient cached version. Silly example: a weather graphic showing current conditions by redirecting from the canonical URL to different end images at different times based on your location (cookies? geo-ip?). Of course the source URL can be easily found using DevTools or even the ancient Page Info Media tab.

You could argue a reasonable case for any of those options. I kind of like #2 as a compromise, but maybe it's better to either match Chrome (#1) or not bother (#3). There are still some edge case info leaks with #2 and a partial fix just invites more bug submissions (just as this bug references bug 1189814). The OAuth case worries me though, even though this could only be a small-scale or targeted attack. Not every OAuth-using site would be vulnerable -- most bounce from siteA->Auth->siteA and this bug's technique wouldn't work there.

Dao: you were involved a little bit in bug 1406253. Do you know more of the history behind that change?

Comment 12

[Ademar Nowasky Junior]

FYI, I've sent to Google a PoC that abuses this behavior to leak an authentication token from their login flow. Although they can protect themselves by checking for the Sec-Fetch-Dest: image header, they think this may be a security issue on Firefox and would like to discuss it with Mozilla.

I'm not sure how to proceed from here. I've shared with them the bug number but probably someone from Mozilla should allow them to access it.

Comment 13

[:Gijs (he/him)]

(In reply to Ademar Nowasky Junior from comment #12)

FYI, I've sent to Google a PoC that abuses this behavior to leak an authentication token from their login flow. Although they can protect themselves by checking for the Sec-Fetch-Dest: image header, they think this may be a security issue on Firefox and would like to discuss it with Mozilla.

I'm not sure how to proceed from here. I've shared with them the bug number but probably someone from Mozilla should allow them to access it.

--> Dan?

Comment 14

[Daniel Veditz [:dveditz]]

They should know how to reach us already but I haven't seen anything. If they want to start a discussion in mail separate from this bug they can send to [e-mail], and if they'd like to take part in this bug we can add them to the CC list if they have an account on Bugzilla (which I guess also involves sending mail to that address to let us know who they are and that they're interested).

Comment 15

[Daniel Veditz [:dveditz]]

I'm more strongly preferring option #1 now, with the understanding that I'm not proposing completely reverting bug 1406253. There are several image-related operations on the context menu. The change in bug 1406253 was about making them do what a user expected if the URL was modified by an extension via the WebRequest API, since the extension couldn't make the same alteration when the image was handled by the privileged context menu code. We could revert "Copy Image Link" to the URL in the image link to fix this problem, while continuing to use the final URL for the rest ("Open Image in New Tab", "Save Image As...", "Copy Image", "Email Image", and "Set Image as Desktop Background" -- did I miss any?).

It's fortuitous this context menu label recently changed in bug 1690561. The previous text, "Copy Image Location", would more likely be understood by users as implying the image's final URL, while "Link" gives us more leeway to make this change.

If someone really needs to copy the final URL they could "Open Image in New Tab" and copy the URL from there, or use DevTools to observe the network requests. Most of the time this workaround won't be necessary and users won't notice a difference, since the two URLs will be identical or the first will reliably redirect.

Comment 16

[Frederik Braun [:freddy]]

I concur with your preference, Dan: We should fix this for "Copy Image Links" and match Chrome behavior.
Even though, we rate this one as "sec-low", I want to acknowledge that abusing "Copy Image Link" to steal cross-origin tokens is a nice trick.
This attack requires an unexpected user interaction, we can't expect users to understand that the "Image Link" is in fact a link to non-image content that contains sensitive URL information. So, it's really worth fixing.

(As an aside, I fully expect high-value websites to defend against attacks like this, by employing a reasonable "Sec-Fetch-Dest" check as a mitigation. Furthermore, I'd expect a check that isn't denying "image" destinations, but rather allowing the intended and expected destinations only).

Comment 17

[arturjanc]

The discussion on this bug is already quite comprehensive, but I figured I'd chime in with a couple of additional comments in favor of Option 1:

1. As the reporter notes, there are a number of common, sensitive auth flows (including Google's) where a secret token gets appended in a redirect URL. The current behavior leads to a situation where copy-and-pasting an image URL can lead to account takeover; while this does require social engineering, it seems like an unnecessary footgun.

2. The web platform protects post-redirect URLs from being revealed cross-origin (e.g. in CORS or for CSP reporting: https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html). Since this is already an important security boundary, upholding it in this case is probably also a good idea.

Re: Sec-Fetch-Dest, in principle sites can use it to reject requests that would be problematic here. However, in this particular case the endpoint which appends the token to the URL likely needs to support both navigations and resource loads (e.g. if a resource is legitimately loaded as an <img> but the credentials expired, the server can redirect to the endpoint which appends the token, which will then redirect back to the resource). In this case Sec-Fetch-Dest: image would be a legitimate value for that endpoint, so it may not be possible to denylist it.

Comment 18

[Frederik Braun [:freddy]]

Thanks for the note about Sec-Fetch-Dest, Artur.

It seems we're all in agreement on how to fix this. Let's get this assigned.

Comment 19

[Ademar Nowasky Junior]

I've come up with a slightly different technique to intercept a redirect chain that uses a content-security-policy-report-only: img-src header and listen for the securitypolicyviolation event to infer which redirect step is being requested. Once the desired redirect step is reached, a call to window.stop() is made to stop the redirection chain.

This technique brings two major advantages for the attack:

(In reply to Ademar Nowasky Junior from comment #2)

If the SIDT was not being invalidated after the first use, the attacker would be able to authenticate into the victim account through this attack.

1. Now the redirect chain is aborted before the targeted redirect URL is submitted to the network. This is useful in those cases where the target URL contains a token that would be invalidated after the first use.

(In reply to Daniel Veditz [:dveditz] from comment #11)

The OAuth case worries me though, even though this could only be a small-scale or targeted attack. Not every OAuth-using site would be vulnerable -- most bounce from siteA->Auth->siteA and this bug's technique wouldn't work there.

2. Now it should work on cases like URL1->AUTH->URL1 where leaking the AUTH URL would not be possible with the previous technique that used a regular content-security-policy header to intercept the redirect chain.

The PoC I've sent to Google used this method to leak a valid token from their login flow. It shows a scenario where a "Search by Image" website instructs the user into searching for an image that is being displayed while being overlapped by the invisible malicious image tag.

PoC: https://storage.googleapis.com/nowa0/gvrp/index.html
Video: https://youtu.be/80YsDLBo2Kc

Comment 20

[Dão Gottwald [:dao]]

(In reply to Daniel Veditz [:dveditz] from comment #11)

Dao: you were involved a little bit in bug 1406253. Do you know more of the history behind that change?

Sorry, no, but the plan you have agreed upon sounds good to me. I can take care of implementing this.

Comment 21

[Dão Gottwald [:dao]]

Attachment: Bug 1719203 - Let "Copy Image Link" use the original URL before redirects. r=gijs

Comment 22

[Rob Wu [:robwu]]

Once this bug is resolved, check whether bug 1644802 should be marked as a duplicate of this one.

Comment 24

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Let "Copy Image Link" use the original URL before redirects. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/bda4a0ce2d5ccb6e820818859ff03d8e7cd31001
https://hg.mozilla.org/mozilla-central/rev/bda4a0ce2d5c

Comment 25

[Ademar Nowasky Junior]

(In reply to Ademar Nowasky Junior from comment #19)

I've come up with a slightly different technique to intercept a redirect chain that uses a content-security-policy-report-only: img-src header and listen for the securitypolicyviolation event to infer which redirect step is being requested. Once the desired redirect step is reached, a call to window.stop() is made to stop the redirection chain.

This technique brings two major advantages for the attack:

(In reply to Ademar Nowasky Junior from comment #2)

If the SIDT was not being invalidated after the first use, the attacker would be able to authenticate into the victim account through this attack.

1. Now the redirect chain is aborted before the targeted redirect URL is submitted to the network. This is useful in those cases where the target URL contains a token that would be invalidated after the first use.

(In reply to Daniel Veditz [:dveditz] from comment #11)

The OAuth case worries me though, even though this could only be a small-scale or targeted attack. Not every OAuth-using site would be vulnerable -- most bounce from siteA->Auth->siteA and this bug's technique wouldn't work there.

2. Now it should work on cases like URL1->AUTH->URL1 where leaking the AUTH URL would not be possible with the previous technique that used a regular content-security-policy header to intercept the redirect chain.

The PoC I've sent to Google used this method to leak a valid token from their login flow. It shows a scenario where a "Search by Image" website instructs the user into searching for an image that is being displayed while being overlapped by the invisible malicious image tag.

PoC: https://storage.googleapis.com/nowa0/gvrp/index.html
Video: https://youtu.be/80YsDLBo2Kc

@Daniel, will this meet the bar for a reward? Thanks

Comment 26

[Andrew McCreight [:mccr8]]

(In reply to Ademar Nowasky Junior from comment #25)

@Daniel, will this meet the bar for a reward? Thanks

The bounty committee usually meets once a week, and will probably discuss this now that the issue has closed. Their decision will get posted in the bug.

Comment 27

[Ademar Nowasky Junior]

(In reply to Andrew McCreight [:mccr8] from comment #26)

(In reply to Ademar Nowasky Junior from comment #25)

@Daniel, will this meet the bar for a reward? Thanks

The bounty committee usually meets once a week, and will probably discuss this now that the issue has closed. Their decision will get posted in the bug.

Alright! Thanks

Comment 28

[:Gijs (he/him)]

Are we fine with this riding the trains or do you want 93 uplift? Last beta is today, AIUI.

Comment 29

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

For verifying this bug I used the test cases provided (poc.html, poc2.html and poc3 - comment 19) and the steps from duplicate bug 1644802.

I can confirm that the scenario described in bug 1644802 no longer reproduces with latest Nightly 94.0a1 2021-09-26.

As for the testcases attached to this bug (poc.html and poc2.html), I see no difference between 92RC (affected) and latest Nightly (fixed). The pop-up and the console errors are the same in both Firefox versions.
For https://storage.googleapis.com/nowa0/gvrp/index.html (comment 19), the image is not loaded neither in Nightly nor in older Fx versions.

Can someone please advise on how to further verify this bug using the provided testcases? Thank you!

Comment 30

[Ademar Nowasky Junior]

(In reply to Petruta Horea [:phorea] from comment #29)

For verifying this bug I used the test cases provided (poc.html, poc2.html and poc3 - comment 19) and the steps from duplicate bug 1644802.

I can confirm that the scenario described in bug 1644802 no longer reproduces with latest Nightly 94.0a1 2021-09-26.

As for the testcases attached to this bug (poc.html and poc2.html), I see no difference between 92RC (affected) and latest Nightly (fixed). The pop-up and the console errors are the same in both Firefox versions.
For https://storage.googleapis.com/nowa0/gvrp/index.html (comment 19), the image is not loaded neither in Nightly nor in older Fx versions.

Can someone please advise on how to further verify this bug using the provided testcases? Thank you!

poc.html and poc2.html are now with broken links so they will not work anymore.

To verify this bug using the https://storage.googleapis.com/nowa0/gvrp/index.html PoC, you may need to disable Firefox Enhanced Tracking Protection and make sure you are logged into a Google account.

The bug seems to be fixed on 94.0a1 (2021-09-27).

Comment 31

[Dão Gottwald [:dao]]

I don't think we should uplift this.

Comment 32

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

Tested on latest Nightly 94.0a1 using Win 10 64-bit and Mac OSX 10.14.6.

(In reply to Ademar Nowasky Junior from comment #30)

poc.html and poc2.html are now with broken links so they will not work anymore.
To verify this bug using the https://storage.googleapis.com/nowa0/gvrp/index.html PoC, you may need to disable Firefox Enhanced Tracking Protection and make sure you are logged into a Google account.
The bug seems to be fixed on 94.0a1 (2021-09-27).

Thank you!

I followed the instructions, however the image is still not displayed. Right clicking and then selecting "Paste" in the "Paste the Image Link" field, does paste the image url. First time I try on a clean profile, it will show bellow the Leaked URL: <address bar url> (or nothing) and the next times I try, the imgur url is shown as leaked: Leaked URL: https://i.imgur.com/9qfP4d9.jpg.

The following error is displayed in the web console:
Uncaught leak :) index.html:293:21 onpaste https://storage.googleapis.com/nowa0/gvrp/ index.html:293 receiveMessage resource://gre/actors/ControllersChild.jsm:14

Chrome browser has the same behavior. I wasn't able to expose the google account. Based on this and the above comments I'm marking this as verified.

Comment 33

[Ademar Nowasky Junior]

Any plans to uplift this to Firefox ESR?

Comment 34

[Rob Wu [:robwu]]

This bug requires considerable user interaction for exploitation, and depends on specific circumstances for a website in order to be security-sensitive. I'm 50/50 on this one, I'd be fine with uplifting, but also fine if we did not.

Gijs/Dao: Should we uplift the fix in this bug and bug 1659155 to ESR91?

Comment 35

[:Gijs (he/him)]

(In reply to Rob Wu [:robwu] from comment #34)

This bug requires considerable user interaction for exploitation, and depends on specific circumstances for a website in order to be security-sensitive. I'm 50/50 on this one, I'd be fine with uplifting, but also fine if we did not.

Gijs/Dao: Should we uplift the fix in this bug and bug 1659155 to ESR91?

Dão said no earlier:

(In reply to Dão Gottwald [::dao] from comment #31)

I don't think we should uplift this.

but I'm not sure if that was just about beta 93; we have more baking time to consider for 91. Either way, I defer to Dão's judgment.

Comment 36

[Tom Ritter [:tjr]]

Attachment: advisory.txt