[mapserver-dev] Question about the bad mapfile pattern (vulnerability) check

[Jeff McKenna]

The tricky part here is that most recent packages use the PCRE regular 
expression library, because of its open BSD license, but the "bad" 
pattern hardcoded into the MapServer source is for libregex, which is 
GPL based, and that expression won't work with the PCRE engine.

My thoughts were when the idea of a "MapServer config file" coming, was 
that phew, then users can just point to their valid mapfiles there with 
simple paths or even wildcard paths or directories, and we can 
completely remove that bad pattern stuff from the source code.

So I assumed that the new config file would save us.  In fact the config 
file is just another place to put the bad pattern, which, honestly most 
MapServer users will never understand nor have the time to understand.

I am wondering, when we re-look at the bad pattern stuff, if we can 
think of a way that the new config file can replace the hardcoding 
inside the MapServer source.

I hope it's ok to wonder here out loud, ha.

-jeff







On 2022-02-10 3:05 p.m., Tamas Szekeres wrote:
> Steve,
> 
> I think we cannot avoid to be platform dependent in this regard. A 
> single slash at the beginning on Windows systems should not be accepted, 
> because it can specify a relative path, however a double back slash at 
> the beginning is accepted (absolute path of a network share). Currently 
> the single slash at the beginning is accepted in all platforms.
> Applying environment variables might not be a trivial task in all run 
> time environments, so I think the default behavior should work in that 
> way which can do the right thing in most use cases.
> 
> Best regards,
> 
> Tamas
> 
> 
> Steve Lime <sdlime at gmail.com <mailto:sdlime at gmail.com>> ezt írta 
> (időpont: 2022. febr. 10., Cs, 15:48):
> 
>     The idea was to limit things to local paths with no back references
>     by default. We're not distinguishing between OSes in setting that
>     pattern. It's possible it's a bit overzealous so we could tweak the
>     default if that makes sense across operating systems. It can be
>     overridden by environment variable (or within the config file) and
>     could be turned off completely with an expression that will never match.
> 
>     On Thu, Feb 10, 2022 at 4:34 AM Tamas Szekeres <szekerest at gmail.com
>     <mailto:szekerest at gmail.com>> wrote:
> 
>         Hi Developers,
> 
>         I noticed that the double back slashes are excluded from the
>         accepted mapfile pattern in one of the commits not too long ago
>         according to security vulnerability reasons. The bad patten
>         regex is now looking like:
> 
>         const char *ms_map_bad_pattern_default =
>         "[/\\]{2}|[/\\]?\\.+[/\\]|,";
> 
>         Do we have a specific reason why we don't accept the double back
>         slashes at the beginning of the mapfile path? This normally
>         refers to a network share which is considered to be an absolute
>         path, and our use cases are working like that extensively. I
>         guess we wanted to exclude the relative paths basically, but it
>         seems not to be that case.
>         I'm also wondering if the double forward slashes at the
>         beginning makes much sense to exclude, since I think that is
>         treated as a single forward slash in the unix like systems which
>         is normally accepted.
> 
>         Thanks,
> 
>         Tamas
> 
>         _______________________________________________
>         MapServer-dev mailing list
>         MapServer-dev at lists.osgeo.org <mailto:MapServer-dev at lists.osgeo.org>
>         https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>         <https://lists.osgeo.org/mailman/listinfo/mapserver-dev>
> 
> 
> _______________________________________________
> MapServer-dev mailing list
> MapServer-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev


-- 
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/