Skip to main content
D
default8q1hivyqc0vk
Participant
September 11, 2020
Answered

IE 11 ignores AllowListUrlPattern in mms.cfg

  • September 11, 2020
  • 2 replies
  • 30019 views

I'm setting 

EOLUninstallDisable=1
SilentAutoUpdateEnable=0
EnableAllowList=1
AutoUpdateDisable=0
AllowListUrlPattern=http://localhost/flash/
ErrorReportingEnable=1
EnableInsecureLocalWithFileSystem=1

 

In:

  • %localappdata%\Google\Chrome\User Data\Default\Pepper Data\Shockwave Flash\System\mms.cfg
  • %localappdata%\Microsoft\Edge\User Data\Default\Pepper Data\Shockwave Flash\System\mms.cfg
  • %windir%System32\Macromed\Flash\mms.cfg
  • %windir%\SysWOW64\Macromed\Flash\mms.cfg

 

After I change the date to 2021, I'm able to run flash form localhost in Chrome, Edge Chromium and Firefox. But I'm not able to run it in IE11 or any app that makes use of Flash.ocx. 

 

Other info:

  • Firefox and Chromium browsers use 32.0.0.433
  • IE11 uses 32.0.0.387 which is the windows embedded version of flash.
  • Running windows 10 Pro Version 10.0.18362 N/A Build 18362, experiencing the same behavior on Windows 10 Pro 10.0.19041 N/A Build 1904
  • Encodng is set to UTF-8
  • I've tried restarting the machine.

 

SO url:https://stackoverflow.com/questions/63799628/internet-explorer-ignores-flash-mms-cfg-settings

 

Anyone got any idea what I should be doing to have it running in IE11 on Win 10 Pro with the date set after 2021?

    This topic has been closed for replies.
    Correct answer jeromiec83223024

    Sorry, I realized what was happening yesterday.  The version of IE that you're on is older than the documentation. 

     

    When we initially released this feature, we used the directive names EnableWhitelist, WhitelistPreview, WhitelistUrlPattern.  Shortly after, in relation to a company-wide engineering decision, we updated those directive names to use the more inclusive language that you see in our admin guide (EnableAllowList, AllowListPreview, AllowListUrlPattern).  I thought about documenting those directives as deprecated, but given the intent and our proximity to Flash EOL, I felt like enshrining the old directives in the documentation for perpetuity (because this final version of the guide will live on for a loooong time in enterprise admin communities), it undermined the goal of moving towards better engineering practices around inclusivity.  My hope was that because of the narrow audience for this particular feature, and the short timeline that it would have been in-market, it wouldn't be a big deal (and the new implementation supports both the new and old directive names). 

     

    On Windows 8 and higher, Microsoft distributes Flash Player via Windows Update, and their policy is to only ship security-bearing releases at this point.  Flash Player is a less useful attack vector becauase it's click-to-play in most browsers now, so there's a lot less action happening on that front.  The stars all lined up in a way that kept that disparity in the market for way longer than I had planned (and pushing out updates to our internal documentation is super hard and time-consuming for really boring reason).  Microsoft will be pushing out an update next month, which will bring that platform into parity with the others.

     

    In the meantime, you can either use the older less-inclusive language, or just wait a couple weeks and your mms.cfg should work as-is. 

     

    Sorry for the confusion!

    2 replies

    jeromiec83223024
    Community Manager
    jeromiec83223024Community Manager
    Community Manager
    September 29, 2020

    Please see the Enterprise Enablement section on page 28:

    https://www.adobe.com/content/dam/acom/en/devnet/flashplayer/articles/flash_player_admin_guide/pdf/latest/flash_player_32_0_admin_guide.pdf

     

    In particular, check out the stuff about troubleshooting with TraceOutputEcho.  ErrorReportingEnable is a setting exclusive to the Flash Player debugger, which does not exist on the generally available player.  The file mm.cfg is the debugger config file, whereas mms.cfg is the config file for the generally available player. Microsoft declined to make a debugger version available via their channel, and since we can't actually install a Flash Player in the required location on Windows 8 and higher, there isn't one available.  We added the ability to output errors to the JavaScript console to facilitate testing on ActiveX on Win8 and higher.

     

    Just to confirm, you're running a local webserver, which serves up content over HTTP on the host "localhost"?  I'm wondering if it's actually something to do with that.  I'll have to go test it on my Windows machine tomorrow, but a lot of the URL resolution stuff is platform/browser specific.  I could see that behaving different on just ActiveX.  You might try accessing content via a local IP instead. (e.g. http://127.0.0.1/flash/)

    jeromiec83223024
    Community Manager
    jeromiec83223024Community ManagerCorrect answer
    Community Manager
    October 2, 2020

    Sorry, I realized what was happening yesterday.  The version of IE that you're on is older than the documentation. 

     

    When we initially released this feature, we used the directive names EnableWhitelist, WhitelistPreview, WhitelistUrlPattern.  Shortly after, in relation to a company-wide engineering decision, we updated those directive names to use the more inclusive language that you see in our admin guide (EnableAllowList, AllowListPreview, AllowListUrlPattern).  I thought about documenting those directives as deprecated, but given the intent and our proximity to Flash EOL, I felt like enshrining the old directives in the documentation for perpetuity (because this final version of the guide will live on for a loooong time in enterprise admin communities), it undermined the goal of moving towards better engineering practices around inclusivity.  My hope was that because of the narrow audience for this particular feature, and the short timeline that it would have been in-market, it wouldn't be a big deal (and the new implementation supports both the new and old directive names). 

     

    On Windows 8 and higher, Microsoft distributes Flash Player via Windows Update, and their policy is to only ship security-bearing releases at this point.  Flash Player is a less useful attack vector becauase it's click-to-play in most browsers now, so there's a lot less action happening on that front.  The stars all lined up in a way that kept that disparity in the market for way longer than I had planned (and pushing out updates to our internal documentation is super hard and time-consuming for really boring reason).  Microsoft will be pushing out an update next month, which will bring that platform into parity with the others.

     

    In the meantime, you can either use the older less-inclusive language, or just wait a couple weeks and your mms.cfg should work as-is. 

     

    Sorry for the confusion!

    jeromiec83223024
    Community Manager
    jeromiec83223024Community Manager
    Community Manager
    January 13, 2021

    Hi,

    I'm able to whitelist a pair of flash player and Firefox.
    However, I'm unable to whitelist another webpage which has port numbers.
    Can anyone advise how can I make flash player read wildcard for portnumber in whitelist url pattern?
    My Landing page has port number 7000 while content resides on other ports.
    Is it possible to use wildcard for port numbers or to allow all ports in this domain/subdomain automatically?

    AllowlistUrlPattern=https://www.example.com/ -- didnt work
    AllowlistUrlPattern=https://www.example.com:*/ -- didnt work

    Instead of coding as below, can anyone suggest a wildcard for ports?
    AllowlistUrlPattern=https://www.example.com:7000/
    AllowlistUrlPattern=https://www.example.com:7600/

    Thanks,
    Aditya


    You cannot use a wildcard for ports. 

     

    Since Flash Player has the ability to make requests to arbitrary sockets, it's possible to build a port scanner in ActionScript, which would run from client machines, behind your firewall.  Requiring you to define individual entries for ports is annoying depending on the number of ports you're using, but for organizations running an unmaintained Flash Player after EOL, we believe it's important to help minimize the potential attack surface by default.  It's too tempting to slap in a wildcard without thinking about (or simply knowing about) all of the potential consequences (like unnecessarily exposing ports to admin UIs, etc). 

     

    Your workaround using AllowListRootMovieOnly will work fine, as long as you're confident that your application will only load trusted, controlled content.  It's off by default, because there is the potential that a parent SWF could load an untrusted child SWF supplied by an attacker in some scenarios.  Imagine a Flash-based tech support portal that allows customer uploads.  As long as you're confident that your application will not encounter or load untrusted content, this is a convenient way to simplify the required configuration. 

     

    For scenarios where you're not confident that this is guaranteed, we'd strongly recommend leaving this flag off, and using AllowListPreview to discover the full list of URIs that need to be allowed, and allowing them surgically.

     

    We also strongly recommend that enterprises that need to continue to use Flash Player license a current, maintained copy of Flash Player from HARMAN.  Those versions continue to get the maintenance fixes and security updates that will minimize your risk moving forward.

    D
    damien5FBF
    Participant
    September 29, 2020

    Im trying to setup the mms.cfg file but Internet explorer 11 and flash player 32.0.0.387 seems to be ignoring the config as well has anyone found a resolution?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices