1455575 - Untrusted content loading and rendering should be subject to WebExtensions in background services too (new tab thumbnails not affected by noscript)

Status: RESOLVED WORKSFORME

(WebExtensions :: Request Handling, defect, P2)

Description

[László Furmen (GMT+2)]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

install an addon which block javascript code (eg. NoScript addon)
open a page, without enabling javascript (tested with https://9gag.com/gag/anM77LE)
close the page
open a new tab


Actual results:

on the new tab under the HIGHLIGHTS section the previously opened page appears apparently with javascripts ran (because the page is not blank, content is shown)


Expected results:

The new tab/highlight section renders important addons which would improve security by (selectively) blocking javascripts useless, by reloading pages without restrictions.
Doing this for an unneccesary feature.
I suggest to disable the highlight feature or use the thumbnail of the previously closed tab...

Comment 1

[:Gijs (he/him)]

Shane, do you know why this is?

Comment 2

[Shane Caraveo (:mixedpuppy)]

This is not a security vulnerability.

I've no idea how activity streams loads and renders its previews, but apparently they are handled in a way that webextensions do not have access to.

Comment 3

[Shane Caraveo (:mixedpuppy)]

IOW, there are lots of things extensions dont get to touch, and this has fallen on that side of the wall.  This is an extension running into an intentional limitation.  Whether it should remain that way I have no opinion on.  Mardak et al. should probably think about that and decide whether it should be exposed and how it should be.

Comment 4

[:Gijs (he/him)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #3)
> IOW, there are lots of things extensions dont get to touch, and this has
> fallen on that side of the wall.  This is an extension running into an
> intentional limitation.  Whether it should remain that way I have no opinion
> on.  Mardak et al. should probably think about that and decide whether it
> should be exposed and how it should be.

Passing this to Mardak. If I had to guess, this is going to be related to how bg thumbnail processing happens in a separate process. Maybe we don't load add-on code into that process or something?

Comment 5

[Ed Lee :Mardak]

I don't actually know how background thumbnails makes requests, but there's a bunch of flags for the docshell to control a bunch of behaviors:
https://searchfox.org/mozilla-central/rev/14578d6f2d2ec5246572827061ecefa60a40855d/toolkit/components/thumbnails/content/backgroundPageThumbsContent.js#34-49

Most recently in bug 1449294, we set useTrackingProtection to turn on tracking protection. Bug 1453448 was filed to turn on safe browsing too via nsIChannel::LOAD_CLASSIFY_URI

I started digging around web extensions and found WebRequest… ;)

I'm totally guessing now, but WebRequest observes "http-on-before-connect" that is notified from at least nsHttpChannel:
https://searchfox.org/mozilla-central/rev/14578d6f2d2ec5246572827061ecefa60a40855d/netwerk/protocol/http/nsHttpChannel.cpp#484-492

It seems to check for some of the flags that the background thumbnails has set, e.g., LOAD_ANONYMOUS

Maybe thumbnail requests are actually getting to WebRequest ??

Comment 6

[Ed Lee :Mardak]

Well, doing some quick experimentation:

Services.obs.addObserver(c => console.log(c.name, c), "http-on-before-connect");
Cu.import("resource://gre/modules/BackgroundPageThumbs.jsm");
BackgroundPageThumbs.captureIfMissing("http://localhost/foo");

That seems to print out a 

XPCWrappedNative_NoHelper {
  name: "http://localhost/foo"
}

Comment 7

[Tim Spurway [:tspurway]]

we are reassigning this to the Web Extensions component, as it appears to be handled properly in AS

Comment 8

[Shane Caraveo (:mixedpuppy)]

Ok, from that my take away is that it is ok for newtab thumbnails to be blocked, modified, redirected, etc. by extensions.  Would that be accurate?  That was more the assessment I was looking for, rather than a technical look at whether it is possible.  Not sure who the right product person is to ni? on this now, so I'll pass to mconca to redirect.

Comment 9

[Ed Lee :Mardak]

(In reply to Shane Caraveo (:mixedpuppy) from comment #8)
> is that it is ok for newtab thumbnails to be blocked, modified, redirected, etc. by extensions
Oh, well... mm. sure? ;)

Activity Stream happens to be the main user of page thumbs, but it is used for other things like ctrl-tab.

There are probably complications of allowing extensions to modify these page thumb requests / pages. In particular it gets loaded in ways different from a normal page, so an extension might not expect things. E.g., no videos nor usual cookies.

Comment 10

[Daniel Veditz [:dveditz]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> This is not a security vulnerability.

Is the thumbnail service using the same originAttributes as the original page load? If not then it _is_ potentially a security vulnerability and definitely a privacy problem since it will leak information into the wrong context.:tjr

Comment 11

[Shane Caraveo (:mixedpuppy)]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> > This is not a security vulnerability.
> 
> Is the thumbnail service using the same originAttributes as the original
> page load? If not then it _is_ potentially a security vulnerability and
> definitely a privacy problem since it will leak information into the wrong
> context.:tjr

Ok, but that would a problem with the thumbnail service and have nothing to do with noscript (or any extension) being unable to see or block requests the thumbnail service is making.

Comment 12

[Ed Lee :Mardak]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> Is the thumbnail service using the same originAttributes as the original
> page load? If not then it _is_ potentially a security vulnerability and
> definitely a privacy problem since it will leak information into the wrong
> context.:tjr
tjr -> groovecoder ? Luke has been looking into activity stream's usage of thumbnails.

Comment 13

[László Furmen (GMT+2)]

If there is a thumbnail refresh mechanism, then there are additional problems too, eg.:
- Malicious pages can go on running their code even after the tab has closed, for example they can possibly mine cryptocurrency 
- It possibly can elongate or keep alive sessions
- The non-human initiated connections to web servers can make "false" hits in forensic investigations or in policy supervisions

And yes, letting extensions to run in thumblail generation time or context might introduce new problems too. 
(It might be worth considering using the new FF screenshot (or kind of) feature, triggered by page load, or close )

Comment 14

[Mike Conca [:mconca]]

From a product perspective, I don't believe we want extensions controlling the thumbnail service for newtab. If there are security or privacy issues with that service, Mozilla should be responsible for cleaning those up (and it sounds like people are looking into that).  If there are still user concerns with the thumbnail generation, the newtab can always be set to about:blank.

Comment 15

[Luke Crouch [:groovecoder]]

This is a tough one ... in https://bugzilla.mozilla.org/show_bug.cgi?id=1449294 and https://bugzilla.mozilla.org/show_bug.cgi?id=1453448 we are indeed looking into cleaning up privacy & security issues with thumbnails.

But an underlying long-running issue with thumbnails in about:newtab is: do users *expect* about:newtab can make more requests or run scripts again?

As I understand it, and ideally, Firefox captures everything it needs for thumbnails *when the user visits a site*. So, about:newtab should not *need* to make additional requests or run additional scripts.

Have we done any research to learn what users expect happens on about:newtab?

Have we done any research to learn whether the "rich" thumbnails improve user experience and/or affect usage?

What would it take to enforce that about:newtab does not send any new requests nor run any scripts?

Comment 16

[:Gijs (he/him)]

(In reply to Luke Crouch [:groovecoder] from comment #15)
> What would it take to enforce that about:newtab does not send any new
> requests

This basically means removing the background thumbnailer. That would be reasonably straightforward. The downside would be that bookmarks/history that gets added via sync will never have thumbnails until/unless you visit them on that machine, which would be unfortunate.

> nor run any scripts?

I think this would just require setting the relevant flag on the docshell used by the thumbnailer - but some / a lot of thumbnails will look pretty different if 0 script runs.

Comment 17

[Tom Ritter [:tjr] (OOTO until April)]

(In reply to Daniel Veditz [:dveditz] from comment #10)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #2)
> > This is not a security vulnerability.
> 
> Is the thumbnail service using the same originAttributes as the original
> page load? If not then it _is_ potentially a security vulnerability and
> definitely a privacy problem since it will leak information into the wrong
> context.:tjr

As far as I can tell: no. Thumbnails will be loaded without any container id (see exception below).  If you load example.com in Container A; Thumbnails will load it in no container, and it can set cookies in your no-container.

But things do get complicated: If I visit example.com in no-container once and then never again, and visit it frequently in Container A: should I load it with no-container or Container A? What it I visit it frequently in two containers?




Now there is a pref: https://searchfox.org/mozilla-central/search?q=about_newtab_segregation&path= that seems to isolate thumbnail requests containers to a container specifically for this purpose. It seems to be on in Nightly for the past couple years but not anywhere else. I think it would be good to enable it browser-side; because otherwise (AFAICT) thumbnails can keep refreshing cookies in your browsing context.

Comment 18

[László Furmen (GMT+2)]

Have you been comitted some changes related to the thumbnails? 
FF keeps showing me NoScript popups (in every 5 minutes) in connection with an already closed page, regardless whether i have a new  (empty) tab or have not.

(I use FF 59.0.3)
(I got the alert in connection with this page: Which is actually this: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob_plain;f=manuf)

Comment 19

[László Furmen (GMT+2)]

Ok, I rechecked the behavior of newtab with this: https://coub.com/view/15oetg ,which renders correctly in the highlite section of newtab in spite of the fact of there are no NoScript permissions which would make it possible.
NoScript seemingly still does not block javascript in the highlite section of newtab.

So it is also possible, that i came across an another bug, wich make it possible to javascript codes to achieve persistency (keep running javascript after the page closed).

Comment 20

[László Furmen (GMT+2)]

I am new here so i dont know how things goes here. 
I am pondering over why is the status of this ticket UNCONFIRMED.
The summary is interesting too, it says "new tab/highlight thumbnail requests not affected by noscript", wich is true, and terse too, but - in my opinion - this is not a proplem. The problem is, that the thumbnailservice runs scripts at all.

Comment 21

[Giorgio Maone [:ma1]]

NoScript's developer here: the expectation of NoScript users is that NoScript-provided restrictions and protections apply to any web content loaded by the browser, no matter if thumbnailed or full-page.

Not being able to process some websites (like AMO and other in the "restricted" list) is already regarded as a problem by many users, even though the rationale for it (preventing WebExtensions from tampering with their own privileges) is pretty clear (maybe a special permission to interact with the resticted list would be an idea).

Having any website work-around NoScript's restrictions by simply being loaded as thumbnails in the newtab page is unacceptable (as a stop-gap measure I'd be tempted to use chrome_url_overrides to disable it, but it would be very unfortunate). 

In NoScript 5 "Classic" I used to hook the thumbnail generation service to disable all the active content features (JavaScript, plugins, media) at the DocShell level, even if the rendering happened in a different process.

As a WebExtension, it's crucial (and IMHO doable, since WebExtensions are multi-process now) that the HTTP requests used to render thumbnails (and any other background service which can lead to active content execution) can be processed by browser.webRequest listeners and run WebEx-registered content scripts.

Comment 22

[Rob Wu [:robwu]]

I don't know whether activity stream uses something different, but in the past I did certainly receive webRequest event notifications for thumbnail requests, details at: https://github.com/Rob--W/open-in-browser/issues/20#issuecomment-345527177

From the user's POV, that feature can be disabled by setting browser.pagethumbnails.capturing_disabled to true.

Could you write a self-contained STR of the bug? E.g. creating an add-on with a webRequest listener for specific requests, opening some tabs and confirming that the expected requests were observed. That STR is needed to verify this bug (and for QA, if there is any fix).

Comment 23

[Giorgio Maone [:ma1]]

(In reply to Rob Wu [:robwu] from comment #22)
> I don't know whether activity stream uses something different, but in the
> past I did certainly receive webRequest event notifications for thumbnail
> requests, details at:
> https://github.com/Rob--W/open-in-browser/issues/20#issuecomment-345527177

I stand corrected. I based my comment on the observations of the reporter, who contacted me this morning complaining about NoScript being bypassable by page thumbnails.

I've actually checked right now: webRequest callbacks work as expected, and script blocking happens as expected as well, being implemented as CSP injection in onHeadersReceived.

Some unexpected differences in rendering between a script-disabled page in a tab and the thumbnail may be due to the content script enabling <NOSCRIPT> element emulation, injected with the browser.tabs.executeScript(), does not work because the thumbnail renderer reports -1 as the tabId.

Closing as WORKSFORME for the moment being, thank you.