[Geomoose-users] Security Advisory for MS4W users

Jeff McKenna jmckenna at gatewaygeomatics.com
Thu Apr 1 09:58:22 PDT 2021


Hi Jim,

I appreciate your advice and responding so quickly (believe me, I did 
the same for this initial report).  I also am honored (not sure the 
correct word) that GeoMoose considers MS4W as its secure home for 
Windows installations.  I have been working very hard on this, for the 
whole MapServer community and also to hopefully make the Windows MS4W 
examples easier to understand, and how to test them locally.

Although I can't say much about the exact report yet, I hope/think I can 
at the minimum say that the report was not for MS4W specifically; but 
that doesn't mean that we shouldn't all take this warning and 'make sure 
our home is secure', especially for all Windows and Unix-based 
installations.   These security steps were first implemented in 
MapServer source back in 2009, but a lot of us have not been using these 
specific environment variables mentioned in the advisory.

I also can appreciate that many developers (not saying this was your 
case) will not or did not click my recommended link for MS4W users to 
follow, instead just read the MapServer advisory wording.  (this has all 
been >10 days of effort, quite exhausting, by Steve, myself and others) 
  After all that exhausting effort, I went further and put together 
step-by-step (with screen captures) instructions specifically for MS4W 
users, to both enable and (more importantly) test these settings locally.

You will see that I broke them down to strongly recommended, 
recommended, and optional changes for MS4W users.

I think this thinking, of the MAP= path security, has triggered some 
thoughts about the upcoming 8.0 release and how to possibly enable other 
settings to handle this (such as an .ini file listing all of your secure 
mapfile paths).  Discussions I am sure will open publicly soon on this.

For now, your questions and thoughts are definitely good, and your steps 
are exactly what is often done for public-facing installations.  For 
MS4W users right now, I suggest that they add the 'strongly recommended' 
MS_MAP_PATTERN setting as explained in detail on the new MS4W security 
section ( 
https://ms4w.com/README_INSTALL.html#securing-your-ms4w-installation ), 
testing through the steps listed there, and consider the other methods 
as well.

Regarding the GeoMoose package for MapServer, as stated in my MS4W 
advisory announcement, this will be tackled soon for MS4W, likely in the 
form of the setup.exe installer modifying the MS_MAP_PATTERN on-the-fly 
for all MS4W apps (GeoMoose etc).  However, my gut feeling is that the 
MapServer 8.0 release that is upcoming is going to tackle this head-on, 
and MS4W will adapt.

As I told Steve during this intense chaos recently, MS4W is often at the 
forefront of MapServer packages, most times literally 2 full years ahead 
of what other packages on all the operating systems distribute, and, I 
predict it will be the same this time.

Your GeoMoose MS4W package could have a commented-out section basically 
pointing to this new MS4W security steps link, and commented 
MS_MAP_PATTERN path etc.      But my gut feeling is to first 'handle our 
own homes' (meaning that if you have MS4W installed or any MapServer 
installation on any Operating System on a public-facing server) do 
enable the strongly recommended security setting, and then future 
MS4W/MapServer releases will likely tighten this more.

I hope this makes sense.  I also worry that these long intense messages 
should be more for the GeoMoose PSC list, as I don't want to scare 
users, but, on the other hand getting everyone to think of security can 
be a good thing.

Phew.  Exhausting but important stuff.

Well, hope everyone has a nice and healthy long Easter weekend.

I'm not closing the discussion, just trying to take a breath, ha.

Thanks all,

-jeff










On 2021-03-31 8:05 p.m., Jim Klassen wrote:
> For most of the GeoMoose sites I run, I make the mapfile look like the 
> endpoint (e.g. "/datasets/wms.map?SERVICE=WMS&..." instead of 
> "/cgi-bin/mapserv?map=/datasets/wms.map&SERVICE=WMS&..."). This URL 
> layout has a number of advantages and has worked really well for us for 
> over a decade now under various implementations.
> 
> The current implementation uses a combination of the Apache 
> AddHandler/Action directives and RewriteRules to work.  Using Action 
> lets Apache do most of the heavy lifting with security and access 
> control because the normal Apache file/path access control rules (ex. 
> under <Directory> and <Files>) and path sanitation rules (cleanup up 
> attempts to evade rules by using /../ or other special characters, 
> requires files to exist, etc.) apply. RewriteRules then set MS_MAPFILE 
> and MS_MAP_NO_PATH environment variables so people can't override it 
> with the map= parameter (in the QUERY_STRING or in a POST).
> 
> Writing a regex that is safe against people using unconventional ways of 
> expressing a URL (especially under windows where case insensitivity of 
> the filesystem comes in to play) is not trivial. Using the Apache 
> <Location> or <LocationMatch> directives and not missing some 
> unconventional way of expressing the URL is also not trivial.  Action 
> helps a lot here in avoiding common mistakes.
> 
> Besides sidestepping the map=/path problem, this allows giving different 
> users access to different mapfiles using standard Apache directives.  It 
> also makes the mapfile accessed be the main URL component in the server 
> logs (instead of just a bunch of calls to /cgi-bin/mapserv).
> 
> The main catch with this is MapServer's automatic calculation of the 
> server URL (for GetCapabilities) becomes incorrect.  MapServer 
> calculates the URL to the mapserv CGI file (which is inaccessible to end 
> users) instead of the URL to the mapfile.  This can be worked around by 
> setting the "wxs_onlineresource" metadata in each mapfile.  However, as 
> setting and maintaining that metadata value for every mapfile gets 
> cumbersome, I wrote a small patch to MapServer [1] that lets it 
> calculate the right path by default.
> 
> Also, we've always used normal CGI (not FastCGI) so I'm not sure if this 
> causes any issues under FastCGI.
> 
> apache.conf snippet:
> 
>      <Directory "/srv/mapserver/cgi-bin">
>          AllowOverride None
>          Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
> 
>          # Only allow specified files
>          Require all denied
> 
>          # Mapserver
>          <Files "mapserv">
>              Require all granted
> 
>              # log to apache error.log
>              SetEnv MS_ERRORFILE "stderr"
>              SetEnv MS_MAP_NO_PATH "true"
> 
>              RewriteEngine on
> 
>              RewriteCond %{env:REDIRECT_HANDLER} ^mapserver
>              RewriteCond %{PATH_INFO} ^/datasets/(.*)
>              RewriteRule .* - [C,env=MS_MAPFILE:/srv/datasets/%1]
>              RewriteRule .* - [C,env=MS_MAP_PATTERN:^/srv/datasets/%1$]
>              RewriteRule .* - [C,env=MS_ENCRYPTION_KEY:/srv/secret.key]
>              RewriteRule .* - [L]
> 
>              RewriteCond %{env:REDIRECT_HANDLER} ^mapserver
>              RewriteCond %{PATH_INFO} ^/moredatasets/(.*)
>              RewriteRule .* - [env=MS_MAPFILE:/srv2/moredatasets/%1,L]
> 
>              RewriteRule .* - [F]
>          </Files>
>      </Directory>
>      ScriptAliasMatch ^/apps/mapserver/cgi-bin/(.*) 
> /srv/mapserver/cgi-bin/$2
> 
>      <Directory "/srv/datasets/">
>          Require all denied
> 
>          Action mapserver /apps/mapserver/cgi-bin/mapserv
>          AddHandler mapserver .map
>          <Files "*.map">
>              Require all granted
>          </Files>
>      </Directory>
>      Alias /datasets/ /srv/datasets/
> 
>      <Directory "/srv2/moredatasets/">
>          Require all denied
> 
>          Action mapserver /apps/mapserver/cgi-bin/mapserv
>          AddHandler mapserver .map
>          <Files "*.map">
>              Require group moredatasets
>          </Files>
>          <Files "*.pdf">
>              Require all granted
>          </Files>
>     </Directory>
>      Alias /moredatasets/ /srv2/moredatasets/
> 
> 
> [1] 
> https://github.com/klassenjs/mapserver/commit/2d69a4bd27e668fa5e8fad6b43d3f81e3e1dea56 
> 
> 
> On 3/31/21 3:02 PM, Jeff McKenna wrote:
>> Dear GeoMoose community, please see the message below for those 
>> running MS4W (or MapServer on any operating system) on public-facing 
>> servers. thank-you.
>>
>>
>>
>> -------- Forwarded Message --------
>>
>> Hello everyone,
>>
>> As the security of MS4W on your public-facing server is important, 
>> please take some time to review the possible security steps to enable 
>> for MS4W at: 
>> https://ms4w.com/README_INSTALL.html#securing-your-ms4w-installation 
>> You will notice MS4W examples, as well as instructions to use an 
>> online tool for testing your MS4W instance.
>>
>> As stated there, setting the *MS_MAP_PATTERN* environment variable is 
>> strongly recommended for your server instance.
>>
>> The past few weeks (and especially the past few days, which were full 
>> of intense regular expression testing) I have been working with Steve 
>> Lime closely and other MapServer steering committee members, to 
>> release the security advisory for MapServer: 
>> https://mapserver.org/announcements/2021-03-30-limit-mapfile-access.html
>>
>> Future MS4W releases will likely be tighter, with definitely the 
>> popular .exe installer setting & enabling the *MS_MAP_PATTERN* regular 
>> expression on-the-fly, for new installations, as well as providing a 
>> few default settings in the distributed Apache httpd.conf file.
>>
>> MS4W security is my priority, always has been, and I hope the examples 
>> and expressions that I provided in the MS4W readme above, help 
>> everyone implement, and take some of the fear of expressions away.
>>
>> Thank-you all.
>>
>>
>> -- 
>> Thank-you for using MS4W.
>> "MS4W: open doors as well as windows"
>>
>> -jeff
>>
>>
> 
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geomoose-users


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


More information about the Geomoose-users mailing list