Skip to main content
D
default07gsrb5lhpuz
Participating Frequently
December 7, 2020
Answered

Bug in mms.cfg if filename contains [ or ]

  • December 7, 2020
  • 2 replies
  • 1101 views

You're able to whitelist domains inside C:\Windows\SysWow64\Macromed\Flash\mms.cfg

 

For example:

AllowListUrlPattern=*://*.example.com/

 

However, there is currently a big bug:

If you try to play any flash on the whitelisted domain that contains [ or ] in the filename the flash plugin will think it is not on the whitelisted domain.

 

This will work: https://example.com/hello.swf

This will not work: https://example.com/hello[].swf

This will not work: https://example.com/he][o.swf

This will not work: https://example.com/hello[.swf

This will not work: https://example.com/[hello].swf

All five SHOULD work.

 

Adobe, please fix this before you abandon flash. All file names must work! I suspect it might have something to do with your IPv6 parser?

 

(Also please consider being able to just whitelist every URL, would make my life easier.)

    This topic has been closed for replies.
    Correct answer jeromiec83223024

    This flag shipped in the last release.  We ship monthly, aligned to Microsoft's Patch Tuesday.  The December train has left the station. 

     

    The workaround is pretty straightforward -- don't put square brackets in filenames.  It's not ideal, but it's where we are.

     

    The latest copy of the admin guide has the details on the new flag, but given that it didn't help you, don't leave it enabled.  Assuming that you're confident that your mms.cfg is in the right location and being read, it's kind of a moot point.  (Check out the Enteprise Enblement section and the explanation of how to use AllowListPreview if you're not confident about that.)

     

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

     

    2 replies

    jeromiec83223024
    jeromiec83223024Correct answer
    Inspiring
    December 11, 2020

    This flag shipped in the last release.  We ship monthly, aligned to Microsoft's Patch Tuesday.  The December train has left the station. 

     

    The workaround is pretty straightforward -- don't put square brackets in filenames.  It's not ideal, but it's where we are.

     

    The latest copy of the admin guide has the details on the new flag, but given that it didn't help you, don't leave it enabled.  Assuming that you're confident that your mms.cfg is in the right location and being read, it's kind of a moot point.  (Check out the Enteprise Enblement section and the explanation of how to use AllowListPreview if you're not confident about that.)

     

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

     

    D
    default07gsrb5lhpuzAuthor
    Participating Frequently
    December 11, 2020

    So make a release outside of Microsoft's echo system? This fix is not of interest to those that will abandon flash next year so making additional fixes that are only available on your website is okay.

     

    What kind of company is Adobe if you use "Microsoft Patch Tuesday" as an excuse to leave a broken final release? As far as I'm aware there are three Tuesdays left in the year. How could you not discover this bug anyway, do you not do any testing over there? Brackets in file names is not exactly uncommon in filenames. {} is broken in addition to [].

     

    I'm also beginning to suspect you have a bug in the detection of local file paths, I can't get AllowListUrlPattern to work on any swf file on my desktop. Trying to play through Media Player Classic with the plugin (not the flash projector). You couldn't give me a direct answer in private message what I should put in mms.cfg to get it to work.

     

    This is how the greatest format to ever hit the web deserves to be treated? Fading out, left with known bugs in the final release. The legacy of Adobe. It is starting to look like the best solution to all of this is to hack the flash plugin to remove your buggy kill switch, or failing that use an older plugin that is several years old. It will have less patches but what can we really do if Adobe refuses to release a working final product?

     

    I might be able to live with not having brackets in filenames but if Adobe really have made it impossible to play local files with the plugin that's too much. If I'm wrong, and I hope I am, please reply to me with a working mms.cfg example that allows a local flash file to be played. file:* didn't work when I tried and neither did an absolute path to the flash file (tried several variations).

    D
    default07gsrb5lhpuzAuthor
    Participating Frequently
    December 18, 2020

    Note that this issue is not resolved. I can't play local flash files using the flash plugin (inside Media Player Classic). This issue could be related to Windows 10. I've spoken with someone else who was still on Windows 7 and he was able to whitelist local swf files by using "AllowListUrlPattern = file:*" together with "EnableInsecureAllowListLocalPathMatching = 1". But this does not work for me on Windows 10.

     

    Since Adobe failed to detect the []{} bug it isn't far-fetched to think Adobe simply overlooked something related to local file paths as well. I can't believe that Adobe won't fix flash and thinks it is fine to have this as the final version.

     

    What I'm having most trouble understanding is why Adobe thought it was necessary to put a kill switch into the flash plugin in the first place. You'd think most browsers dropping NPAPI support would be enough to cover 99.9% of the world's population, WHY nuke the plugin itself?

    D
    default07gsrb5lhpuzAuthor
    Participating Frequently
    December 9, 2020

    This is the reponse I got from Adobe staff 7 hours ago in a private message:

     

    Sadly, it's way too late.
The final update for Flash Player shipped this morning.
This is not going to get fixed.
You might try setting the flag:
EnableInsecureAllowLocalPathMatching=1
We added this to make matching more forgiving, but it also opens a whole bunch of security stuff...

     

    So they will not fix the bug. Even though flash support is supposed to last until December 31st. That's just over three weeks from now, this bug report shouldn't be "way too late".

     

    Setting EnableInsecureAllowLocalPathMatching to 1 in mms.cfg does not help. It seems to be a hidden flag, can't find a reference to it in the Adobe Flash Player 32.0 Administration Guide (PDF) or anywhere else online. Would have been nice to know exactly what it does and what "a whole bunch of security stuff" means.

    T
    Test Screen Name
    Legend
    December 9, 2020

    That's the way with security issues. Publishing details tells the bad guys what to target. So we just have to put up with things going away "for our own good". 

    D
    default07gsrb5lhpuzAuthor
    Participating Frequently
    December 10, 2020

    Why not just release a binary without an extension and with no information on what it does? That way you'd be safe from the bad guys. Sure you have to spend a year figuring out how to use the thing but you'll be safe doing it. Unless your bad guys does the same thing I guess.

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