[mapserver-dev] Re: MapServer security issue

Daniel Morissette morissette at dmsolutions.ca
Mon Nov 4 18:16:35 EST 2002


Guys,

There are actually other vulnerabilities that I will not disclose to
this list for obvious reasons.  What do other developers think?

Some options that come to mind are:

- Have the ability to compile MapServer in a "safe" mode where no
filename can be changed via the URL... actually this could be the
default starting with 3.7, and a special option would be required in
order to enable changing things like data paths in a URL

- Modify MapServer to limit a mapfile to a given set of
sub-directories... this could be handled via the new msBuildPath()
function that is used everywhere in version 3.7 to access files. 
However there are always chances that we could overlook one place or
another and leave a hole open.  (You have to think about database
connections or other parameters not stored as filenames)

- Another safety feature would be to disable the use of the 'map=...'
parameter in the URL when the MS_MAPFILE environment variable is set. 
In the current implementation if MS_MAPFILE is set then it is still
possible to override its value with the map=... parameter in the URL.

Any other suggestion?

Daniel


Steve Lime wrote:
> 
> Thanks Jan, I'll forward this to the developers list for discussion.
> Another
> fix would simply be to not allow changing of DATA via a URL.
> 
> Steve
> 
> Stephen Lime
> Data & Applications Manager
> 
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
> 651-297-2937
> 
> >>> Jan Hartmann <jhart at frw.uva.nl> 11/04/02 06:43AM >>>
> Hello Steve,
> 
> I wasn't sure whether this should be posted to any of the mapserver
> lists, so I just send it to you personally. If you think more people
> should have a look at it, please feel free to forward.
> 
> Jan
> 
> --------------------------------------------------------------------------
> 
> Has anyone thought about the following security risk in MapServer CGI:
> 
> MapServer reads its data files (GIS or raster) from a path specified by
> 
> the DATA statement in the LAYER section of the MapFile. This filename
> is
> usually hard-coded in the MapFile, but it can also be set with a
> CGI-variable from the calling URL. Take for example a MapServer CGI
> running as
> 
> http://mapserver.mydomain.com/scripts/mapserv
> 
> and a MapFile called default.map with the following items:
> 
> LAYER
>    NAME map1
>    DATA "/web/shapefiles/map1.shp"
>    ...
>    ...
>    ...
> END
> 
> Usually you will create a map with an URL like:
> 
> http://mapserver.mydomain.com/scripts/mapserv?map=default.map
> 
> which will display "map1.shp". However, it is perfectly possible to get
> 
> a map from this same MapServer with:
> 
> http://mapserver.mydomain.com/scripts/mapserv?map=default.map&map_layer_0_data="any_local_file"
> 
> which can display any shapefile on your file system, within or without
> 
> your Web environment. The trouble is, this can done by everyone on the
> Web.
> 
> Of course, you need to know an actual existing filename, and you only
> get back read-only raster results, so the actual security risk is not
> that big. However, IMO WebServers should NEVER  have access to the
> whole
> file system, however restricted this access might be, but only to
> specifically designated file areas.
> 
> It wouldn't be too hard to stop this gap: just make something like
> SHAPEPATH obligatory, not only for shapefiles, but also for OGR and
> raster files. Existing applications could just add SHAPEPATH "/" or
> SHAPEPATH "c:\", if they don't mind exposing their whole filesystem.
> Others could use this as a sort of root location for their map-data,
> and
>   shield everything they wouldn't wish to be been seen from the
> outside.
> 
> Jan Hartmann
> Department of Geography,
> University of Amsterdam
> jhart at frw.uva.nl

-- 
------------------------------------------------------------
 Daniel Morissette               morissette at dmsolutions.ca
 DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------



More information about the mapserver-dev mailing list