Flash Player 20 playback issue on ActiveX (v20.0.0.228)

[kobo02]

We are using the Flash Player ActiveX in our vb.net application.

As a result of updates to 20.0.0.228 version of Flash Player, it is not possible to play.

The swf path is "file:///e:/movie/test.swf" or "file://server/movie/test.swf".

This works with previous version of Flash Player, but latest version (20.0.0.228) cannot play.

The swf path is "e:\movie\test.swf" or "\\server\movie\test.swf".

This works both of version.

I want to know whether this be fixed in the bug, or whether a specification.

I hope to be able to play all kinds path, include "file:///e:/movie/test.swf".

[Kratika Agarwal]

Hi,

Thanks for reporting the issue.Could you please share your swf file so that we can verify the issue.

Is it working on other browsers other than ActiveX.

[kobo02]

thanks

I cannot provide the swf file because it's a part of commercial application.

but, you can reproduce using sameple swf file of adobe site below.

https://www.adobe.com/support/documentation/en/flash/fl8/samples.html

Click "alpha video sample files" for download.

1.

AxShockwaveFlash1.Movie = "file:///d:/movie/ClearExternalNoVol.swf"

-> Cannot play. screen is white.

2.

AxShockwaveFlash1.Movie = "d:/ClearExternalNoVol.swf"

-> Can play normally

*

I was confirmed by IE but it can play normaly.

(IE cannot use URL, such as "file:///d:/...". It is automatically converted to "d:/...".)

[jeromiec83223024]

We continue to be forced to lock down the ability to for SWF files running in the local filesystem to access external resources for security reasons.  Personally, I would like us to retire this functionality altogether, and newer browsers like Edge already impose those restrictions at the browser.

The issue you're experiencing with URL resolution lies at the intersection of a valid pseudo-protocol and the ability to abuse it by taking advantage of the overly-permissive interpretations of similar URLs by some browsers.  While it's unlikely but possible that we may change this behavior to fix the issue, it's probably just going to be a continued source of pain for you.

You're far, far better of either hosting the SWF on a web server (even a local one), or by packaging your content as a desktop Adobe AIR application, which exists to address the local application use-case, and is a far better choice for this kind of approach.

[kobo02]

jeromiec83223024 による書き込み:

We continue to be forced to lock down the ability to for SWF files running in the local filesystem to access external resources for security reasons.  Personally, I would like us to retire this functionality altogether, and newer browsers like Edge already impose those restrictions at the browser.

You mean that in the future, the local file will not be able to play on the flash player (activex)?

If so, this is a big problem for us.

because, we will take a lot of time and cost in order to change our application and contents.

We want to know when you intend to lock down "the ability to for SWF files running in the local filesystem".

We need to prepare for this.

The issue you're experiencing with URL resolution lies at the intersection of a valid pseudo-protocol and the ability to abuse it by taking advantage of the overly-permissive interpretations of similar URLs by some browsers.  While it's unlikely but possible that we may change this behavior to fix the issue, it's probably just going to be a continued source of pain for you.

so, Is the issue bug, not specification?

We want to know specifically when the issue will be fixed. in the near or far future?

As measures of the issue, we are going to change the swf path from "file:///d:/" to "d:\" for playback.

(network path: "file://server/"->"\\server\")

You're far, far better of either hosting the SWF on a web server (even a local one), or by packaging your content as a desktop Adobe AIR application, which exists to address the local application use-case, and is a far better choice for this kind of approach.

OK.

We will consider about this, but we cannot change our application soon.

[jeromiec83223024]

What I see in practice is that we're slowly being forced out of being able to do this by the browsers.  Given the security landscape in 2015, I don't personally think this is a bad thing, or a fight that we could win.  While there is no formal decision to deprecate local filesystem access at this time, I personally believe that an eventuality, and that it's much better to encourage developers to think about a migration strategy now, vs. letting people be caught off-guard later.

UNC paths in particular are problematic.  Until we debug the issue, we don't know whether or not it's fixable, but network traversal is an area of particular interest to attackers, and the ambiguities at the intersection of HTTP and UNC paths in the browser create scenarios that are difficult to safely interpret.  So file:/// is generally a better choice. although I'm not sure why you're running into this particular issue yet.

Using Adobe AIR instead of the browser for local applications would eliminate the risk of losing local filesystem access in the future, while allowing you to reuse much of your existing Flash-based code and content.

By any chance, when the file:/// path is resolved, is is traversing a Junction Point on the network storage?  Hard Links and Junctions (Windows)

If so, you might be able to work around this issue with the following mms.cfg flag; however, this does leave you open to the possibility of future abuse, which is why we block it by default.

Administrator configuration | Block usage of junction files

If you're already serving content over the network, it might just be easier to put an HTTP server in front of it and adjust the application accordingly.

[kobo02]

jeromiec83223024 による書き込み:

UNC paths in particular are problematic.  Until we debug the issue, we don't know whether or not it's fixable, but network traversal is an area of particular interest to attackers, and the ambiguities at the intersection of HTTP and UNC paths in the browser create scenarios that are difficult to safely interpret.  So file:/// is generally a better choice. although I'm not sure why you're running into this particular issue yet.

Because, the latest Flash Player cannot use “file:///”.

This is the issue that I have reported.

Were you able to reproduce this phenomenon?

And, I want to know whether there is the mind that the Adobe repairs.

The most troubled problem for us is it was able to do playback at the previous version, but suddenly it is that it has been not able to do playback at the latest version without prior announcement. As a result, our customer complained to us, then we had to repair our application as soon as possible.

Currently, we changed our application to a method of UNC path (“d:\” or “\\server\”) because the latest version of Flash Player cannot use “file:///”. But you said that “file:/// is generally a better choice”.

A last question is, after you fix this bug, should we change our application to the method of “file:///”("file://server/") again? Until we change our application to Adobe AIR etc.

[jeromiec83223024]

We have not reproduced the issue yet.  I've seen enough anecdotal evidence to believe that this is an issue and I've opened a bug on it, but nobody has provided a reproducible example yet.

In the absence of a reproducible scenario, I have to have a quality engineer investigate the problem, create a set of tests from scratch and hope that they find a set of conditions that reproduces the problem while working blindly, vs. just pointing someone with a C++ debugger to a set of reproducible steps that demonstrates the problem.  This adds considerable time to our investigation and response.  This issue has already missed the window for the January release, so we're looking at February at this point.  The window there is also fairly narrow, so I'm keen to get this investigated as quickly as possible.

Posting a bug at http://bugbase.adobe.com/ with complete step-by-step instructions on how to reproduce it would certainly help speed things along.  If you post the bug number here, I'll get the notification and will open it to the team directly.

I don't have a strong preference for one method of using file:/// paths vs. another.  None of them are great options.  It's hard for me to predict how they'll be abused in the future, and/or how we'll be forced to respond.  I also don't have clear insight into specific changes in the various browser pipelines.  It's just clear that there's a trend in restricting plugin access to the local filesystem, and that there's significant existential risk to this kind of use-case in general.

[ivanp61579321]

This is a critical bug, since it breaks all software following official doc which says "Absolute URLs must include the protocol reference, such as http:// or file:///":

Bug#4101067 - Unable to play local swf files in Flash Player 20 using 'file' protocol

[Kratika Agarwal]

Hi,

Thanks for reporting the issue. Please see the bug for the updates.

[kanthi_gm]

HI All,

Is this issue fixed yet? We are facing the same issue with one of our MFC application written in VC++. The flash SWF is not loading and we see a black screen. We have tried with both SetMovie and LoadMovie on ShockWave Flash Object.

Thanks and Regards,

Kanthi.

[kobo02]

thank you for the follow-up and bug reporting!

[pavelr21055322]

“You become responsible, forever, for what you have tamed.”
― Antoine de Saint-Exupéry, The Little Prince

I'm am an author of YoWindow Weather app/screensaver - http://yowindow.com

YoWindow is a well known application for Windows and Mac.

For example, #1 Screen saver in Germany

Screensaver - Downloads - CHIP

YoWindow has fallen as a victim of this modification.

Since the release of FP 20.0.0.267 we are receiving complaints that YoWindow is not working anymore.

Most users will soon be unable to run the app and screen saver.

We use ActiveX instead of AIR because AIR is not able to run as a screen-saver.

We've been working on YoWindow Weather since 2006.

I wonder if this is the end of the line?

Should we close down the project?

Pavel Repkin

[jeromiec83223024]

I believe that the candidate fix is available in the current beta, here:

http://www.adobe.com/go/flashplayerbeta/

To answer your question more directly, embedding ActiveX controls into standalone applications is not guaranteed to be viable over the long term.  We don't technically support the use-case now, although we're aware that there's a body of legacy applications that take advantage of this approach, and we do our best to do right by the developers that have invested in the Flash platform over the years, and that still use this approach. 

That said, we don't actively test this use-case, although we do try to fix it if and when things break.  If faced with a choice between security in the browser plug-in case and the application case, we'll choose the browser plug-in. 

As the security landscape continues to evolve and become more challenging, we're often faced with decisions for which we cannot anticipate all of the potential side-effects, and the nature of those issues frequently does not afford us the luxury of a slow and measured response. 

[ivanp61579321]

Jeromie, as I stated in https://bugbase.adobe.com/index.cfm?event=selectBug&CFGRIDKEY=4101067:

"Just tried Beta Dec 16, 2015 from http://www.adobe.com/go/flashplayerbeta/ on Windows 7 and the issue is still present."

This is not security related issue, but a critical bug ('blocker') affecting all developers like us, which tied their products with Adobe's technology for over 10 years.

It would be nice to add this use-case as a test unit, since it is part of official documentation "Absolute URLs must include the protocol reference, such as http:// or file:///":

http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000573.html

[pavelr21055322]

Jeromie, thank you for the prompt reaction to the incident.

I have tried out the BETA version of FP.

The error is fixed, thank you.

I have a number of questions regarding the present and the future.

1. The newest Flash Player 20.0.0.267 is being rolled out to the users computers right now.

It has the defect.

Today I have received a ton of emails from people who are not able to run our application.

Their FPs have upgraded to 267 automatically.

Can you pause the rollout of the problematic 267 build?

Please, pause it.

Until the current BETA is ready for the release.

2. I need to tell YoWindow Weather users when the problem to be fixed.

When are you going to release the current BETA of Flash Player?

3. I wonder what are we going to do to avoid such an incident in the future?

I'm thinking about to go AIR way.

But can we compile AIR app to screen-saver?

[Kratika Agarwal]

Hi,

Thanks for reporting the issue. We are looking into the bug. We will update you son.

[jeromiec83223024]

The current release is a response to a security exploit in the wild that we were forced to address quickly.  It went out on Monday, so it should have patched the vast majority of your users already.  Our priority will always be the security of the web browser, and our approach in these situations is to remediate the immediate threat while hopefully not breaking anything, and then to deal with any unanticipated/undiscovered functional fallout when it arises. The issue you're experiencing is a functional issue that was fallout from having to push that release prematurely.

We're currently aware of a cluster of bugs impacting the embedded OCX use-case, and are actively investigating.  I don't make promises that I can't keep, so I'm not going to talk about dates, but we're doing our best to provide an expedient fix in the form of a production release.

Adobe's US offices are closed for the US holidays, which is slowing down the response.  People and systems are unavailable due to vacation travel, scheduled maintenance, etc.  Fortunately, we're all back in the office on Monday and should have critical mass.  In the meantime, we're already conducting the analysis and considering the logistics of what can be fixed, when.  I expect it to be a fairly quick turnaround.

Hope that helps.

[pavelr21055322]

Jeromie, thank you for disclosing the background of this story.

I'm glad the issue is given the high priority.

Because a lot of people are frustrated right now.

I don't want to find the project in this trap again.

I wonder what are we going to do to avoid such an incident in the future?

I'm thinking about to go AIR way.

But can we compile AIR app to screen-saver?

[Kratika Agarwal]

Hi,

Please see below link for the latest updates on this issue:

Re: Flash Player 20.0.0.267 - ActiveX Embedding Issue

Thanks

[ivanp61579321]

The latest version 20.0.0.270 does not fix the https://bugbase.adobe.com/index.cfm?event=bug&id=4101067

Please check this bug ASAP, there are hundreds of thousands users affected.

I've reported it 3 weeks ago; there are more than 80 votes and 70 notes. Customers are asking for refunds.

[chris.campbell]

We are aware of this issue and are working to see what options are available to us.  It's a top priority and we will have an update on this thread once more information is available.

[ivanp61579321]

Chris, any update on this bug?

Today is exactly one month since this thread has been created.

[chris.campbell]

@ivanp61579321

We hope to push out a beta in the next couple of hours that has a fix for this issue.  We'd like to get your input once it's available to verify that it resolves the problem for you.  I'll post again once the beta has been released.

Thanks,

Chris

[chris.campbell]

We've released a new beta of Flash Player that we believe fixes the following two bugs:

• Bug 4101067‌ - “Unable to play local swf files in Flash Player 20 using 'file' protocol”
• Bug 4098809 - “VB6 Fusion Charts not loading in Flash Player”

If you've been impacted by one of these bugs, please try the beta out and let us know if it helps or you see other issues.

We still have one critical sound bug (Bug 4103304‌ - “Timelines with multiple layers are unable to stop playing sound”) that we are currently working to resolve.  We had hoped to get a test build out today but our internal testing found that we hadn't fully solved the problem.  We're actively working on a new fix and I'm hopeful I'll have something to try in a few days.

Thanks,

Chris