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

[sy56595285]

Multithreading without shared memory is 99.9% useless.

It wasn't very useful with shareable bytearray: starting workers is extremely expensive and you had to waste time for encoding/decoding objects to bytes, but was still helpful for huge tasks.

Now even this possibility is lost. Force enabling feature is not an option because client organizations won't mess with that, and you can't just set it in swf embed code on the page.

All the time to make flash multithreading work is now just wasted, plus time needed to rewrite code back.

Security? This change can neither save flash player reputation, nor can it really protect users from hardware vulnerability.

[Robert Mc Dowell]

"Force enabling feature"

you mean "force disabling a feature"....

Everyone knows how computers, smartphones and all electronic devices are not and will never be 100% secure.

People who think that the fault is always Flash are just ignorant and morons.

Now mitigate is always better than not do anything.

[sy56595285]

No, I mean enabling. Existing installations use it. Flash player update just breaks important functionality.

You can add 'EnableInsecureByteArrayShareable=1' to mm.cfg to restore the feature, but it's likely not doable in practice on all the machines/networks which require it.

This vulnerability is minor risk. Killing functionality is a real trouble. Probably everyone for whom security was the primary concern already abandoned using flash or never used it, so I guess this 'better mitigation' affects only those who need shareable arrays more than minor theoretical security gain.

[Robert Mc Dowell]

be patient, there is always a good solution at the end. We are all working hard for the best results, and for sure today it became

very complex, more than years ago where security was not really a threat. Personally I pass the half of my work time to stress test my code and system for security purpose. so imagine a component like Flash that must deal with billions of different machines...

[jeromiec83223024]

Sorry this impacted you.

If your application is deployed in an enterprise space, whitelisting the functionality is a pretty painless workaround.  For consumer applications, it's obviously problematic.  The intent was very much to disable the ability for random content to use this functionality.

Also, it's not about reputation.  It's about doing the right thing.  It's why we report vulnerabilities publicly (just because a piece of software isn't reporting vulnerabilities doesn't mean that they don't exist), work closely with partners in academia and industry to stay on top of research, invest heavily in constantly hardening the product, and make the hard calls about functionality when they need to be made. 

Given that Flash Player is only around through 2020 and it's going to continue to become more and more difficult for end-users to run Flash Player in the browser before then, your efforts would probably be better spent transitioning the content to HTML5/JavaScript/WebAssembly for long-term compatibility.

[Alexey_M]

I've found a workaround for the ByteArray in MessageChannel problem. Everything works if I put a ByteArray inside of an Object. So I changed channel.send(dataArray) to channel.send({"data": dataArray}) and problem disappeared. It looks like there is an optimisation somewhere inside of a MessageChannel which works with ByteArray messages in a special way... and which is broken in case of missing shareable = true.