1423883 - Loading a file after about:addons (or other parent process page) URL bar displays previous (wrong) URL after update-related restart (spoof)

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect, P5)

Description

[Abdulrahman Alqabandi]

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

Steps to reproduce:

Tested on Nightly 59.0a1 (2017-12-07) (64-bit).

1. When an update is available, navigate to about:addons (or any privileged about page)
2. In the same tab now navigate to a valid file:// location
3. Update firefox 




Actual results:

After restarting, you will notice the file is opened from step 2, yet the location points to 'about:addons'

Video: https://www.youtube.com/watch?v=dcSV0OhU3jk


Expected results:

No spoof.

This is harmless AFAIK since I can't repro using http, seems to only work with about pages + file:// pages as well as an update.

Also, I wasn't able to repro by restarting/refreshing/crashing nightly, only seems to work on update. If someone can find a way to repro without update (or how to trigger updates) let me know so I can further test this.

But in case this somehow can be done through http I will mark as sensitive. Remove at your discretion.

Comment 1

[:Gijs (he/him)]

This seems like a remoteness switching issue... Mike, any chance that the inability to repro could be due to pre-starting the "normal" web content process (which we wouldn't do for file: ) and if so, is there an easy way to disable that so we can test whether it reproduces with http: URIs if the process isn't pre-started?

As it stands, this bug seems sec-low, also because it'd be hard work as a website to enforce that you're loaded directly after something like about:addons (which you don't control, of course) in the same tab. However, if the pre-starting of the process is what's saving us here, that might mean there's just a race condition, which would effectively mean this *does* apply to http: . Of course, it's also possible there's some other reason these step cause problems with a file: URI and not with an http one...

Comment 2

[Daniel Veditz [:dveditz]]

In Nightly we have a different content process for file: content. I don't know when our sandbox added that, but possibly in 57 when we blocked file reading from the normal content process. Could be something to do with switching processes?

If that has something to do with it then it could well be limited to file: urls.

> only seems to work on update. If someone can find a way to repro without update
> (or how to trigger updates) let me know so I can further test this.

After each update you'll have to reinstall the old version, because updates will always take you to the latest. Unfortunately can't go step-by-step. You can change the update interval prefs so it checks every minute or something (please don't DOS our servers -- change it back when done!). Or you can change the update URL to a local server and serve copies of our update XML files that do the update you want (the meta data can still point to the Mozilla servers for the software)

Comment 3

[Abdulrahman Alqabandi]

I found one possible method involving the tab crash restore. The only reliable tab crash I have now is bug 1427287 so I will be using it for repro steps:

1. Install tab crash extension PoC from Bug 1427287 (or use your own)
2. Open new tab and navigate to 'about:addons'
3. Navigate to 'https://addons.mozilla.org/en-US/firefox/addon/e-307579-2/' which will cause tab crash error page
4. Deactivate installed extension
5. Click on 'restore tab'

You should be within 'https://addons.mozilla.org/en-US/firefox/addon/e-307579-2/' but the address bar shows 'about:addons'.

So this seems to work with http websites.

Comment 4

[Abdulrahman Alqabandi]

Should I file a separate bug for Comment 3? If not, could I/you change the title to reflect it?

Comment 5

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #4)
> Should I file a separate bug for Comment 3? If not, could I/you change the
> title to reflect it?

I can't tell, I can't see bug 1427287 so can't reproduce. Can you CC me?

TBH, I expect it's all the same issue and we should just deal with it here.

Comment 6

[Abdulrahman Alqabandi]

They seem to have different behaviors, specifically, why does http not work on update session restore but works on tab crash session restore? 

CC'd you on bug 1427287

Comment 7

[:Gijs (he/him)]

(In reply to Abdulrahman Alqabandi from comment #6)
> They seem to have different behaviors, specifically, why does http not work
> on update session restore but works on tab crash session restore? 

Not sure without diving in, for which I don't have cycles right now, but probably has to do with different processes for file:, web pages, about:addons, and the tab crash page. I don't know which is which here. Still, the elaborate STR mean it doesn't seem all that realistically exploitable, so I'm assuming we don't need to treat this as an urgent bug until/unless sec-severity says otherwise.

Comment 8

[Mike Conley (:mconley) (:⚙️)]

I can reproduce this. Here are the minimal STR I'm using:

1) Browse a tab to about:addons
2) Browser that same tab to http://www.example.com
3) Hover the mouse over the example.com tab to find the process ID
4) On MacOS and Linux, do:

kill -SIGKILL <process ID>

On Windows, open the Task Manager, choose Details, find the process that matches the process ID, and choose to End task

5) When about:tabcrashed appears in the example.com tab, click "Restore tab"

ER:

URL bar should show http://www.example.com

AR:

URL bar shows about:addons

Investigating.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

This code appears to be responsible for setting the URL bar to about:addons after restoring a tab that should point us at example.com (for the STR in comment 8):

https://searchfox.org/mozilla-central/rev/7fb999d1d39418fd331284fab909df076b967ac6/browser/components/sessionstore/SessionStore.jsm#957-975

It looks like the userTypedValue / userTypedClear isn't being cleared when we do the navigateAndRestore operation. I suspect this is related to the work that went on in bug 1241085.

Comment 10

[:Gijs (he/him)]

This wfm, I suspect it got fixed by parent-process document channel related changes.