Bug 1162372 (CVE-2015-4476)

Custom URI schemes in the location bar can lead to URL & SSL spoofing

RESOLVED FIXED in Firefox 41

Status

()

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: jordi.chancel, Assigned: mcomella)

Tracking

(Blocks 1 bug, {csectype-spoof, sec-moderate})

39 Branch
Firefox 42
ARM
Android
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty +
in-testsuite ?

Firefox Tracking Flags

(firefox39 wontfix, firefox40- wontfix, firefox41+ fixed, firefox42+ fixed, firefox-esr31 unaffected, firefox-esr38 unaffected)

Details

(Whiteboard: [post-critsmash-triage][adv-main41+], )

Attachments

(8 attachments, 1 obsolete attachment)

Reporter

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150415140819

Steps to reproduce:

Copy a wrong URL format address like : secure://www.google.com or httpZ://www.google.com , past it in the location bar (just past it for the moment), and after try to go on this wrong URL lead to URL and SSL spoofing (the url of the malicious website is changed by secure://www.google.com and if the malicious website have a valid SSL , the wrong URL appear to be secure like a website with SSL connexion).

-1 : copy a wrong URL format like httpZ://www.google.com and past it on the location bar
-2 : after past this wrong URL , try to go on this address




Actual results:

The location bar show the wrong URL format address (httpZ://www.google.com) and if the website where you copy/past this address have a valid SSL connexion , the wrong URL address appear like secured like a website with SSL.


Expected results:

The location bar show the wrong URL format address (httpZ://www.google.com).
The wrong URL address can appear like secured like a website with SSL.
Reporter

Comment 1

4 years ago
Posted file testcase1.html
use this testcase , copy the URL of the link , past it into the location bar , and after try to go on this wrong URL. 

Result:
The URL is changed by the wrong URL format (wrong address) , and if the website of the tab was secure by SSL , the wrong address appear like secure too.
Reporter

Comment 2

4 years ago
i will upload a video of demonstration quickly for show you the real impact of this vulnerability.
Reporter

Comment 3

4 years ago
This is the video of demonstration of the exploitation with the testcase uploaded.
I keep getting searches when I paste the urls... have you disabled something?
Flags: needinfo?(jordi.chancel)
Reporter

Comment 5

4 years ago
no i haven't disabled something. the configuration is normal.
Flags: needinfo?(jordi.chancel)
Reporter

Updated

4 years ago
Whiteboard: [On the demonstration video I use a Samsung Galaxy s5 4g+]
Confirmed the above on Fx38 on Android. The address bar is successfully spoofed with fake protocol and domain.

(Note: Fennec only, not desktop.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug satisfies the requirement of a sec-high rating, as it successfully spoofs the address bar with a reasonable human interaction. Technically, it does not spoof SSL, as "secure://" is not a valid protocol, but that does not affect the rating.
Keywords: sec-high
I have been unable to reproduce this. I get the same results as Dave, searches or error message stating not a valid url if I use paste and go.
This is the latest Firefox 38.0.1 - screenshot attached.
In 41 Nightly I get:

* Paste & Go: "Couldn't find an app to open this link". Page doesn't open.
* Paste, hit enter: blank page loads, "Couldn't find an app to open this link" shows, favicon is preserved from previous page.

Once I managed to get a page to load, but I can only repro from within the test case HTML attachment.
Summary: copy/past and wrong URL format in the location bar and try to go on this wrong URL can lead to URL & SSL spoofing → Pasting wrong URL format in the location bar can lead to URL & SSL spoofing
The URL doesn't have to be pasted - any url entered with an unknown scheme will attempt to open an associated Android app. It looks like a feature that used to be in Chrome (v18-) but was removed in favor of intent:// URIs (v25+; see bug 851693 for intent:// URIs) [1].

An example STR:
  * Open https://google.com
  * Open httpz://google.com

I think the easiest solution, since Chrome has removed this and they are the default on Android, is to just remove this functionality in favor of intent URIs.

[1]: https://developer.chrome.com/multidevice/android/intents
Summary: Pasting wrong URL format in the location bar can lead to URL & SSL spoofing → Custom URI schemes in the location bar can lead to URL & SSL spoofing
(In reply to Michael Comella (:mcomella) from comment #11)
> The URL doesn't have to be pasted - any url entered with an unknown scheme
> will attempt to open an associated Android app.

To be explicit, what we currently do here is get a new URL, thus update the displayed url/title, we can't load it so we don't change the page content, favicon, or lock, and we show a toast. This handling behavior just happens to allow spoofing.
And thus an alternative fix is to just not update the title, but I imagine Chrome broke backwards-compatibility for a reason.
I'd be really surprised if google deprecated their scheme handling code. For instance, this Sonos:// link works fine for me in both them and us:

https://people.mozilla.org/~wjohnston/sonos.html

I doubt they special cased sonos (but maybe!). We know if there are apps to handle a scheme. We probably need to show an error of some sort if we can't figure out where to go (we do show an error, but right now its a ButtonToast that's easily missed). The entire "search" bit of that toast could actually be handled as an error page widget now!

My vote is that we remove this code:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/ContentDispatchChooser.js#52

and instead of show an error page. We'll already have a "search" button on that page to search for the url. If we want, we can special case it to show a "Search Android market" widget.

We also probably shouldn't keep the typed url around in the urlbar if it isn't loading. We show it quickly for perf reasons.
(In reply to Wesley Johnston (:wesj) from comment #14)
> My vote is that we remove this code:
> 
> http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/
> ContentDispatchChooser.js#52
> 
> and instead of show an error page. We'll already have a "search" button on
> that page to search for the url. If we want, we can special case it to show
> a "Search Android market" widget.

WFM but let's not yak shave... (I filed bug 1169091).

> We also probably shouldn't keep the typed url around in the urlbar if it
> isn't loading. We show it quickly for perf reasons.

This ^ is the real issue - I'll investigate.
Assignee: nobody → michael.l.comella
We set the title immediately upon hitting enter in commitEditingMode:

https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/toolbar/BrowserToolbar.java?rev=2a0c51e9039d#811

so this only affects values directly entered by the user.

We can either intercept this call if we have suspicion that the url is not valid (seems complex), or change the url back when we realize the page can't load (which will cause a flicker and look a bit unpolished).
(In reply to Michael Comella (:mcomella) from comment #16)

> We can either intercept this call if we have suspicion that the url is not
> valid (seems complex), or change the url back when we realize the page can't
> load (which will cause a flicker and look a bit unpolished).

We usually leave user input in the case of a failure to load, because it's likely that they've typoed something and will want to fix it.

Michael, have you conclusively determined that we're not loading anything here? The video certainly makes it look like a page loads.

If not, this bug should probably be reworded; it's basically "users can paste stuff that looks like a URL without a page loading", which doesn't meet my definition of spoofing.
New thought: we should open the application if it's available, otherwise search with the URL. This avoids the issue of:

(In reply to Richard Newman [:rnewman] from comment #17)
> We usually leave user input in the case of a failure to load, because it's
> likely that they've typoed something and will want to fix it.

But to answer your questions:

> Michael, have you conclusively determined that we're not loading anything
> here? The video certainly makes it look like a page loads.

We don't load anything. The linked video uses the code from the attached test case:

  document.addEventListener("touchstart", function(e){
  setTimeout('document.body.innerHTML = \'<b>I am not <u>google</u> at all and <u>i am not secure</u></b>\';',9500);
  }, false);

I think this means we'd already have to be on a malicious site in order to be compromised.
OK, makes sense. In which case the only 'attack' is:

* You go to a malicious site.
* The site tells you to copy and paste in the URL bar.
* You paste something that doesn't load. You see the popups saying "Couldn't find an app to open this link".
* You look at the URL bar and decide that whatever's showing in the viewport is now the URL you pasted.

That's a lot less worrying than the initial description made it sound. And not affecting Paste & Go is nice.


So yeah, our choices to improve this situation are:

1. If we fail to load a URL (particularly because of the scheme), stay in editing mode. When you leave editing mode, return the URL bar to the URL of the current page.

2. If we fail to open a URL, do a search. This might not make sense if it's because the scheme was unrecognized, and it might leak data (e.g., pasting mailto: and ending up on Google).

3. Load an error page (like about:neterror, but perhaps less error-ey), prepopulating the search field with the URL.


I'm kinda in favor of the first or third options -- if you're trying to navigate to a page and you get it wrong, I don't see much reason to leave you focused on the current page and allow it to do whatever it wants. The difference between 1 and 3 is that in 1 you need to hit Back to get back to the malicious page, and in 3 we always navigate you away.

Thoughts, Michael?
(In reply to Richard Newman [:rnewman] from comment #19)
> I'm kinda in favor of the first or third options -- if you're trying to
> navigate to a page and you get it wrong, I don't see much reason to leave
> you focused on the current page and allow it to do whatever it wants. The
> difference between 1 and 3 is that in 1 you need to hit Back to get back to
> the malicious page, and in 3 we always navigate you away.

I like 3 - it gives the user the option to search (which they may have been trying to do anyway) and it gives a clear indication that the URL they entered had gone through.

In 1, I feel like hitting enter and having nothing change can be unintuitive, especially because we'll likely just show a toast (which can be easily missed, e.g. tab queue, especially when their focus is on the top of the screen, on the url bar). Also, there's much less text space to explain what's going on to the user.

That being said, the code handling our Intent interactions is in Gecko-land (I've similar digging for the followups to bug 851693), code which I don't understand well so a proper fix for this will take a bit.
Flags: sec-bounty?
Status: NEW → ASSIGNED
Whiteboard: [On the demonstration video I use a Samsung Galaxy s5 4g+]
Any updates on a patch for this issue? This is an extant sec-high rated issue.
Flags: needinfo?(michael.l.comella)
Reporter

Updated

4 years ago
OS: Unspecified → Android
Hardware: Unspecified → ARM
Reporter

Updated

4 years ago
Version: Firefox 37 → Firefox 39
(In reply to Al Billings [:abillings] from comment #21)
> Any updates on a patch for this issue? This is an extant sec-high rated
> issue.

It is now my top priority (though I'll be mostly off for the next two days).

Anthony, I'm going to make scheme:// urls typed in the url bar go to an error page (if possible) like the one I just attached, just with different text. Do you have any UI decisions you want to see there, or should I just show you the prototype when I have it?
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(alam)
Or we can be consistent and do what desktop does (see attachment): declare "the address was not understood".

I like this approach (and will implement it without antlam suggestions) but with a search for the play store, like our server not found screen.

v1 can skip the search box though.
Sure, show me a build when you get the chance. Reading the bug, I still think I need a bit more context for this one, and the build will help.
Flags: needinfo?(alam)
Apparently, it was built in.

Note that unlike most other links (and desktop), the uri in the url bar is updated to about:neterror, which is a bit user unfriendly.

Margaret, if you know how to fix this, please help!
Anthony, here's a build: https://people.mozilla.com/~mcomella/apks/mcomella-1162372_01.apk

To repro:
  1) hit the url bar, type "sonos://" and enter.
  2) Go to https://people.mozilla.org/~mcomella/test/uri.html and click the "sonos://" url (a more typical user flow).
Flags: needinfo?(alam)
Comment on attachment 8635620 [details] [diff] [review]
Load about:neterror when we can't load a uri w/ a custom scheme

Review of attachment 8635620 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/IntentHelper.java
@@ +181,2 @@
>              // Don't log the URI to prevent leaking it.
> +            Log.w(LOGTAG, "Unable to handle URI - loading about:neterror");

Do we need to worry about this in the other error cases above? In what cases would Intent.parseUri fail, and could that leave us open to the same vulnerability? Also, from a UX perspective, it seem like showing an error page is generally better than just showing a toast, if the user is trying to load the URL through the urlbar.
Attachment #8635620 - Flags: review?(margaret.leibovic) → review+
Also, comment 26.
Flags: needinfo?(margaret.leibovic)
(In reply to Michael Comella (:mcomella) from comment #29)
> Also, comment 26.

(should probably be a follow-up to keep the fix simple)
(In reply to :Margaret Leibovic from comment #28)
> Do we need to worry about this in the other error cases above?

I'm not sure, but I agree that the toast is a bad user experience so let's open the error page - good catch.
Looked at the error page with Mcomella. Definitely better than a toast.
Flags: needinfo?(alam)
Attachment #8635620 - Attachment is obsolete: true
Comment on attachment 8636815 [details] [diff] [review]
Load about:neterror when we can't load a uri w/ a custom scheme

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
  I think it's pretty non-obvious what we fixed here.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
  I don't think so.

Which older supported branches are affected by this flaw?
  38-42.

If not all supported branches, which bug introduced the flaw?

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
  I have not tried to create them but this may just apply to all of them. It seems fairly low risk to me - we're just loading an existing error page instead of the current error flow of showing a toast.

How likely is this patch to cause regressions; how much testing does it need?
  Unlikely - see above.
Attachment #8636815 - Flags: sec-approval?
Comment on attachment 8636815 [details] [diff] [review]
Load about:neterror when we can't load a uri w/ a custom scheme

sec-approval+ for trunk. We should get patches made and nominated for Aurora and Beta as well.
Attachment #8636815 - Flags: sec-approval? → sec-approval+
The same patch applies cleanly to 41 (though I have yet to build and test it) while 40 will require some work - the intent handling changes, starting in bug 851693, didn't land in 40 and so the exit points are different.

The changes would go in ContentDispatchChooser.ask [1], which currently displays a native toast: 
 win.NativeWindow.toast.show(failedText, "long", {

Presumably we just load the error url instead.

NI self to build/test aurora and write a branch patch for beta.

[1]: http://mxr.mozilla.org/mozilla-beta/source/mobile/android/components/ContentDispatchChooser.js?rev=c474691b9c0f#51
Flags: needinfo?(michael.l.comella)
FTR, my aurora and beta builds appear to be broken so this could take a while – I'll NI someone else to test if it goes on too long.
Fixed the build (bug 729752).

Aurora branch patch seems to work and I'll build 40 when I get the chance.
(In reply to Michael Comella (:mcomella) from comment #26)
> Created attachment 8635621 [details]
> about:neterror, post patch
> 
> Apparently, it was built in.
> 
> Note that unlike most other links (and desktop), the uri in the url bar is
> updated to about:neterror, which is a bit user unfriendly.
> 
> Margaret, if you know how to fix this, please help!

I don't believe this happens for the usual neterror case, like if you try to navigate to a page while you don't have network connectivity, so I bet this has to do with the fact that we're loading about:neterror directly in this patch.

There is special docshell logic that handles loading neterror pages in the usual case, so maybe there's something we should be doing instead of directly loading about:neterror in this case. I would ask around in #developers to see if there's a better way to show an error page. Looking at blame in docshell, this logic is really old, so you may need to rely on someone like bz for an answer.
Flags: needinfo?(margaret.leibovic)
Had some realizations after talking to MattN:

(In reply to :Margaret Leibovic from comment #40)
> I don't believe this happens for the usual neterror case, like if you try to
> navigate to a page while you don't have network connectivity, so I bet this
> has to do with the fact that we're loading about:neterror directly in this
> patch.

Loading about:neterror directly on desktop and Android updates the title appropriately but leaves the url that was typed in the url bar (e.g. loading about:neterror directly shows the url about:neterror). On phones, we only show one (title or url) and default to showing the url. On tablet, this looks fine.

The issue is we should be showing the failed url is the url bar (like when network connectivity fails), rather than about:neterror.
Same patch on 41 & 40 branch patch appear to work as expected - what's next?
Flags: needinfo?(michael.l.comella) → needinfo?(abillings)
Just nominate the patch for Aurora and Beta and one of us will approve it (either I or release management).
Flags: needinfo?(abillings)
Comment on attachment 8636815 [details] [diff] [review]
Load about:neterror when we can't load a uri w/ a custom scheme

Approval Request Comment
[Feature/regressing bug #]: N/A
[User impact if declined]:
  Users can be spoofed by a page when they do not have an application installed to handle certain links.
[Describe test coverage new/current, TreeHerder]:
  Tested locally.

[Risks and why]: 
  Low - we have a Nightly & aurora tested code path that is opening a uri that has no application to handle it on Android (dipslay a toast), but instead we're changing that to open an error page via the well-tested loadUrl method. I think the worst that happens is that error url we'd like does not open (in favor for another erroring on the error url) because I screwed url encoding.

[String/UUID change made/needed]: None
Attachment #8636815 - Flags: approval-mozilla-aurora?
Comment on attachment 8637257 [details] [diff] [review]
(WIP 40 branch) Load about:neterror when we can't load a uri w/ a custom scheme

Approval Request Comment: see previous comment for other fields
[Risks and why]: 
  Low - we are using a code path that has existed for a long time and making minimal changes to load a url. In the worst case, I did something bad in js and it errors on the edge case. -_- This code path is not the same as 41/42 though, so I'm a little concerned there may be an edge case I'm missing (e.g. maybe we changed something in 41/42 and so some calls won't go through this code path).
Attachment #8637257 - Flags: approval-mozilla-beta?
Attachment #8636815 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8637257 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I assume the aurora/beta patches will land through the usual processes?

I was under the impression that all of these patches should land together (and probably close to a Beta build) so that the window for exploit is reduced. Though, considering this patch non-obviously fixes the exploit, it's probably fine.
Flags: needinfo?(ryanvm)
Yes, it's on the radar to be uplifted later today once it's sufficiently green on fx-team. While we try to land them in close proximity, that doesn't mean we like to burn multiple trees at once :)
Flags: needinfo?(ryanvm)
(In reply to Michael Comella (:mcomella) from comment #47)

> I was under the impression that all of these patches should land together
> (and probably close to a Beta build) so that the window for exploit is
> reduced. 

 That's what sec-approval is for, to keep the window small. The assumption about the Beta build probably isn't correct though since we often need stuff to land on trunk and be clearly stable before we approve for Beta and Aurora.
https://hg.mozilla.org/mozilla-central/rev/d43113d59aab
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
(In reply to Matt Wobensmith from comment #7)
> This bug satisfies the requirement of a sec-high rating, as it successfully
> spoofs the address bar with a reasonable human interaction. Technically, it
> does not spoof SSL, as "secure://" is not a valid protocol, but that does
> not affect the rating.

That _absolutely_ affects the rating. spoofing is sec-low or at best -moderate. Spoofing the TLS indicators that people trust is the only way to nudge that up to a sec-high. ("hm, looks phishy, but I guess it's really my bank").
Flags: sec-bounty? → sec-bounty+
Using the steps from comment#0 and the testcase attached to this bug, I verified that the about:neterror page is displayed correctly and also that the wrong URL is displayed in editing mode
Whiteboard: [adv-main40+]
Alias: CVE-2015-4476
Regression in bug 1189957 - does not affect 39, affects 42, and I assume it affects 40-41
So 39 as "won't fix" is mismarked?
(In reply to Al Billings [:abillings] from comment #56)
> So 39 as "won't fix" is mismarked?

No - the current bug is fixed (and affects 39) but it caused another non-security bug 1189957 which affects 40 (because that's where these patches are first applied, thus wontfix 39).
As a heads up, my solution in bug 1189957 involves backing this fix out of 40 because the changes necessary to make bug 1189957 work the correct way are only in 41+.

This bug doesn't seem realistic to spoof in the wild, so I'd be okay with backing it out.
Reporter

Comment 59

4 years ago
I don't understand ,this vulnerbility will be in the advisories of firefox 40 notwithstanding?
Flags: needinfo?(michael.l.comella)
(In reply to Jordi Chancel from comment #59)
> I don't understand ,this vulnerbility will be in the advisories of firefox
> 40 notwithstanding?

I'm not sure I fully understand your question but I'll try to answer it – my proposed solution (which I'm trying to get approval for) includes backing out the 40 branch patch which would cause this vulnerability to exist in 40. Since the user has to type in the url bar, this spoofing doesn't seem realistic to perform in the wild – please correct me if I'm wrong – so I'm okay with it existing for one more version. Otherwise, we're hurting our users` flows in a rather important UX experience (plane tickets – imo, since the tickets on mobile devices experience tends to be stressful, screwing this UX up could be an instant way for users to stop using Firefox).
Flags: needinfo?(michael.l.comella)
Reporter

Comment 61

4 years ago
i just ask if this vulnerability will be an advisory for the firefox 40 update in https://www.mozilla.org/en-US/security/advisories/ for the week of august 11 ?
Flags: needinfo?(michael.l.comella)
I believe so. Al Billings runs this process.
Flags: needinfo?(michael.l.comella) → needinfo?(abillings)
(In reply to Michael Comella (:mcomella) from comment #60)

> I'm not sure I fully understand your question but I'll try to answer it – my
> proposed solution (which I'm trying to get approval for) includes backing
> out the 40 branch patch which would cause this vulnerability to exist in 40.
> Since the user has to type in the url bar, this spoofing doesn't seem
> realistic to perform in the wild – please correct me if I'm wrong – so I'm
> okay with it existing for one more version.

I'm not sure how we're going to back it out of 40 at this point. We're building release candidates at the beginning of the week. We aren't going to want to take code changes without an overwhelming reason. Is there a reason we can't ship *this* fix for 40, back it out in 41, and ship a different fix there? From a user point of view, as long as users are never vulnerable to this bug, I don't have an issue with that and that avoids code churn in our release candidates.

Jordi, if we ship this fixed in 40, it will get an advisory. If we don't fix it in 40 but ship a fix in 41, then an advisory will come out when 41 ships.
Flags: needinfo?(abillings) → needinfo?(michael.l.comella)
Lawrence, you may wish to weigh in here.
Flags: needinfo?(lmandel)
(In reply to Al Billings [:abillings] from comment #63)
> I'm not sure how we're going to back it out of 40 at this point.

I didn't consider the merge date when I mentioned this - if we're stuck, I guess we're stuck.

> Is there a reason
> we can't ship *this* fix for 40, back it out in 41, and ship a different fix
> there?

This fix causes bug 1189957, which prevents users from properly using the Delta website to check in for flights. If users try a different browser, they'll notice the check in process works and it'll reflect poorly on Firefox, particularly because the returned error is, "The address was not understood".

It's possible Delta are the only ones that use this hack, but it's more likely that others are also using it.

I'd prefer if it was backed out because it is a poor user experience and this bug doesn't seem to be easily usable by malicious parties (i.e. the user has to type in the url themselves), but I'm no security expert to know how reproducible this bug is in the wild.
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(sledru)
I don't think we would normally back out a sec bug fix once it's landed. But let's figure this out with Sylvestre involved, now that he's back. We haven't built the RC for mobile yet so we can probably straighten this out.
Also, given the few hours we have until Sylvestre can comment, is there a better fix that solves both problems? Or is it just a choice of which bug would we rather live with? Thanks!
Oh, android only! Sure, we can take a backout. It has been in mozilla-beta only for a week.
Maybe Delta can fix that for 41.

Ryan, could you backout this patch https://hg.mozilla.org/releases/mozilla-beta/rev/4a07d8bd97c8 ?
(both m-b & m-r)

Thanks!
Flags: needinfo?(sledru)
Flags: needinfo?(ryanvm)
Flags: needinfo?(lmandel)
Reporter

Comment 69

4 years ago
( about comment68 )

this vulnerability will be an advisory for the firefox 40 update in https://www.mozilla.org/en-US/security/advisories/ for the week of august 11 even if you backout the fix ?
Flags: needinfo?(sledru)
Flags: needinfo?(kbrosnan)
I think Al is going to remove it from the advisory list.
Flags: needinfo?(sledru)
Flags: needinfo?(kbrosnan)
https://hg.mozilla.org/releases/mozilla-beta/rev/073a16641001

Will merge to m-r when green on Treeherder.
Flags: needinfo?(ryanvm)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #71)
> https://hg.mozilla.org/releases/mozilla-beta/rev/073a16641001
> 
> Will merge to m-r when green on Treeherder.

merged to m-r https://hg.mozilla.org/releases/mozilla-release/rev/073a16641001
(In reply to Jordi Chancel from comment #69)
> ( about comment68 )
> 
> this vulnerability will be an advisory for the firefox 40 update in
> https://www.mozilla.org/en-US/security/advisories/ for the week of august 11
> even if you backout the fix ?

There will be no advisory for 40 for this if it isn't in 40, Jordi. 

It looks like this is moving to 41. Ryan, your change was a backout, right?
Flags: needinfo?(ryanvm)
Yes, per comment 68.
Flags: needinfo?(ryanvm)
Attachment #8637257 - Flags: approval-mozilla-beta+
Verified on FF 40 RC build 1 that the old functionality was restored.
Going to httpZ://google.com will open the "Couldn't find an app to open this link | Search" 
toast notification instead of the about:neterror page
Whiteboard: [adv-main40+]
My patch in bug 1189957 fixes the issue by loading the error page directly in the context from which it was loaded. In the delta case, this loads the error page in the invisible iframe, not affecting the main page content.
Duplicate of this bug: 1169091
Jordi, can you verify fixed in the latest Fx41?
Flags: needinfo?(jordi.chancel)
Whiteboard: [post-critsmash-triage]
Reporter

Comment 79

4 years ago
Yes i have tested this vulnerability on the last Fx41 beta and it is FIXED. ;)

Good job !
Flags: needinfo?(jordi.chancel)

Updated

4 years ago
Group: core-security → core-security-release
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main41+]
Depends on: 1258605
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.