Address flaw in CGI mapfile loading that makes it possible to bypass security controls (#6313)

[sdlime]

This pull request addresses a critical flaw identified in issue #6313. The fix forces the mapfile value through validation if it's pulled from an environment variable or given as a path. --Steve

[rouault]

I've just added 4d631fc to fix a memory leak which was very likely what the ASAN config of Travis-CI didn't like. Hopefully that will make it happy

[sdlime]

The pull request does a few other things:

• adds validation to exclude standard CGI environment variables as map values
• adds ability to add additional user-defined filtering against environment variable values (MS_MAP_ENV_PATTERN)
• simplifies MS_MAP_PATTERN writing by excluding problematic character sets (e.g. ..) from map values by default.

What does this mean for users? This represents a critical flaw and all users should upgrade ASAP.

If you've not used MS_MAP_PATTERN or MS_MAP_NO_PATH as part of securing your installation then this doesn't have much impact. That said, you should upgrade and make use of those controls to limit where mapfiles can be accessed.

If you've relied on MS_MAP_PATTERN exclusively, you should upgrade and should be in good shape. However, it's a great time to review and test MS_MAP_PATTERN.

If you've relied on MS_MAP_NO_PATH primarily (like me), you should upgrade and set a value for MS_MAP_PATTERN. You might consider also setting a value for MS_MAP_ENV_PATTERN if you have a standard way of naming environment variables that reference mapfiles (for example, mine all end in _MAPFILE).

--Steve

[sdlime]

I've just added 4d631fc to fix a memory leak which was very likely what the ASAN config of Travis-CI didn't like. Hopefully that will make it happy

Thanks @rouault! Once the tests pass then I can merge and the backport to 7.6 can happen. Hopefully can do a couple of cherry-picks for 7.0 to 7.4 branches.