[mapserver-dev] Re: MapServer security issue

[Steve Lime]

In your scenario what's the benefit to the hacker in choosing another
mapfile? They can't get at the contents, not through the MapServer
and there's already a regex pattern applied to mapfile names. That 
pattern is in the source code as opposed to the environment but I
see little value in something other than limiting the extension.

Steve

>>> Jan Hartmann <jhart at frw.uva.nl> 11/19/02 06:25AM >>>
Well, I was very short I'm afraid, but it was Saturday afternoon and I

wanted to see the entry of St. Nicholas ("Santa Claus") in Amsterdam. 
I'll try to sum up in more detail.

The security problem with MapServer CGI is that requests for maps can 
contain pathnames to files anywhere on the WebServer's filesystem.
These 
requests can be scripted by external browsers, so in theory everyone on

the net has some sort of read access to all vector and raster files on

the Webserver's hard disk. Steve's proposal was to add the variables 
DATAPATTERN and FILEPATTERN to the Mapfile. These should contain a 
regular expression that would be used to restrict every further DATA or

FILE access by scripting. That way you can be sure that only those
files 
can be read that match the regular expression and nothing else.

This way the contents of the Mapfile are shielded. However, the Mapfile

as a whole still remains visible to the whole world. To see why this is

a security leak, imagine someone with a public WWW MapServer and a 
MapFile accessing certain GIS-files on his hard disk. In addition, he 
has lots of other GIS files on that same hard disk to be used  with 
private MapScript applications, which also have their own MapFiles.
With 
Steve's solution, the second group of GIS files are impossible to
access 
for the public MapServer. However, the Mapfiles used by the MapScript 
applications can be accessed. Everyone can send  URLs to the public 
Mapserver like "http://.../mapserv?map=<any file>". The pathname of the

mapfile is relative to the MapServer script directory, and can cover
the 
whole hard disk. A MapFile cannot be shielded with a variable within 
that same MapFile (at least I can't imagine how). This way the public 
MapServer can make visible maps that are meant only for private use and

there is no protection against it. Of course, you need to know the 
actual filename of the MapFile, and you can hide this very deep. 
However, you can not guarantee that it will never be found.

A solution would be to add an environmental variable (called e.g. 
MS_MAPFILE_PATTERN), with a regular expression which restricts the 
possible range of MapFiles. This is exactly the same mechanism as 
DATAPATTERN and FILEPATTERN above; the only difference is that it is
not 
in the MapFile, but in the environment. The two other environment 
mechanisms mentioned by Steve can remain as they are; they are very 
handy, and they can hide the MapFiles very effectively, but they cannot

make them completely impossible to access.

Hope this is clearer.

Jan


Steve Lime wrote:
> Too much running through my head these days. Can you sum up the map
> file
> hole? I tried wading through this thread and thought I'd just ask.
At
> the moment
> you can set a mapfile by:
> 
>   - setting the MS_MAPFILE env variable
>   - setting parameter map to some file
>   - setting parameter map to some env variable (i.e.
COMPASS_MAPFILE)
> 
> In any case, the file name is checked against a regex and that file
is
> never returned
> to the user. I use the last option all the time to hide mapfile
> locations and to make
> application management easier.
> 
> 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/16/02 08:13AM >>>
> 
> On second thougthts:
> 
> To allow for multiple MapFiles to be accessed from URL's, MS_MAPFILE

> could be a colon-separated list of allowed mapfiles 
> (file1:file2:file3:...). Each of those could be accessed via the
normal
> 
> ?map=mapfile.parameter. The first one could be the default map.
Coming
> 
> to think of it, you could just as well do this with a regex. And to 
> protect people against themselves, you could make MS_MAPFILE
> obligatory.
> 
> Jan
> 
> Jan Hartmann wrote:
> 
>>Just one final loophole, mentioned by Daniel: the mapfile from the 
>>calling URL. This can come anywhere in the filesystem and you cannot
> 
> 
>>shield that with a regular expression within the mapfile (would be 
>>circular, wouldn't it?). His solution (adding an environment
variable
> 
> 
>>MS_MAPFILE that can override the map-URL parameter) looks fine to
> 
> me.
> 
>