Adobe Flash Player mms.cfg settings for Programs Apps and Software

[Marcel5C83]

Hello,

I run an older Visaul Basic software that uses the flash.ocx to run a flash file. Windows blocked this file. I tried to allow the folder the .swf is loaded from but still it didn't work. Does flash.ocx ignore the mms.cfg ?

I put it in both folders:

C:\Windows\SysWOW64\Macromed\Flash\mms.cfg
C:\Windows\System32\Macromed\Flash\mms.cfg

This is the mms.cfg I use:

EOLUninstallDisable=1

EnableAllowList=1

ErrorReportingEnable=1

SilentAutoUpdateEnable=0

EnableInsecureLocalWithFileSystem=1

EnableInsecureAllowListLocalPathMatching=1

EnableInsecureActiveXNavigateToURL=1

AllowListUrlPattern=file:///c:/Users/Logo%20Tipp/AppData/Roaming/Logo/Legacy/swf/lottogross/

AllowListUrlPattern=file:///c:/Users/Tipp-Terminal/AppData/Roaming/Logo/Legacy/swf/lottogross/

AllowListUrlPattern=blob:*

Also the software like JPEX is not working anymore. Can't you allow a software like in AllowListUrlPattern to work with .swf files that are in that directory. I don't understand why it's not working as it should.

[faschimi]

I have the same issue here, trying to unblock content which is expected to be loaded by a Flash player instance inside Articulate Storyline 2. The mms.cfg files placed in Windows folder are only unblocking content inside Internet Explorer. Please let us know if you figure this out...

[jeromiec83223024]

It's possible that Flash Player can't read mms.cfg from the context of your application.  It really depends on how you embedded Flash Player, and since it's not a use-case that we really support or test, it's not something that I have good recommendations about.  I know that people are doing it successfully, but we're outside my wheelhouse. 

Since you're not running in a browser, you can't look in the JavaScript console to see any of the logging output.  This makes it hard to validate whether or not you're getting any output about what's getting blocked.  If you're lucky, it's just that your pattern doesn't match the URI that's ultimately being sent to Flash.

There's a lot of platform/browser-specific normalization and pre-processing that can happen before a request for a given URL gets passed to us (and a lot of that doesn't necessarily happen when you embed Flash like this).  The point of all the logging is to help you get at those actual values as they're presented to Flash.

If you're lucky, just specifying "AllowListUrlPattern=file:*" gets things working.  This might not be optimal, but at that point, you know that mms.cfg is being read.  If not, you're going to have to solve that first, and while I'd be curious about the solution that you arrive at (I'd love to be able to point to an analysis for other folks that run into this), it's easily been a decade since I've played with Visual C#, and I wasn't doing Flash-centric stuff.

Since you can't use TraceOutputEcho in this scenario because you're not in a browser with a JavaScript console, the only way that you'd be able to see any of the debug output necessarily to configure good AllowListUrlPattern rules would be to log trace output to a file. 

File logging is only supported by the Flash Player Debugger variants (intended for use by Flash content developers to debug content), with the TraceFileOutputEnable directive specified in mm.cfg.  Because Microsoft controls the ActiveX installation path on Windows 8 and higher (and they declined to make ActiveX debuggers available for those platforms), you'll only be able to do this on a Windows 7 machine. 

See: https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html for details on how to install and configure the debugger.  The debugger is still available as of today, but those downloads will be taken down eventually, so sooner is better on that front.

At that point, you should be able to follow the instructions in the Enterprise Enablement section of the Admin Guide to log the URIs that are getting blocked.  Ideally, you'd construct a set of matching patterns that constrains access to a limited set of locations sufficient to prevent local Flash content from leaking any sensitive information to the web in the event that you ran malicious content by accident.

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

[Marcel5C83]

Hello,

thanks for reaching out and trying to help. I already tried the file:* pattern but it didn't change anything so I didn't post it here. I thought it may be too wide because there are some restrictions with those patterns.

There are several programs that do not work. I thoguht they should work when i allow the specific folders in which the .swf are located and I allow the program folders. Basically the FFdec.exe which is a Flash Decompiler is not working in that way and my Visual Basic program which uses the flash.ocx to implement a flash file into the software and let it run.

So I really miss a legit way to let it run from softwares which I haven't seen so far.
With my list above I could get it to run in Chrome if I copy the mms.cfg in the correct folder and open an index.html with embed tag. But there is no way so far I saw to get "Software" which runs flash in it, to allow playing flash anymore. "Only if you have an standalone .exe made out of an .swf, but not software who tries to run real .swf files. So I'm still stuck on this one!

Of course there are solutions to uninstall those updates with killswitch or set the timer back. But these are no real solutions for 1000's of pc's where software runs.

So my question remains the same: 

How to allow software to run real flash via the flash.ocx or other to still play flash files?

For my view it seems that it's not possible using the mms.cfg, I even don't know if any Application takes care of the mms.cfg like FFdec.exe or my Visual Basic Software which uses the Flash.ocx. Seems not.

So it seems we are stuck on this one unless there is an automated un-update.exe for those files killing .swf

Because a manual way is too complicated for most users.

[FGsysadmin]

I have the same problem as Marcel5C83, about which I'd posted in another thread (but this thread seems to be more apt) with an HP printer application (HP Solution Center) which HP will not update.

I have determined that the application exe does access mms.cfg (twice, for some reason) when launched; it looks for it in C:\Windows\SysWOW64\Macromed\Flash, it accesses it in read mode, it parses its contents and it closes it; all these operations are marked as "successful". But of course I have no way to tell what the exe does with the information it finds in mms.cfg, and I don't know it it's a standalone Flash application or if it reads .swf files (but from what I gather it should be a standalone Flash application). The "file:*" pattern also does not work in my case.

[Marcel5C83]

How did you find out that the Application access the file? Do you have some kind of "sniffer" logger for that?

[Paulo Cesar5CC5]

You can find wich file the software try to access using this program from Microsoft: Process Monitor - Windows Sysinternals | Microsoft Docs

[jeromiec83223024]

Have you tried adding the EnableInsecureAllowListLocalPathMatching=1 to mms.cfg? 

Flash Player requires the URL being passed in to be valid.  When hosted in a browser, this normalization happens automatically.  This doesn't always happen when Flash Player is hosted in an application (it's up to the application to get this right), and we added a flag to loosen the matching rules to accommodate this. 

There are security implications here.  Enforcing standards-conformant URIs is necessary to solve situations where URLs are ambiguous.  That ambiguity is at the heart of a lot of browser-related security pain over the last two decades.  It's a workaround, but it also opens the door for mischief in the right circumstances.  It would be a disservice to the broad community if this was a copy-paste workaround that got used broadly by a bunch of people on trailing-edge operating systems and browser versions.

I feel obligated to reiterate that for the vast majority of users, continuing to use Flash Player at this point is a bad idea.  Large companies have the resources and expertise necessary to continue using Flash in legacy scenarios safely.  The vast majority of individuals using Flash don't have comparable resources, and simply hoping that things will go well is a recipe for major headaches down the road.

[FGsysadmin]

Yes, I have tried to add that directive.

My current mms.cfg file is as follows:

---

EOLUninstallDisable=1
EnableAllowList=1
ErrorReportingEnable=1
SilentAutoUpdateEnable=0
EnableInsecureLocalWithFileSystem=1
EnableInsecureAllowListLocalPathMatching=1
EnableInsecureActiveXNavigateToURL=1
AllowListUrlPattern=file:*
AllowListUrlPattern=blob:*

---

Process Monitor shows that C:\Windows\SysWOW64\Macromed\Flash\mms.cfg is accessed twice by HP Solution Center ("C:\Program Files (x86)\HP\Digital Imaging\bin\Hpqdirec.exe") when I launch it.

Theoretically, the "AllowListUrlPattern=file:*" directive ("allow any local path") and the "EnableInsecureAllowListLocalPathMatching=1" directive ("don't be strict about URIs compliance to standards") should allow the application to run, at the theoretical expense of security (though I don't see how it could be exploited, expecially if I block Internet access from/to Hpqdirec.exe with Windows Firewall), but instead it makes no difference, and at this point I don't understand why.

[jeromiec83223024]

There's a thread over here on alternate HP packages that might work and don't have Flash dependencies: 

https://community.adobe.com/t5/flash-player/alternative-for-hp-printer-hp-solution-center/m-p/118002...

[Marcel5C83]

I have tried this as well of course. So there is no solution like for Browsers to allow a certain software to access flash files from a certain folder as it still seems by now. Unless the application does something on itself to do so. This is especially about applications using flash.ocx to get things running. 

I would have wished that it has the same value as still running in browsers to be honest. But many people are looking for copy&paste solutions. They change their system time to play old flash games and deinstall the updates that has the killswitch. That may not be the mayority but there are people. And also there are people who would like to let run their software as is it but still have security updates at least for windows. Forcing people to certain things is always what I disliked most. Security is one thing but I still want to decide certain things on my own. And "security" is often misused. Didn't have Chrome 88 just fixed 8 or more “high vulnerability” bugs. Time for a "kill google chrome" campaign now since it took over Flash? But then another “player” will come.

I mean browser must not support flash and stuff. But blocking content on a system-level is a whole new level no one talks about. So yeah in my point of view there has to be an copy&paste solution to let flash run on my own computers as I wish 🙂

[jeromiec83223024]

Chrome 88 dropped support for the PPAPI plug-in interfaces, ending support for all browser plug-ins, including Flash.  Safari and Firefox have also dropped support for Flash Player at this point.  IE and Edge will follow suit soon. 

The option you do have is to run old software.  Ideally, you'd do that safely -- build a VM that's airgapped from the Internet, etc.  Like with any technology, we're not going to stop people with sufficient skills and expertise from doing things that are dangerous. 

If you want to pull all the safety features off your table saw, that's a terrible idea, but you can do it.  Your table saw manufacturer isn't going to tell you how to do that, and for the vast majority of people, it's a wildly inappropriate idea.  You know that when you disable those features, you might be walking around with a few less fingers some day, (or by removing that annoying kickback guard, you might take a 2x4 to the chest -- nobody's stopping you, but you want to have a full grasp of implications before assuming that risk). 

It's pretty much the same deal here.  If you're determined and sufficiently skilled, there are workarounds, and the bar is high enough that the vast majority of people aren't going to get themselves into trouble without understanding at least at a high level that what they're doing is a bad idea.

The optimal solution here really is to find alternatives that don't require Flash Player.  The population of folks that are skilled and confident about using unstafe technology safely aren't generally asking for help, and if you're googling for a copy-and-paste guide, that's a good indication that you're probably better off with the safeties enabled.  It's a huge hassle to do this correctly, and you're almost certainly better off finding a forward-looking alternative.  

[jeromiec83223024]

@Marcel5C83 - This thread got noisy and I'm still interested in understanding why this is failing for your application.  The thing I'm interested about in your situation is the actual log output.  Flash Player should be logging what's getting blocked.

I wrote the following guide for some of our support engineers.  Here's the section on troubleshooting desktop applications.  

Desktop Applications

In the early days of Flash Player, distribution of content on interactive CD-ROMs was common practice.  This led to later practices of developers embedding Flash Player in desktop applications (typically by embedding an IE window) for more expressive User Interfaces.  Flash remains popular for creating animated UI elements in specific scenarios, like HUD overlays in video games.

Ultimately, Adobe AIR (now EOL) became the supported platform for desktop application creation using Flash technology.  In general, we’ve been actively discouraging developers from building applications that leverage the system Flash Player in embedded browser windows for the better part of a decade, but we try not to break existing applications.

In the context of Enterprise Enablement, depending on how Flash Player is leveraged, the application should be able to read and obey directives in mms.cfg.  The challenge is around debugging, particularly on Windows 8 and higher, where the ActiveX installation path is controlled by Microsoft, and neither the latest builds or debugger variants of ActiveX Flash Player are available.

Where possible, the easiest way to debug applications that embed the ActiveX Flash Player is to do it on a Win 7 VM, with the debugger installed and configured for file logging (TraceFileOutputEnable=1 in mm.cfg).

Here’s more detail on configuring the debugger:
https://helpx.adobe.com/flash-player/kb/configure-debugger-version-flash-player.html

Once configured, you should be able to see the debugging messages when URL requests are blocked by EnableAllowList, just like you would in a browser.  Depending on the bit-ness of the application and the version of IE that gets embedded, you may need to put mms.cfg in a different system folder than you would when targeting the browser itself (i.e. C:\Windows\System32 for 64-bit vs C:\Windows\SysWOW64 for 32-bit) folders.

In practice, what’s generally happening is that Flash Player requires valid URIs that conform to RFC 3986.  In the context of desktop applications, those would most likely be local files, with the expected format of file:///c/users/foo/desktop/bar.jpg. 

Instead, we’ve been seeing a variety of malformed values getting passed in.  These are from a popular open-source project that uses Flash for graphical overlays in broadcast video (news chirons, etc):

*** AllowListPreview: AllowList blocks 'C:\Users\labuser\Desktop\CasparCG Server 2.0.7\CasparCG Server\Server\templates\\cg20.fth.pal'. ***

(note both the wrong format and double backslashes)

*** AllowListPreview: AllowList blocks 'file:///C|/Users/labuser/Desktop/CasparCG%20Server%202.0.7/CasparCG%20Server/Server/templates//CASPARCG_FLASH_TEMPLATES_EXAMPLE_PACK_1/ADVANCEDTEMPLATE1.ft'. ***

(note the old-school pipe notation for drive letters)

In these instances, there’s no way to target them with an AllowListUrlPattern directive, because they fail the URI validity check before we even get to the code that tries to match the pattern.

To work around this issue, we added the EnableInsecureAllowListLocalPathMatching directive, which effectively skips the validity checks, allowing AllowListUrlPattern=file:* to match on whatever you throw at it.  If the operating system will resolve it, we’ll match it. 

This opens a whole can of worms in terms of ambiguous URIs, which can lead to things like unexpected network store traversal via UNC path.  Requiring RFC-conformant URIs is intended to solve those issues, but it became obvious as we got more input from the field that there was a class of legacy applications that were not passing in valid URIs. 

Unfortunately, the addition of EnableInsecureAllowListLocalPathMatching landed in the December Flash Player release (32.0.0.465), which was after the last build that Microsoft shipped for Windows 8 and higher.  Organizations that require this feature for the ActiveX Flash Player on Windows 8 and higher will need to license a maintained version of Flash Player from HARMAN in order to gain access to it.

[jeromiec83223024]

So just to clafiry the next steps: 

• Get a configuration that logs
• Examine the logs and take a look at what's getting sent
• Patch your app to send confirming URIs
• Recommend that your enteprise customers license the ActiveX Flash Player from HARMAN if they need the ActiveX Flash Player for more than the next couple months.

I'm super curious about the URIs that are getting sent.  There's no possibility of pushing out an update at this point that would change the behavior, but at that point, we can have an informed look at what's happening.  If there's an edge case that we didn't think of, I can at least debug it and see if there are any useful recommendations.

In terms of addressing this, you probably just want to update your application to normalize those paths to RFC 3986 compliant URIs.

This is what Caspar (the software from the case study above) did. You might be able to just crib the normalization code from their Github repo. This is optimal (at least IMO), because your customers on Win8+ probably aren't on a version of Flash Player that supports EnableInsecureAllowListLocalPathMatching, and their only option to get it is to license a maintained Flash Player from HARMAN moving forward. It's much more cost-effective to just patch the application to pass in a valid URI in the first place. 

At that point, you should be able to look at the logs and write matching AllowListUrlPattern directives that work.

It's also worth pointing out that MSFT will be removing the ActiveX Flash Player that they distributed to Windows 8 and higher via a future mandatory Windows Update.  That package is currently optional, but the next big roll-up update (scheduled around summer) will require it. 

Licensing the ActiveX Flash Player from HARMAN is ultimately going to be necessary for enterprises on Windows 8 and higher.  Adobe was never able to distribute an installer for the ActiveX Flash Player on that platform, so you can't just reach back and get and old version.  HARMAN built an installer that works on Win8+ systems, AFTER the Microsoft Update that removes their Flash distribution has been applied.

Deploying a licened version from HARMAN confers some meaningful benefits -- those builds continue to get functional and security updates.  For enterprises that need to keep Flash deployed, this is the best approach from both a security and operational perspective (they can/should still leverage the AllowList to limit their attack surface).

Without requiring users to license the HARMAN player, using confirming URIs buys you a few months to replace those Flash dependencies with something else before that mandatory MSFT patch gets deployed.

[Marcel5C83 · Accepted solution]

 I basically gave up on this case. It's a cold case for me now. I see that getting to the ground of it would require to log the pathes and setup a vm and track everything but that's not in my area. I'm not the coder of the program tbh I'm more a middleman trying to find a soultion for 2 parties.

All I can say is that my "path" worked for Google Chrome. I could tun the local file in the browser with using my mms.cfg setup but could not let it run with the software. I thought AllowListUrlPattern=file:* will allow all softwares to play anything on my local drive. It does not. Maybe because of the EnableInsecureAllowListLocalPathMatching which is not working on Windows 10 unless you get the HARMAN Flash Player. Or maybe it's not reading the mms.cfg. But I can sent you how it was integrated. Maybe it helps some other people when looking for this thread. I guess there are many people having problems and looking for a good solution.

    ShockwaveFlash1.Height = 9000  '15 * 400

    ShockwaveFlash1.Width = 12000    '15 * 480

    ShockwaveFlash1.Top = 0

    ShockwaveFlash1.Left = 0

   ShockwaveFlash1.Movie = svp & "swf\lottogross\lottogross.swf"

   ShockwaveFlash1.Playing = True

   ShockwaveFlash1.Visible = True

[jeromiec83223024]

Getting Enterprise Enablement to work in Chrome is painful.  The location for mms.cfg is specific to the active Profile in Chrome, and each Chrome Profile has it's own directory tree for Flash data that doesn't correlate to any of the other profiles, or to the mms.cfg that all the other browsers look at. 

It's way easier to do in IE or Firefox ESR.

[FGsysadmin]

I find jeromiec83223024's insight very interesting, thank you for taking the time to discuss it.

I may be able to set up a test environment, but not in the immediate future, I've got too busy of a schedule at the moment.

Is it OK if, once I've gotten round to it (and if), I post back here with the results?

[jeromiec83223024]

I'd just start a new thread with the details relevant to your situation if you're stuck.  I'm more likely to notice it, and we don't have to carry all the extra context from this thread forward that way.