Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

[Benjamin Smedberg]

I intend to ship a change which will prevent Flash from loading from file:,
ftp:, or any other URL scheme other than http: or https:. The purpose of
this change is to increase security and limit Flash to well-tested
configuraitons.


- file: same-origin security mechanism is different, and so there have
been problems in the past with Flash content bypassing normal controls.
- Flash is normally not tested with ftp: or other protocols, and we've
had security issues in the past as a result of interactions between Flash
and these sites.

I am not yet sure whether we will be able to prevent Flash from loading in
data: contexts or not. I'd like to, but it may not be possible without
breaking existing content.
This work is being tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1335475

--BDS

[Chris Peterson]

On 2/7/2017 1:15 PM, Benjamin Smedberg wrote:
> I intend to ship a change which will prevent Flash from loading from file:,
> ftp:, or any other URL scheme other than http: or https:. The purpose of
> this change is to increase security and limit Flash to well-tested
> configuraitons.

Do you want to also block Flash content from loading file: or ftp: URLs?

[Emanuel Hoogeveen]

Will this also prevent loading downloaded .swf files into Firefox? This is useful for running Flash games, which tend to work best in the browser (some media players also support loading Flash files, but their hotkeys tend to conflict). Obviously if we get to the point where we stop supporting Flash altogether this use case will break anyway, so mostly asking for clarification.

[段垚]

Is this just preventing auto-loading (like "click to play") or
completely disable Flash for non-http(s) contents?

Can users get back old behavior by flipping a preference?

We have developed a Firefox based tool to edit/view local EPub files,
which may contain Flash.

If this feature can't be opt-out , we and our customs will be in trouble.

I understand and appreciate the trend of web without plugins, but we and
our customs just have too many Flash assets.

Thanks.

Duan, Yao

在 2017/2/8 5:15, Benjamin Smedberg 写道:
> I intend to ship a change which will prevent Flash from loading from file:,
> ftp:, or any other URL scheme other than http: or https:. The purpose of
> this change is to increase security and limit Flash to well-tested
> configuraitons.
>
>
> - file: same-origin security mechanism is different, and so there have
> been problems in the past with Flash content bypassing normal controls.
> - Flash is normally not tested with ftp: or other protocols, and we've
> had security issues in the past as a result of interactions between Flash
> and these sites.
>
> I am not yet sure whether we will be able to prevent Flash from loading in
> data: contexts or not. I'd like to, but it may not be possible without
> breaking existing content.
> This work is being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1335475
>
> --BDS

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Benjamin Smedberg]

On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <dua...@ustc.edu> wrote:

> Is this just preventing auto-loading (like "click to play") or completely
> disable Flash for non-http(s) contents?
>

This is completely disabling this content.

>
> Can users get back old behavior by flipping a preference?
>

That is not the plan, no.

>
> We have developed a Firefox based tool to edit/view local EPub files,
> which may contain Flash.
>
> If this feature can't be opt-out , we and our customs will be in trouble.
>

My mind is filled with questions about how epub+Flash could ever be a good
idea, but I will avoid asking them here. Instead, could you work around
this by serving the content and loading it from http://localhost ? That is
what we intend to recommend for developers building Flash websites and
wanting to test locally.

Otherwise, you will have to build your own builds with this restriction
removed.

--BDS

[Benjamin Smedberg]

Will this also prevent loading downloaded .swf files into Firefox? This is
> useful for running Flash games, which tend to work best in the browser
> (some media players also support loading Flash files, but their hotkeys
> tend to conflict).

It will prevent them from loading via File > Open, yes (and that is the
fundamental change we need to make). If you were to serve them via
localhost you could still use them (e.g. with python -m SimpleHTTPServer).

--BDS

[Benjamin Smedberg]

On Tue, Feb 7, 2017 at 5:19 PM, Chris Peterson <cpet...@mozilla.com>
wrote:

That is not part of this bug. I will consult with Adobe and see whether
that is likely to break anything, and perhaps propose it as a separate
change.

--BDS

[Xidorn Quan]

On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:
> Will this also prevent loading downloaded .swf files into Firefox? This
> is
> > useful for running Flash games, which tend to work best in the browser
> > (some media players also support loading Flash files, but their hotkeys
> > tend to conflict).
>

> It will prevent them from loading via File > Open, yes (and that is the
> fundamental change we need to make). If you were to serve them via
> localhost you could still use them (e.g. with python -m
> SimpleHTTPServer).

I kind of disagree with this. SimpleHTTPServer is simple for developers
but not at all for normal users. I think it should be allowed to load a
top level Flash file. What harm could it do if we allow that?

- Xidorn

[段垚]

在 2017/2/10 1:28, Benjamin Smedberg 写道:
> On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <dua...@ustc.edu> wrote:
>
>> Is this just preventing auto-loading (like "click to play") or completely
>> disable Flash for non-http(s) contents?
>>
> This is completely disabling this content.
>
>
>> Can users get back old behavior by flipping a preference?
>>
> That is not the plan, no.
>

Well, this plan seems too aggressive. I'd rather recommend implementing
"click to play" for non-http(s) Flash first and deferring complete removal.

IE requires user's confirmation to load local Flash for a long time.

>> We have developed a Firefox based tool to edit/view local EPub files,
>> which may contain Flash.
>>
>> If this feature can't be opt-out , we and our customs will be in trouble.
>>
> My mind is filled with questions about how epub+Flash could ever be a good
> idea, but I will avoid asking them here.

Epub+Flash is not quite a good idea, it is just because our Flash assets
can't be replaced in a short term.

> Instead, could you work around
> this by serving the content and loading it from http://localhost ? That is
> what we intend to recommend for developers building Flash websites and
> wanting to test locally.

Local http server could trigger security alarm of OS/firewall, which
confuses users: why a desktop app want to start a server?

Also local http server may be more insecure than direct file access,
e.g. misconfigured or flawed server may allow
anyone on the net to access your files. So I'd rather not head to this way.

> Otherwise, you will have to build your own builds with this restriction
> removed.
>
> --BDS

[Frederik Braun]

On 10.02.2017 01:09, Xidorn Quan wrote:
> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:

>> Will this also prevent loading downloaded .swf files into Firefox? This
>> is
>>> useful for running Flash games, which tend to work best in the browser
>>> (some media players also support loading Flash files, but their hotkeys
>>> tend to conflict).
>>

>> It will prevent them from loading via File > Open, yes (and that is the
>> fundamental change we need to make). If you were to serve them via
>> localhost you could still use them (e.g. with python -m
>> SimpleHTTPServer).
>
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
>

toplevel loads includes opened via window.open and target=_blank, no?

This means HTML/JS from file:, ftp: etc. could still find a way to open
SWF from those non-HTTP/HTTPs sites.

[Benjamin Smedberg]

I thought I enumerated the harm at first, but I'll elaborate a little.

1) Flash doesn't know about and breaks our "current and subdirectory only"
file: origin policy.

2) Flash is a high-risk attack surface: if you can get somebody to download
a SWF they can probably own your system. We don't have anyone testing or
defending this effectively.

So we believe that there is significant harm in the current situation, and
very little upside.

--BDS

On Thu, Feb 9, 2017 at 7:09 PM, Xidorn Quan <m...@upsuper.org> wrote:

> On Fri, Feb 10, 2017, at 04:29 AM, Benjamin Smedberg wrote:

> > Will this also prevent loading downloaded .swf files into Firefox? This
> > is
> > > useful for running Flash games, which tend to work best in the browser
> > > (some media players also support loading Flash files, but their hotkeys
> > > tend to conflict).
> >

> > It will prevent them from loading via File > Open, yes (and that is the
> > fundamental change we need to make). If you were to serve them via
> > localhost you could still use them (e.g. with python -m
> > SimpleHTTPServer).
>
> I kind of disagree with this. SimpleHTTPServer is simple for developers
> but not at all for normal users. I think it should be allowed to load a
> top level Flash file. What harm could it do if we allow that?
>

> - Xidorn

[Benjamin Smedberg]

On Fri, Feb 10, 2017 at 12:36 AM, 段垚 <dua...@ustc.edu> wrote:

>
> 在 2017/2/10 1:28, Benjamin Smedberg 写道:
>
>> On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <dua...@ustc.edu> wrote:
>>
>> Is this just preventing auto-loading (like "click to play") or completely
>>> disable Flash for non-http(s) contents?
>>>
>>> This is completely disabling this content.
>>
>>
>> Can users get back old behavior by flipping a preference?
>>>
>>> That is not the plan, no.
>>
>> Well, this plan seems too aggressive. I'd rather recommend implementing
> "click to play" for non-http(s) Flash first and deferring complete removal.
>
> IE requires user's confirmation to load local Flash for a long time.
>

We are planning on making Flash click-to-play by default for all content.
However, our implementation of click-to-play is based on remembering that
setting per site. This implementation does not work with file: URIs and the
engineering and QA effort to make it work is well beyond what we think is a
reasonable investment. Flash is a dying technology and this is one low-cost
way we can reduce attack surface and make users safer.

--BDS

[t...@ritter.vg]

On Friday, 10 February 2017 08:32:27 UTC-6, Benjamin Smedberg wrote:
> I thought I enumerated the harm at first, but I'll elaborate a little.
>
> 1) Flash doesn't know about and breaks our "current and subdirectory only"
> file: origin policy.
>
> 2) Flash is a high-risk attack surface: if you can get somebody to download
> a SWF they can probably own your system. We don't have anyone testing or
> defending this effectively.
>
> So we believe that there is significant harm in the current situation, and
> very little upside.

I think #1 is sufficient to remove this behavior, even ignoring #2. A malicious flash applet open opened from file:// can read the user's profile, take all their saved passwords, cookies, etc and steal data, masquerade as them, and perform all manner of malicious activity.

-tom

[段垚]

在 2017/2/10 22:34, Benjamin Smedberg 写道:
> On Fri, Feb 10, 2017 at 12:36 AM, 段垚 <dua...@ustc.edu> wrote:
>
>> 在 2017/2/10 1:28, Benjamin Smedberg 写道:
>>
>>> On Wed, Feb 8, 2017 at 2:26 AM, 段垚 <dua...@ustc.edu> wrote:
>>>
>>> Is this just preventing auto-loading (like "click to play") or completely
>>>> disable Flash for non-http(s) contents?
>>>>
>>>> This is completely disabling this content.
>>>
>>> Can users get back old behavior by flipping a preference?
>>>> That is not the plan, no.
>>> Well, this plan seems too aggressive. I'd rather recommend implementing
>> "click to play" for non-http(s) Flash first and deferring complete removal.
>>
>> IE requires user's confirmation to load local Flash for a long time.
>>
> We are planning on making Flash click-to-play by default for all content.
> However, our implementation of click-to-play is based on remembering that
> setting per site. This implementation does not work with file: URIs and the
> engineering and QA effort to make it work is well beyond what we think is a
> reasonable investment.

I think it is OK to not remember that setting for file-urls - just
require confirmation on each reload.
Is this simpler to implementation?

> Flash is a dying technology and this is one low-cost
> way we can reduce attack surface and make users safer.
>
> --BDS

[段垚]

I agree that this is a problem, but I disagree that Firefox must remove
this behavior now.

* This behavior has existed for decades in all desktop browsers, and the
usage of Flash is declining, which means the threaten is also declining.
So I don't see the reason for an immediate removal.

* Flash plugin is still actively maintained by Adobe, so I think you can
ask them to restrict permissions for local Flash contents.
This would benifit all browsers, not just Firefox.

>
> -tom

[Ehsan Akhgari]

On 2017-02-10 7:51 PM, 段垚 wrote:
>
>
> 在 2017/2/11 2:26, t...@ritter.vg 写道:

> I agree that this is a problem, but I disagree that Firefox must remove
> this behavior now.
>
> * This behavior has existed for decades in all desktop browsers, and the
> usage of Flash is declining, which means the threaten is also declining.

That is not true. It is public knowledge that Flash exploits are traded
as a commodity these days:
<https://www.wired.com/2015/07/hacking-team-leak-shows-secretive-zero-day-exploit-sales-work/>.

[段垚]

在 2017/2/14 0:24, Ehsan Akhgari 写道:
> On 2017-02-10 7:51 PM, 段垚 wrote:
>>
>> 在 2017/2/11 2:26, t...@ritter.vg 写道:

>> I agree that this is a problem, but I disagree that Firefox must remove
>> this behavior now.
>>
>> * This behavior has existed for decades in all desktop browsers, and the
>> usage of Flash is declining, which means the threaten is also declining.
> That is not true. It is public knowledge that Flash exploits are traded
> as a commodity these days:
> <https://www.wired.com/2015/07/hacking-team-leak-shows-secretive-zero-day-exploit-sales-work/>.

I guess all popular softwares have exploits being traded. How this fact
invalidates my argument?
Also I think forbidding non-http(s) Flash does not fix thoses exploits
magically.

[Ehsan Akhgari]

On 2017-02-13 11:50 AM, 段垚 wrote:
>
>
> 在 2017/2/14 0:24, Ehsan Akhgari 写道:
>> On 2017-02-10 7:51 PM, 段垚 wrote:
>>>
>>> 在 2017/2/11 2:26, t...@ritter.vg 写道:

>>> I agree that this is a problem, but I disagree that Firefox must remove
>>> this behavior now.
>>>
>>> * This behavior has existed for decades in all desktop browsers, and the
>>> usage of Flash is declining, which means the threaten is also declining.
>> That is not true. It is public knowledge that Flash exploits are traded
>> as a commodity these days:
>> <https://www.wired.com/2015/07/hacking-team-leak-shows-secretive-zero-day-exploit-sales-work/>.
>>
>
> I guess all popular softwares have exploits being traded. How this fact
> invalidates my argument?

I was responding to your point about the threat declining because of the
declining usage of Flash. This is demonstrably not true.

> Also I think forbidding non-http(s) Flash does not fix thoses exploits
> magically.

Sure, this is about reducing attack surface, not completely eliminating it.

[段垚]

在 2017/2/14 2:03, Ehsan Akhgari 写道:
> On 2017-02-13 11:50 AM, 段垚 wrote:
>>
>> 在 2017/2/14 0:24, Ehsan Akhgari 写道:
>>> On 2017-02-10 7:51 PM, 段垚 wrote:
>>>> 在 2017/2/11 2:26, t...@ritter.vg 写道:

>>>> I agree that this is a problem, but I disagree that Firefox must remove
>>>> this behavior now.
>>>>
>>>> * This behavior has existed for decades in all desktop browsers, and the
>>>> usage of Flash is declining, which means the threaten is also declining.
>>> That is not true. It is public knowledge that Flash exploits are traded
>>> as a commodity these days:
>>> <https://www.wired.com/2015/07/hacking-team-leak-shows-secretive-zero-day-exploit-sales-work/>.
>>>
>> I guess all popular softwares have exploits being traded. How this fact
>> invalidates my argument?
> I was responding to your point about the threat declining because of the
> declining usage of Flash. This is demonstrably not true.

Why? Assume

threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year

If usage_of_flash_per_year is declining but threat_of_flash is
increasing, then exploits_of_flash_per_year must be increasing.
But the report you cited does not provide such data.

>
>> Also I think forbidding non-http(s) Flash does not fix thoses exploits
>> magically.
> Sure, this is about reducing attack surface, not completely eliminating it.

Non-http(s) Flash takes only a small fraction of all Flash contents,
even for users who do use non-http(s) Flash.
I don't think users want to drop their local Flash for a small fraction
of reduced attack surface,
especially if those local Flash don't have alternatives yet. The more
practical reaction is trying another browser.

[Till Schneidereit]

On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <dua...@ustc.edu> wrote:

> I guess all popular softwares have exploits being traded. How this fact
>>> invalidates my argument?
>>>
>> I was responding to your point about the threat declining because of the
>> declining usage of Flash. This is demonstrably not true.
>>
>
> Why? Assume
>
> threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year
>
> If usage_of_flash_per_year is declining but threat_of_flash is increasing,
> then exploits_of_flash_per_year must be increasing.
> But the report you cited does not provide such data.
>

That assumption doesn't hold: malicious uses of Flash don't need
non-malicious ones.

In fact it seems quite likely that there'll be an inverse relationship:
less (non-malicious) usage means less testing of potentially exploitable
code paths, which would increase the threat.

One solution to this is to decouple the amount of testing done for those
code paths from how frequently they're used. In practice that's not trivial
because at least some testing comes in the form of investigating crash
reports from users. Another solution is what's proposed here: disable
less-well tested configurations altogether.

>
>
>> Also I think forbidding non-http(s) Flash does not fix thoses exploits
>>> magically.
>>>
>> Sure, this is about reducing attack surface, not completely eliminating
>> it.
>>
>
> Non-http(s) Flash takes only a small fraction of all Flash contents, even
> for users who do use non-http(s) Flash.
> I don't think users want to drop their local Flash for a small fraction of
> reduced attack surface,
> especially if those local Flash don't have alternatives yet. The more
> practical reaction is trying another browser.

The underlying assumption here is that these usages of Flash are rare
enough that the incompatibility, while unfortunate, becomes acceptable.
Note that other browser vendors are planning their own measures for
restricting Flash usage, too.

I understand that none of this helps you, and that's very unfortunate. I
hope you appreciate that we don't have infinite resources and thus have to
make, sometimes painful, trade-offs. Much as you probably have to in your
own projects.

[段垚]

在 2017/2/14 18:10, Till Schneidereit 写道:
> On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <dua...@ustc.edu> wrote:
>
>> I guess all popular softwares have exploits being traded. How this fact
>>>> invalidates my argument?
>>>>
>>> I was responding to your point about the threat declining because of the
>>> declining usage of Flash. This is demonstrably not true.
>>>
>> Why? Assume
>>
>> threat_of_flash = exploits_of_flash_per_year * usage_of_flash_per_year
>>
>> If usage_of_flash_per_year is declining but threat_of_flash is increasing,
>> then exploits_of_flash_per_year must be increasing.
>> But the report you cited does not provide such data.
>>
> That assumption doesn't hold: malicious uses of Flash don't need
> non-malicious ones.

I agree. So let me ask this question instead: is there any proof that
local-only Flash
exploits are increasing?

>
> In fact it seems quite likely that there'll be an inverse relationship:
> less (non-malicious) usage means less testing of potentially exploitable
> code paths, which would increase the threat.

I would assume Adobe will actively test Flash plugin with local contents
for a reasonablely long time. Do you mean tests in Firefox for local
Flash contents
will inevitably decrease even if you don't disable it?

>
> One solution to this is to decouple the amount of testing done for those
> code paths from how frequently they're used. In practice that's not trivial
> because at least some testing comes in the form of investigating crash
> reports from users. Another solution is what's proposed here: disable
> less-well tested configurations altogether.
>>
>>> Also I think forbidding non-http(s) Flash does not fix thoses exploits
>>>> magically.
>>>>
>>> Sure, this is about reducing attack surface, not completely eliminating
>>> it.
>>>
>> Non-http(s) Flash takes only a small fraction of all Flash contents, even
>> for users who do use non-http(s) Flash.
>> I don't think users want to drop their local Flash for a small fraction of
>> reduced attack surface,
>> especially if those local Flash don't have alternatives yet. The more
>> practical reaction is trying another browser.
>
> The underlying assumption here is that these usages of Flash are rare
> enough that the incompatibility, while unfortunate, becomes acceptable.
> Note that other browser vendors are planning their own measures for
> restricting Flash usage, too.

Although usage of local Flash is rare, I'd point out that local Flash
contents usually have higher
value than those on web sites, Because users only save important
contents to disks.
Additionally, local Flash contents are much harder to replace than those
on web sites
because users can hardly contact the author. Please consider more for users.

>
> I understand that none of this helps you, and that's very unfortunate. I
> hope you appreciate that we don't have infinite resources and thus have to
> make, sometimes painful, trade-offs. Much as you probably have to in your
> own projects.

[Till Schneidereit]

On Tue, Feb 14, 2017 at 12:00 PM, 段垚 <dua...@ustc.edu> wrote:

>
>
> 在 2017/2/14 18:10, Till Schneidereit 写道:
>
>> On Tue, Feb 14, 2017 at 12:14 AM, 段垚 <dua...@ustc.edu> wrote:
>>
>> I guess all popular softwares have exploits being traded. How this fact
>>>
>>>> invalidates my argument?
>>>>>
>>>>> I was responding to your point about the threat declining because of
>>>> the
>>>> declining usage of Flash. This is demonstrably not true.
>>>>
>>>> Why? Assume
>>>
>>> threat_of_flash = exploits_of_flash_per_year *
>>> usage_of_flash_per_year
>>>
>>> If usage_of_flash_per_year is declining but threat_of_flash is
>>> increasing,
>>> then exploits_of_flash_per_year must be increasing.
>>> But the report you cited does not provide such data.
>>>
>>> That assumption doesn't hold: malicious uses of Flash don't need
>> non-malicious ones.
>>
> I agree. So let me ask this question instead: is there any proof that
> local-only Flash
> exploits are increasing?
>

I don't know. I do know that legitimate usage of Flash, be it via file: or
otherwise, is steadily declining. That's all that's needed to change the
cost/benefit balance here.

>
>> In fact it seems quite likely that there'll be an inverse relationship:
>> less (non-malicious) usage means less testing of potentially exploitable
>> code paths, which would increase the threat.
>>
>
> I would assume Adobe will actively test Flash plugin with local contents
> for a reasonablely long time. Do you mean tests in Firefox for local Flash
> contents
> will inevitably decrease even if you don't disable it?
>

What I'm saying is that testing and hardening against attacks isn't free,
so requires investing resources. This entire thread is based on the
conclusion that Flash usage has diminished to a point where it's can no
longer a good investment of resources to keep doing these activities for
this fairly niche-usage of Flash.

We are doing precisely that, but we believe that our users are better
served by us investing resources in tasks that have more impact. Again, the
underlying assumption in this entire thread is that our users won't be
affected as strongly as you assume, or few enough will.

[段垚]

Seems I failed to convince you to change the plan.

So the last question is: when will this happen?

[Benjamin Smedberg]

At this point it seems unlikely that I will have time to fix this for
Firefox 54, so most-likely it will be Firefox 55.

--BDS