Error in Flash Player 30

[alanc78729854]

Hi,

I'm trying to load one of my games using Flash Player 30 in Chrome. The game errors with the error message "ArgumentError: Error #3806" and fails to load. I was able to load the game on Firefox running Flash Player 29 but as soon as I manually upgraded to Flash Player 30 the game fails to load.

Is there a known issue which would cause this issue or can someone point me in the correct direction to file a bug! The game has been working correctly for nearly 4 years so I'm hoping that Adobe can fix the issue in Flash Player since an update to the game will be difficult.

You can see the issue here: Play SAS 4 - Ninja Kiwi

Regards,

Alan

[alanc78729854]

I've added a bug to the official bug tracker although I suspect that the issue won't be fixed by Adobe since it appears that certain APIs have been deprecated with no warning. You can see the issue here:  Tracker

[jeromiec83223024 · Accepted solution]

Thanks for the head's up (and for taking the time to file a bug).

We don't like to break backwards compatibility (and we rarely do it), but security is our highest priority.  In this instance, we chose to disable functionality in order to protect users against vulnerabilities in a pretty big chunk of CPU hardware currently in the market.  We chose this specific approach very carefully, to ensure that the impact to the average user would be minimal.  This was the most surgical change we could make.

While it's possible to re-enable this functionality on the client, it increases their attack surface.  We're recommend talking to the game developer to see if they can eliminate the use of shared ByteArrays.

You can find additional details in this blog post:

Spectre / Meltdown Mitigations

[Alexey_M]

Hello
We use Workers to decode webp graphics. After I realized that shareable is not available any more, I tried to remove it. I thought that copying of ByteArrays might not be a problem... But in fact it doesn't work at all. Randomly we're getting Error #2030: End of file was encountered. exceptions on operations with such ByteArrays.

[jeromiec83223024]

We'd be happy to debug this and see what we can do.  Please either file a bug at tracker.adobe.com (reply here with the bug ID -- I'll get an email notification and will personally follow up), or just send me a link to a sample that reproduces the problem.

[Alexey_M]

I haven't manage yet to make an isolated sample, but I just understand what goes wrong.

A create a worker and two MessageChannel objects - one to send data to a worker and one to receive. At some random points I'm getting the same data I sent to a worker! Logs from a worker shows that it works as expected. So it looks like there is a mess with message channels!

[Alexey_M]

I made an example. There are sources of the client app and the worker. Everyhing works fine if you uncomment shareable = true lines, but brokes down if shareable is false.

Here it is:

https://www.dropbox.com/s/vdy361lnyxziyhi/messages_bug.zip?dl=0Dropbox - message_bug.zip

[Robert Mc Dowell]

Do you mean that we cannot use shared byteArray anymore?!???

so what's the solution to communicate between workers?

[alanc78729854]

Hi,

Thanks for the response and I understand the need to protect end users. I do however find the lack of communication on this issue quite disappointing. After initially figuring out what was happening I went looking for any information about the changes and I was unable to find anything, even the blog post you linked to was only posted after the patch was pushed live.  The URL which was hard-coded into the Flash Player client redirected to a 404 and the player and your official docs weren't updated to reflect the change.

Regards,

Alan

[eddieone1]

How to share memory between workers then?

Also, someone at adobe needs to update all he docs. Adobe Flash Platform * Communicating between workers

[jeromiec83223024]

Basically, you'll need to choose one of other options listed on that page.  What works best is going to be highly dependent on your application's needs.  There's always Scout to help profile, too.

We disabled Shared ByteArrays to prevent Spectre-style attacks against the CPU.  It was the most surgical option available.  I don't expect that we're going to be able to re-enable them.  In light of Spectre, high-resolution timing in the browser in any technology is pretty problematic.  We're working closely with the OS and browser vendors to make sure that the web platform (including Flash) stays secure.  Similar timing attacks against the CPU seem to be getting a lot of attention from the research community at the moment.  We'll continue to watch the research closely and respond as necessary.

We're actively working with the tech writing team to get the ASDocs updated, but there's no magic one-liner that's going to provide a perfect, universal fix.

[eddieone1]

Ok thanks for the fast response here. I have a feeling the death of Flash will be a bumpy ride. We will ride it out though. I suggested to the developer to try shared objects (flash cookie) as a workaround. I'm not clear if it will work yet.

[Robert Mc Dowell]

eddieone1

Flash will never die

this issue has nothing to do with flash itself, it's a major CPU architecture problem that concerns all run time engines

The thing I still cannot catch is how a so big security breach has been discovered something like 30 years after the first CPU that includes this security hole....

btw it's a massive regression knowing that shared bytearray is extremely useful. I just hope that the brilliant Actionscript Adobe engineers will have a genius solution soon,

as they allowed us to create wonderful application experiences during the last 20 years.

[jeromiec83223024]

We actually surveyed the use of Shared ByteArray invocations across our beta audience (where we have the ability to collect these kinds of analytics) as part of the decision-making process for identifying an approach to mitigating these vulnerabilities, and we found that only a very, very small amount of content actually uses it.  While breaking the feature is not ideal, we're committed to being responsible actors in the web ecosystem.  This was the best of the available terrible options.   

[jeromiec83223024]

I think it's going to depend on what they're doing.  LSOs require disk reads/writes, which is going to be on the order of 100k times slower than memory reads/writes.  There were faster options on the page that you referenced, but it's highly dependent on what they're doing.  LSOs were way down on the list of things that were recommended.  If consistency and speed weren't important to the original design, Shared ByteArray was probably overkill in the first place.

[jeromiec83223024]

Yeah, we agree that there's definitely room for improvement.  We're already talking about how we might streamline our processes around documentation to allow us to be more agile when situations like this arise.

To put it in context, in response to an exploit discovered in the wild, we decided to ship this release a week early (vs. shipping a one-off release with just the 0-day patch, then following up with this release a week later).  This ends up being less work, particularly for enterprise administrators with large managed environments.  Normally, we'd be using the next week to carefully review all the documentation and stage it, but the priority was to get the patch into the world as quickly as possible.  We definitely would have preferred to have had the documentation in place simultaneously, but given the choice between holding the patch for documentation or shipping it and backfilling the documentation, I'll happily stand by the decision. 

Thanks again for your patience, and sorry about the inconvenience.

[dews]

Why isn't there mention of this in the Release Notes??  This is a HUGE change for those of us actually using this - the fact that I had to be told of this by a client absolutely sucks.

PARTICULARLY because we were under the impression that we're "in the know" by reading the release notes!  Come on.

[_maria_]

From the Release Notes Flash Player 30 AIR 30 :

Spectre / Meltdown Mitigations

In response to a class of recently disclosed vulnerabilities in popular CPU hardware related to data cache timing (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754), known popularly as Spectre and Meltdown, we are disabling the ‘shareable’ property of the ActionScript ByteArray class by default.  Administrators can turn this feature back on using the following MMS properties:

EnableInsecureByteArrayShareable

Short Description:
Allows Administrators to override the Flash Player 30 and above default behavior of restricting the “shareable” property of the ActionScript ByteArray API class.

Detailed Description:
EnableInsecureByteArrayShareable = [0,1] (0=false, 1=true)

This setting will allow Administrators to override the Flash Player 30 and above default behavior of restricting the “shareable” property of the ActionScript ByteArray API class. Shared ByteArrays are used to share data between threads with ActionScript “Workers.” Shared ByteArrays are an advanced feature of the ActionScript API set and not commonly used in the vast majority of published Flash content. For increased security, we recommend administrators leave this feature disabled.

EnableInsecureByteArrayShareableDomain

Short Description:
Allows Administrators to override the Flash Player 30 and above default behavior of restricting the “shareable” property of the ActionScript ByteArray API class on a per-domain basis.

Detailed Description:
EnableInsecureByteArrayShareableDomain = domain name or IP address

By default, Flash Player 30 and above will no longer allow the “shareable” property of the ActionScript ByteArray API class. The EnableInsecureByteArrayShareableDomain settings provide exceptions to that rule. Administrators can create a “white list” of approved domain names or IP addresses to which the EnableInsecureByteArrayShareable setting will apply. If the active security context is in the list of domains and IP addresses, then access to the sharable ByteArray property will be allowed. Otherwise, sharable ByteArray access will be denied.

For domain names, prefixing a * wildcard is allowed. For example, *.adobe.com would allow all Flash content with the “shareable” property to run on www.adobe.com, get.adobe.com, helpx.adobe.com, and so on. Wildcards are not allowed when specifying IP addresses.

For example, the following settings allow SWFs using the shareable ByteArray property to only run on servers at www.mydomain.com and 10.1.1.10:

EnableInsecureByteArrayShareableDomain=www.mydomain.com
EnableInsecureByteArrayShareableDomain=10.1.1.10

For domain names, prefixing a * wildcard is allowed.

Example:

EnableInsecureByteArrayShareableDomain=*.mydomain.com

This would allow all Flash content with the “shareable” property to run on www.mydomain.com, foo.mydomain.com, and so on. Wildcards are not allowed when specifying IP addresses.

[dews]

This was NOT in the the Release Notes on labs.adobe.com - doesn't really help us if you we don't have the heads up BEFORE you make the change.

[_maria_]

You didn't specify which release notes you were referring to, thus, I posted the Flash Player 30.0.0.113 Release Notes.

[dews]

With all due respect, I think it goes without saying that we need to know before you release.

We didn't notice the blog post on the 7th - labs we check every few days.

For future reference, was it a mistake not to update the release notes on labs?  If not, then I'll make a note for us to also check the Blog.

[Hahanokill]

Maria_vargas, I have tried to use the feature:

EnableInsecureByteArrayShareableDomain=(site name)

However it seems that I am not using it correctly as the game mentioned in the post does not seem to work when I do this no matter if I whitelist all the .swf files and original site the game is being played on, the site name, or the individual .swf files on their own.

It seems I am missing something to whitelist on this site given that the generalised feature:

EnableInsecureByteArrayShareable=1

makes the game load properly like it should, however this is obviously a much bigger security risk that I would not like to take, given that it disables accross the board the security fix in Flash 30.

Is it possible to correct exactly where I have gone wrong in my whitelisting?

Here it is:

EnableInsecureByteArrayShareable=0

EnableInsecureByteArrayShareableDomain=ninjakiwi.com/Games/Action/Play/SAS-Zombie-Assault-4.html 

EnableInsecureByteArrayShareableDomain=assets.nkstatic.com/Games/gameswfs/sas4/sas4.swf?v=20180815-03

EnableInsecureByteArrayShareableDomain=assets.nkstatic.com/Games/loaders/800x620.swf?v=20180815-03

EnableInsecureByteArrayShareableDomain=cdn.nkstatic.com/assets/expressInstall-2c88f1d04e149aadaa3f54d2b71b9422.swf

[Robert Mc Dowell]

alanc78729854

the website shows an AS error for me:

Error #2044: Unhandled error:. text=Flash IMA sdk is deprecated.

    at com.google.ads.ima.api::AdsLoader/createSdkLoader()

    at com.google.ads.ima.api::AdsLoader/load()

    at com.google.ads.ima.api::AdsLoader/invokeRemoteMethod()

    at com.google.ads.ima.api::AdsLoader/requestAds()

    at ima3_preloader_1_4_fla::MainTimeline/Initialize()

    at ima3_preloader_1_4_fla::MainTimeline/frame1()

[jeromiec83223024]

This isn't our bug.

It looks like the content provider is using a Google library for Interactive Media Ads which is no longer supported by Google.  The content provider also doesn't handle the case where calls to that library fails, hence the unhandled error.  It looks like they'll need to change their ad insertion stuff.

Error #2044: Unhandled error:. text=Flash IMA sdk is deprecated.

[alanc78729854]

Hi,

We know about that error but it doesn't affect the normal loading of the game. We see the same error in FP29.

Hopefully we'll be able to get an update out to let the game work with FP30

Regards,

Alan