Impending 12 January flash shutoff

[defaultdr11wi5lm2li]

We have an internal intranet only application that has one part dependent on a flash object. I'll startoff by saying I have a working solution to flash not working after 11 January. We only need this to continue working for a few months until we transition to a different piece of software which does not use flash. I've had no success attempting to contact Harman via their webform or via phone.

With the latest versions of flash and setting my pc to 12 January, it did not work. Flash loads and presents an icon instead of loading the flash object. I found that versions of flash up to and including 32.0.0.371 do not have the hard-coded shutoff and after loading that version I have full functionality again setting my pc's clock to future dates. Adding AutoUpdateDiable to mms.cfg and also setting policies to prevent Mozilla (with its 26 January update which should prevent the flash plugin from loading at all) from updating should cover us. However, I had initially been trying to get the later versions of flash working using EnableAllowList and AllowListURLPattern in mms.cfg. I'm still wondering if there is anything I've missed and am posting details below if anyone has an answer or further suggestions.

Using those two parameters in mms.cfg allows the flash object to load post-12 January, but as luck would have it the flash object also makes a socket connection back to an application on the server (the same server where the flash object and entire intranet application itself is hosted). This connection is not working in the flash object when I set the date to 12 January. I get the following error when using the debug version of flash.
Error #2044: Unhandled securityError:. text=Error #2048: Security sandbox violation: http://10.1.15.101/components/ptool.swf cannot load data from 10.1.15.101:8378.

This looks to be a crossdomain access issue. I do have a http://10.1.15.101/crossdomain.xml file at the root of the website and it contains the all inclusive
<allow-access-from domain="*"/>

1) Interestingingly enough, even if I delete this crossdomain.xml file from the website and use any date on my pc from today until 11 January, the flash object works as does the socket connection and I do not get the above error. This kind of makes it look like we don't have a crossdomain access issue after all; I wasn't expecting this part. This is without a mms.cfg file or one only containing
SilentAutoUpdateEnable=0
AutoUpdateDisable=1
EOLUninstallDisable=1

2) If I add the following two lines to mms.cfg, the flash object loads irrespective of what date I have on my pc, but the part dependent on the socket connection does not work and I get the Error#2048.
EnableAllowList=1
AllowListURLPattern=*://10.1.15.101

3) If I keep my pc's clock before 12 January, I get entire functionality from the flash object including the socket connection working by adding this additional line to mms.cfg. (including those from (2) above)
AllowListPreview=1

4) However, this last setting is ignored after EOL 12 January, so the socket connection again fails if I set my pc clock to 12 January or later.

Any ideas I might try? Like I said 32.0.0.371 works as my fix for a few months but I did spend some time getting here and am now curious. I did try adding some variations of AllowListURLPattern into mms.cfg but haven't come up with a winner. Everything I've seen about Error#2048 points to a crossdomain fix, but since I can delete the file which is there now and not break the application it looks directly like something else happening with the EOL hard-coded shutoff that I should be able to mitigate with an entry in mms.cfg.

Thanks to anyone who has a suggestion or solution.

[defaultdr11wi5lm2li]

I think I found a solution. The connection with the error appeared to not be using http or https so I couldn't whitelist it, but adding AllowListRootMovieOnly=1 has worked around the issue.

[jeromiec83223024]

This is a decent workaround.  The risk with AllowListRootMovieOnly is that any child SWFs that get loaded can also load content.  It's possible to imagine scenarios where this might result in the ability of an attacker to get cilent machines on your network to load malware, but it's very situational. 

If you wanted to tighten your policy down in the future, you could use the AllowListPreview feature to log all of the requests.  They'll give you the exact URI that Flash Player sees, which you can use to populate an AllowListUrlPattern directive.

You can find more details on this in the Enterprise Enablement section of the Admin Guide, here: 

https://www.adobe.com/devnet/flashplayer/articles/flash_player_admin_guide.html

[jeromiec83223024]

It occured to me that it might not be the socket that's at issue, but that you need Flash Player 32.0.0.465 or higher to target URIs by IP.  If you're using the ActiveX Flash Player on Windows 8 or higher, Microsoft chose not to ship those releases because they weren't security-related (and Microsoft controls the install locations for Flash on Win8+, such that all updates had to come via Windows Update).  Administrators in this boat could either work around this by configuring a DNS alias for the host and making any necessary configuration changes and/or redirect to ensure that it gets used, or they could license and deploy a current, maintained version of the ActiveX Flash Player from Harman (which we would recommend to all enterprise users, as the licensed HARMAN builds will continue to get compatibility and security updates). 

There's more on the Flash Player support offering from HARMAN, here: 

https://www.adobe.com/products/flashplayer/enterprise-end-of-life.html

[defaultdr11wi5lm2li]

Thanks, this is an intranet only application with no public facing access so I'm trying to keep mitigations only with firefox and letting edge and chrome update and block flash -- so no we're not using IE/ActiveX flash here. From the debug output, it appears the application is not using http, https, or file (smb) so AllowListURL wasn't working and AllowListRootMovieOnly seems to pick up general socket connections.

I've had absolutley no luck getting Harman to respond to a phone call, voice mail, or web form submission for months and at this point we'll only need to keep this working for a few months.

The only unexpected issue we had yesterday was that the flash object (Flex developed) can call up a child window with text fields. On some Windows 10 clients (not all) we cannot edit the text nor even click into it and use the arrow keys to move the cursor around within the text. I've matched firefox and flash versions with the PCs where this does work and had no initial luck. I eventually found that if I keep the child window open and open say notepad and then click back into the child window I can now edit the text there. This appears to have nothing to do with the flash cutoff and is more likely a timing issue with the flash object ActionScript or NPAPI plugin. If this work as a viable workaround for us I'll likely let it be unless anyone here has a suggestion on it.

[jeromiec83223024 · Accepted solution]

Based on what you're describing, it's most likely Firefox not passing focus to us.  It's interesting that it happens consistently.  If we were talking about this a year ago, I would have most likely opened a bug with them.  🙂

Normally, the workaround I'd suggest is to use another browser, but that's not useful.  The 32-bit Firefox has a totally different sandbox architecture than 64-bit Firefox (our bolt-on sandbox vs their native one).  Switching from one to the other might do it.  I'd try that first.

If that doesn't help and I were trying to solve this, I'd probably be looking at how I could render the page differently.  If I was injecting the object into the DOM using JavaScript, I'd play around with maybe using an actual HTML object tag, or think about the order that the page is getting rendered in and permuting that so that the Flash content is loaded late in the lifecycle.  Not sure if it would help, but it's where I'd probably start poking around.

[jeromiec83223024]

Also, just in defense of the HARMAN guys, I saw a graph of sign-ups the other day, and the last few weeks are that exponential hockey-stick shape.  I'm sorry that they didn't follow up.  They were absolutely pummeled with late-breaking requests, and what they accomplished under the circumstances was pretty impressive.  We had a sense that they'd get overwhelmed during the last couple weeks as the folks that might not have been paying attention started seeing all of the "goodbye Flash" articles in the tech press.  We tried to get the word out in advance so that it wouldn't be a huge spike at the end, but human nature is human nature.  🙂

For what it's worth, the incoming volume seems to have normalized to something manageable at this point, and I expect that the response would be much different now.  Given your timeline, it sounds like you made the right choice under the circumstances.