Zero Day patch deployed has affected some websites,
Videos will not launch in IE11 with FP 184.108.40.206 installed.
Works fine in Chrome on same machine and works in Edge on Win10.
If we use earlier version of Flash Player (v29) then videos work. But then we are vulnerable to attacks in the wild.
This needs to be fixed.
None of the videos that I can see on Microsoft Stream are Flash. They're HTML5 video on both Chrome and IE11.
If you right-click on an affected video, do you see "About Flash Player" in the context menu? If so, can you send me a link to one?
No. There is no "About Adobe Flash Player 220.127.116.11" in the context menu but after the installation of the Adobe Flash Player zero day patch to upgrade to version 18.104.22.168 these videos have become blocked in IE11 on Win7
Okay, I was able to reproduce this and track this down to a security-related change in Flash Player. It was working fine for me in IE on Win10 as well, but I looked at Win7 today and it was failing.
This is related to a proactive mitigation for Spectre-style attacks against the CPU.
You can add one of the following directives to mms.cfg to disable this mitigation.
See page 54 of the Flash Player System Administrator's Guide for additional details:
Thanks for the possible resolution.
My questions here are as follows:
Really appreciate your assistance but more interested in the lack of assistance or provision of information by Adobe.
This particular change was a proactive mitigation for Spectre-style attacks against Intel CPUs. We rarely make the decision to wholesale break functionality, but we also frequently have to make the tough calls between multiple terrible choices. When there's an elegant or transparent change that can be made, we're always going to go for that.
We don't pre-announce security changes, because we can see from the data that attackers see and respond to any pre-announcements that we make. While we'd love to be able to pre-communicate changes to the development community, the reality of the modern security landscape is such that we don't have that luxury.
If you have mission critical use cases that rely on Flash Player, we'd recommend that you participate in our beta program. We publish weekly builds, and we'd strongly recommend testing your critical use-cases with them. We watch feedback carefully, and do our best to make sure that we're not introducing new problems in the field. You can find details at https://www.adobe.com/go/flashplayerbeta.
As you can imagine, earlier feedback is better. We release on 4-week cycles, and we have much more flexibility at the beginning of a release than we do at the end. It's probably worth mentioning that while we have several million clients participating in the beta, nobody reported this particular issue until after it shipped.
In terms of this specific issue, it's important to point out that Flash Player is *not* a video player. You can build a video player on top of it. In this instance, the video player being used in this context uses Shared ByteArrays. It's a clever technique, but there are several other ways to accomplish what they're doing that aren't impacted.
My understanding is that we've provided guidance to the group that maintains that video player on how to remove this dependency; however, they're far downstream from us, and I have no insight into when they would update the video player, or when those changes would get published on Microsoft's servers.
We're also not planning to re-enable Shared ByteArrays. They're off by default, and that's the right disposition under the circumstances. If the research or ecosystem changes in a way that contraindicates our mitigation, we might consider changing the default in the future, but I'm not seeing any evidence of an impending change at this time.
Whether or not you need to "fix this" each month is really driven by how you deploy Flash Player. It's common for enterprise organizations to deploy a custom mms.cfg (and there might be some other configuration options that you might find interesting, depending on your organization's needs and paranoia level).
You can find details on the various deployment mechanisms and configuration flags here:
You *will* need to continue to deploy an mms.cfg file with these flag(s) for as long as you want Shared ByteArrays in Flash Player to remain enabled. It will be up to you to determine when that functionality is no longer needed and remove the flag or delete the custom mms.cfg that you've deployed.
Thank you for a detailed and comprehensive response to my questions above. I do understand the many security aspects that have to be addressed and managed these days. My apologies if I came across a bit strong earlier. I guess we may have to manage this going forward. Please note we raised this with Microsoft as well and are hoping that they will address the issues on their site(s). I think we can close this conversation as you provided all the answers.
No problem. We don't like we stuff breaks either, and we totally get the frustration.
Flash Player lives in an incredibly complex problem space that isn't necessarily obvious from the outside. I'm happy to at least try and explain why we make decisions when they're causing people grief. If you would have asked me a few months about about whether or not Shared ByteArrays had anything to do with encrypted video playback, I would have told you that it was super unlikely.
Trying to extrapolate what people are doing with a fundamental set of APIs is a little like trying to see into the future. You're always going to be surprised.
The best we can really do under the circumstances is to empower people with controls that let them manage any unexpected fallout for mission-critical uses, while minimizing the attack surface across the broader population.
Copy link to clipboard
Tuesday's release (in tandem with an update to Microsoft's video player) removes the dependency on the functionality that was impacted, and gets video playback working again. You should no longer need the mms.cfg flags previously recommended as a workaround. Simply update to the latest Flash Player. If you deployed those flags earlier, we'd recommend that you remove them to re-enable those security mitigations.
What update to Microsoft's video player are you talking about ?
I've flash player 22.214.171.124 installed and the Windows 7 August 2018 update roll-up installed (KB4343900) but the issue still occures.
According to Microsoft, the original issue is resolved. We've confirmed the same.
It sounds like maybe you're experiencing something distinct.
What happens if you clear your browser cache?
If that doesn't help, point me to a representative link.
We tested on several computers and the issue is the same.
The issue occurs on the folowing site but you need an account to connect :https://customers.oase-office.eu
I've aded the following lines in the mms.cfg and the video are playing without issue now.
Seems to be very similar with what is described above.
The site you provided embeds a specific, old version of Azure Media Player (1.8.0).
The change that solves this issue is in Azure Media Player 2.1.9. You'll probably want to research best practice for embedding their player in a way that ensures that you're using the latest updates, and then your content accordingly.
Here's their changelist:
Many thanks for this answer. We will get in touch with the owner of the site.