Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#19200 closed defect (fixed)

HTML5 video not blocked with placeholder, plays automatically

Reported by: potato Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-security-slider, tbb-6.0-issues, noscript, GeorgKoppen201611, TorBrowserTeam201611
Cc: ELiMiNATOR, ma1, f451022, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In Tor Browser 6.0a5, with security level set at Medium-Low or higher, HTML5 video that uses media source extensions (MSE) is able to load and play automatically, without being blocked by a click-to-play NoScript placeholder. The policy for the Medium-Low, Medium-High, and High security levels states that "HTML5 video and audio media become click-to-play via NoScript," but this bug breaks that security policy by allowing HTML5 MSE media to play unobstructed. The browser's attack surface may be increased due to exposure to this media.

I've tested on both OS X and Tails 2.4~rc1. The bug exists on both platforms. On OS X, I tested with a clean install of Tor Browser.

Regular HTML5 video that does not use MSE is unaffected by this bug and gets placeholder-blocked properly.

Expected result:

HTML5 MSE video should not be allowed to play automatically in security level Medium-Low or higher, it should be replaced with a click-to-play placeholder by NoScript to block it until the user either clicks the placeholder or uses the NoScript toolbar button to allow it. This was the behavior in Tor Browser 5.5.5 and earlier.

Steps to reproduce:

  1. Click the Torbutton icon in the browser toolbar, select "Privacy and Security Settings..." and choose Medium-Low, Medium-High, or High security level.
  2. Go to a site that has MSE video, such as any YouTube video, eg: https://www.youtube.com/watch?v=T07gkTc5Fcc
  3. If Tor Browser is in High security mode, then allow scripts on the page via the NoScript toolbar button option "Temporarily allow all this page."
  4. The video will start playing automatically. There is no NoScript placeholder that you click to start the video, it just starts playing.

Child Tickets

Change History (47)

comment:1 Changed 3 years ago by potato

I don't think this bug is related to the fact that "mediasource:" is whitelisted in NoScript's settings. Removing that item from "noscript.default" and "noscript.mandatory" and "capability.policy.maonoscript.sites" in about:config has no effect, the bug is still present. Also, "mediasource:" was whitelisted in Tor Browser 5.5.5, which didn't even have this bug.

comment:2 Changed 3 years ago by gk

Keywords: tbb-security-slider added; 6.0a5 video media mse mediasource noscript placeholder removed
Priority: Very HighHigh

Well, the slider got implemented based on a study concerning past vulnerabilities. And MSE haven't been a thing back then. Thus, it is not surprising that they are not accounted for in the settings. We plan to look again at past vulnerabilities in Firefox code in the coming weeks and adjust the slider accordingly. This might be a good ticket to consider then.

comment:3 Changed 3 years ago by bugzilla

Thanks for filing a separate ticket for ticket:18937#comment:14. Maybe, this will help to raise attention of devs to the problem.

Last edited 3 years ago by bugzilla (previous) (diff)

comment:4 Changed 3 years ago by gk

Keywords: tbb-6.0-issues added

comment:5 Changed 3 years ago by rena

it's possible just disable media source extensions?

comment:6 Changed 3 years ago by cypherpunks

according to https://developer.mozilla.org/en-US/docs/Web/API/MediaSource the change happened in firefox 42.0 where media.mediasource.enabled is set to true by default. setting it to false reverts this to the previous click-to-play functionality.

comment:7 in reply to:  6 Changed 3 years ago by bugzilla

Replying to cypherpunks:

the change happened in firefox 42.0

It just shows how long ago NoScript stopped to do what it should. So, another +1 to #19280.

comment:8 in reply to:  6 Changed 3 years ago by rena

Replying to cypherpunks:

media.mediasource.enabled is set to true by default. setting it to false reverts this to the previous click-to-play functionality.

Yeah, it work appropriately for me.

comment:9 Changed 3 years ago by gk

Closed #19352 as a duplicate of this ticket.

comment:10 Changed 3 years ago by gk

Keywords: GeorgKoppen201607 TorBrowserTeam201607 added

comment:11 Changed 3 years ago by gk

Cc: ELiMiNATOR added
Keywords: GeorgKoppen201607R added; GeorgKoppen201607 removed
Status: newneeds_review

bug_19200 (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_19200) in my public Torbutton repo has a fix for review.

Marked #19546 as a duplicate.

comment:12 Changed 3 years ago by gk

Keywords: GeorgKoppen201607 TorBrowserTeam201607R added; GeorgKoppen201607R TorBrowserTeam201607 removed

comment:13 Changed 3 years ago by gk

Upon further thought I wonder whether the approach in my patch is actually a good one. I mean we don't set media.webm.enable to false either to get WebM videos to adhere to click-to-play governed by NoScript. I fear we are essentially breaking MSEs on higher security level this way instead of making it click-to-play.

comment:14 in reply to:  13 ; Changed 3 years ago by mcs

Replying to gk:

Upon further thought I wonder whether the approach in my patch is actually a good one. I mean we don't set media.webm.enable to false either to get WebM videos to adhere to click-to-play governed by NoScript. I fear we are essentially breaking MSEs on higher security level this way instead of making it click-to-play.

So are you now thinking that the correct solution is to fix NoScript to work correctly when both noscript.forbidMedia and media.mediasource.enabled are set to true?

comment:15 in reply to:  14 Changed 3 years ago by gk

Cc: ma1 added
Keywords: TorBrowserTeam201607 added; TorBrowserTeam201607R removed
Status: needs_reviewneeds_revision

Replying to mcs:

Replying to gk:

Upon further thought I wonder whether the approach in my patch is actually a good one. I mean we don't set media.webm.enable to false either to get WebM videos to adhere to click-to-play governed by NoScript. I fear we are essentially breaking MSEs on higher security level this way instead of making it click-to-play.

So are you now thinking that the correct solution is to fix NoScript to work correctly when both noscript.forbidMedia and media.mediasource.enabled are set to true?

Yes.

comment:16 Changed 3 years ago by ma1

Mediasource is quite a hairy problem.

The reason why ClickToPlay cannot work the way it does for "normal" videos is because there's no general way to identify the actual origin of the stream that is going to be played: in facts, the data can be generated on the fly by JavaScript code on the page and can actually come from anywhere (XMLHttpRequest, fetch(), random numbers, images whose bits are read using the canvas API, user input, whatever).

Therefore the only meaningful "subject of trust" can be page's origin: trying to put individual mediasource elements behind ClickToPlay is impossible (since the data is fetched and/or assembled by scripts, you are required to reload the page upon placeholder activation, and the identity of the element to be activated is usually lost, since it's not bound to any persistent unique URL); furthermore, I doubt it's even useful from a security standpoint, since you cannot actually tell one instance from the other.

The only partial work around I can think of is to implement a "special case" ClickToPlay for MSE, activating all the elements of a certain page if any placeholder gets clicked (the key would be page's URL, rather than the non-existent "media URL", and a page reload would occur). Would that work for you?

comment:17 Changed 3 years ago by gk

Cc: f451022 added

Marked #19736 as a duplicate of this bug.

comment:18 in reply to:  16 ; Changed 3 years ago by gk

Status: needs_revisionneeds_information

Replying to ma1:

Mediasource is quite a hairy problem.

The reason why ClickToPlay cannot work the way it does for "normal" videos is because there's no general way to identify the actual origin of the stream that is going to be played: in facts, the data can be generated on the fly by JavaScript code on the page and can actually come from anywhere (XMLHttpRequest, fetch(), random numbers, images whose bits are read using the canvas API, user input, whatever).

Therefore the only meaningful "subject of trust" can be page's origin: trying to put individual mediasource elements behind ClickToPlay is impossible (since the data is fetched and/or assembled by scripts, you are required to reload the page upon placeholder activation, and the identity of the element to be activated is usually lost, since it's not bound to any persistent unique URL); furthermore, I doubt it's even useful from a security standpoint, since you cannot actually tell one instance from the other.

The only partial work around I can think of is to implement a "special case" ClickToPlay for MSE, activating all the elements of a certain page if any placeholder gets clicked (the key would be page's URL, rather than the non-existent "media URL", and a page reload would occur). Would that work for you?

We could tried it at least I guess. There was the idea in #19736 to just set media.autoplay.enabled to false and be done with it but I assume that this does not prevent malicious code from exploiting bugs in Mozilla's media code but that might be worth to double-check. Another thing I looked at was the Flashstopper extension which at least provides an interesting way to block audio/video tags until the user does something. Giorgio, what do you think would be the best road for making sure we keep our security guarantees and a click-to-play mechanism?

comment:19 in reply to:  18 Changed 3 years ago by f451022

Replying to gk:

We could tried it at least I guess. There was the idea in #19736 to just set media.autoplay.enabled to false and be done with it but I assume that this does not prevent malicious code from exploiting bugs in Mozilla's media code but that might be worth to double-check. Another thing I looked at was the Flashstopper extension which at least provides an interesting way to block audio/video tags until the user does something. Giorgio, what do you think would be the best road for making sure we keep our security guarantees and a click-to-play mechanism?

set media.autoplay.enabled to false introduce a bug on youtube, and probably others sites too, I saw this today on some tests.

whatever, I prefer disable MSE because:

  1. it's use javascript and I don't like it.
  1. without MSE you can get de video path including youtube videos, it's allows to open the video on a standalone tab and also download the video easily.

example:

take it, https://www.youtube.com/watch?v=dQw4w9WgXcQ.
and using right click > page info > media, you can get the path.
or just copy the link on noscript placeholder.

now you can standalone and also download the video.

comment:20 Changed 3 years ago by gk

Keywords: TorBrowserTeam201608 added; TorBrowserTeam201607 removed

Moving items to August 2016.

comment:21 Changed 3 years ago by gk

Keywords: GeorgKoppen201608 added; GeorgKoppen201607 removed

Moving my tickets as well.

comment:22 Changed 3 years ago by gk

Keywords: GeorgKoppen201609 added; GeorgKoppen201608 removed

Moving my tickets

comment:23 Changed 3 years ago by gk

Keywords: TorBrowserTeam201609 added; TorBrowserTeam201608 removed

Tickets for September.

comment:24 Changed 3 years ago by cypherpunks

hello,
using Tails 2.5, TBB 6.0.3. with NoScript - Forbid Scripts Globally, any video from framepool.com loads and is playable after a click. Is it the issue this ticket is about?
e.g. footage.framepool.com/en/shot/513553723-highlights1613-anvil-tool-forge-metal-machining

The same with facebook "security check", it reloads page as if JS was enabled, but it is not.

comment:25 Changed 3 years ago by gk

Keywords: GeorgKoppen201610 added; GeorgKoppen201609 removed

Moving my tickets

comment:26 Changed 3 years ago by gk

Keywords: TorBrowserTeam201610 added; TorBrowserTeam201609 removed

Moving tickets to October.

comment:27 in reply to:  16 ; Changed 3 years ago by bugzilla

Keywords: noscript added

Replying to ma1:
Giorgio, gk asked you about the security hole 3 mo ago. Do you think it's not about NoScript or it shouldn't be addressed in a timely fashion?

The only partial work around I can think of is to implement a "special case" ClickToPlay for MSE, activating all the elements of a certain page if any placeholder gets clicked (the key would be page's URL, rather than the non-existent "media URL", and a page reload would occur). Would that work for you?

It looks like TBB shouldn't expose MSE availability to sites for which JS is disabled (to make HTML5 A/V visible). But for JS-enabled sites your "ClickToPlay for MSE" feature looks good.

comment:28 in reply to:  27 ; Changed 3 years ago by ma1

Replying to bugzilla:

Replying to ma1:
Do you think it's not about NoScript or it shouldn't be addressed in a timely fashion?

I do think it needs to be addressed ASAP, and I did implement my "trust MSE videos on this page + reload" solution in NoScript 2.9.5 codebase (under development), which is significantly different from 2.9.0.x (current release) because it's refactored and split across processes as an interim e10s-compatible XUL version before switching to WebExtensions.

Unfortunately putting this version in a releasable state is taking considerably longer than expected, but I hope to publish it in a couple of weeks at most, but should I miss this mark I'm gonna backport this fix into an ad-hoc 2.9.0.15 release.

comment:29 in reply to:  28 Changed 3 years ago by bugzilla

Replying to ma1:

Unfortunately putting this version in a releasable state is taking considerably longer than expected, but I hope to publish it in a couple of weeks at most, but should I miss this mark I'm gonna backport this fix into an ad-hoc 2.9.0.15 release.

Where did you see a version of e10s in a releasable state? Do you know that Mozilla still calls Win64 release of FF experimental (not to public)? And only FF53 is going to be the default... since FF43? So, FF48 + 10 = FF58 to take electrolysis seriously.

comment:30 Changed 3 years ago by gk

Keywords: GeorgKoppen201611 added; GeorgKoppen201610 removed

Moving my tickets to November.

comment:31 Changed 3 years ago by gk

Keywords: TorBrowserTeam201611 added; TorBrowserTeam201610 removed

Moving tickets over to November.

comment:32 Changed 3 years ago by i139

any progress? disable MSE is more desirable at this time

comment:33 Changed 3 years ago by gk

Cc: gk added

comment:34 in reply to:  32 Changed 3 years ago by ma1

Replying to i139:

any progress? disable MSE is more desirable at this time

About to release MSE per-site enablement (either as click to play or from the Blocked Objects menu, depending on how dynamically the website creates media elements) in 2.9.5, due within this week.

comment:35 Changed 3 years ago by i139

isn't possible to block some MSE path? force the site to use a limitation and predictable range of path (predictable elements), who complex is MSE? its looks like a DRM

comment:36 in reply to:  35 Changed 3 years ago by ma1

Replying to i139:

isn't possible to block some MSE path? force the site to use a limitation and predictable range of path (predictable elements), who complex is MSE?

It's possible to (un)block *per hosting page* and declared MIME type, but not per data source.
With MSE you cannot tell for sure where the actual bytes come from: they're usually fetched using XHR or the fetch() API, but they could actually be anything, even computed on the fly, because they're added programmatically through a JavaScript API on the go. This, from a security perspective, means that the only entity which you can decide to trust or not for MSE is the site where the JavaScript using the MediaSource API is executed. Unblocking per page, rather than per site (which is still possible) is merely a convenience.

What I'm doing is intercepting the API in order to learn

  1. whether it's gonna be used on the page
  2. which MIME types are being requested (this info is passed to the API to tell the consuming element which the required codecs are)

Then I emulate an actual content interception, possibly associating it to a media element if already bound to the MediaSource instance.

comment:37 Changed 3 years ago by i139

what is the advances of MSE use instance of non-MSE use? should be measured the advances and the difficulty of implementation of this technology, like this issue with placeholder

comment:38 in reply to:  37 ; Changed 3 years ago by ma1

Replying to i139:

what is the advances of MSE use instance of non-MSE use? should be measured the advances and the difficulty of implementation of this technology, like this issue with placeholder

Proponents of this technology will tell you that it allows to move into the web platform a lot of logic (mostly for adaptative bit rate) which was implemented natively in custom players or in Flash.
As a side effect the data flow *appears* less transparent, but what we should focus on is that the JavaScript on a certain webpage has now the power to fuzz (and possibly exploit) any available HTML 5 media codec *without even touching the network*. That's way I believe restricting MSE usage as an additional permission for the site (or the webpage, as I said, for convenience rather than security, e.g. on Youtube) is the most sensible approach: exactly the same NoScript already adopts for WebGL.

comment:39 Changed 3 years ago by i139

Adaptive bitrate Vs Obscurity.
the major beneficiary with this will be live streaming, like twitch or conferences that doesn't run without MSE and some sites that use dynamic javascript like twitter.

somehow, maybe the user should have control above this choice (without use about:config) maybe put this in the security slider or a checkbox option
you have an observation about a possible exploit?
those information have to be put in the manual.

comment:40 in reply to:  38 Changed 3 years ago by i139

Replying to ma1:

That's way I believe restricting MSE usage as an additional permission for the site (or the webpage, as I said, for convenience rather than security, e.g. on Youtube) is the most sensible approach: exactly the same NoScript already adopts for WebGL.

is the best option how we have now.

however saying about js and codec is proper make a statement about firefox codec, in firefox 51 mozilla adding support to flac, noscript or torbutton could use a serie of checkbox for codec or for media format, avoiding unnecessary and unsafe codec/format adding a extra protection for user.

Last edited 3 years ago by i139 (previous) (diff)

comment:41 Changed 3 years ago by ma1

Please check NoScript 2.9.5rc35 from ​https://noscript.net/getit
Thank you.

comment:42 Changed 3 years ago by i139

working properly, but I have to click in two placeholder for play the video

tested in youtube and dailymotion on security setting medium with 6.5a4

comment:43 in reply to:  42 ; Changed 3 years ago by i139

Replying to i139:

but I have to click in two placeholder for play the video

it's because the page at first time reload

comment:44 Changed 3 years ago by i139

NoScript 2.9.5 was released with this correction, is just update

comment:45 in reply to:  43 ; Changed 3 years ago by ma1

Replying to i139:

Replying to i139:

but I have to click in two placeholder for play the video

it's because the page at first time reload

It's probably because there are two separate MediaSource buffers with different content types, e.g. one for audio and one for video.

comment:46 Changed 3 years ago by gk

Resolution: fixed
Status: needs_informationclosed

This seems to be fixed with NoScript 2.9.5.1. Thanks so much ma1!

comment:47 in reply to:  45 Changed 3 years ago by cypherpunks

Replying to ma1:

Replying to i139:

Replying to i139:

but I have to click in two placeholder for play the video

it's because the page at first time reload

It's probably because there are two separate MediaSource buffers with different content types, e.g. one for audio and one for video.

Nice way to play audio only if required.

But these placeholders are behind the player on Twitter, so clicking leads to play/pause effect.

Note: See TracTickets for help on using tickets.