[mapserver-dev] Re: MapServer security issue

[Jan Hartmann]

I think the main problem (unauthorized disk access via DATA, TEMPLATE, 
FONTSET, TMP or other variables) has been taken care of by your regex 
solution (very good idea by the way). I'm not that afraid of unescaped 
character or buffer overflow, but checking them is always a good idea. 
Buffers should be reasonably large of course, because so much can be 
passed to MapServer.

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.

Daniel, do these solutions check with the other security risks you 
mentioned? Are there additional risks with PHP-MapScript?

Jan

Steve Lime wrote:
> I'm implementing my suggestion of last week, should be functional this
> weekend.
> I agree that some sort of test should be contrived to make sure CGI
> input is 
> properly sanitized. The CGI form parsing stuff is old, but reliable
> code from
> NCSA. It has been patched as as necessary over the years. I'm guessing
> that
> code should be scrutinized to make sure everything is being escaped
> properly.
> I've also thought about putting a throttle in place to limit the size
> of a total
> request and for any individual data. This would mean checking content
> lengths
> and bombing if requests are too large. Might be effective in thwarting
> certain
> attacks aimed at buffer overflows. 
> 
> 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/12/02 11:38AM >>>
> 
> Yes, I was thinking of the HTTP_REFERER environment variable, which is
> 
> set by the server if it processes a request coming from another webpage
> 
> (i.e. not from a directly typed-in URL). In theory, this would make it
> 
> possible to discriminate between calls to the MapServer CGI coming from
> 
> inside or outside the same server environment. On second thoughts this
> 
> is not a good idea:
> 
> - The sending browser has to set the "referer:" line in the request 
> header of the web-page. Not all browsers do this
> - Servers can be configured not to set this variable
> - The request header can be easily spoofed by using telnet or netcat to
> 
> send a request to the server and adding explicitly a false "referrer:"
> 
> header line
> 
> As far as I could find out there is no really secure way to prevent a 
> CGI program from being started up from anywhere on the web and letting
> 
> it do whatever it was programmed to do. So security has to come from 
> within the MapServer CGI. I guess Steve's last proposal (setting a 
> regular expression in the MapFile to check for access to the DATA and 
> MAP variables) offers the most flexibility with the least programming 
> effort (or change for existing applications). To be even more secure, 
> perhaps someone should do a quick check for the security of all
> possible 
> CGI variables that MapServer can process (an unbelievable lot!)
> 
> 
> Jan
> 
> 
> Steve Lime wrote:
> 
>>I like this idea, but how to implement. I assume you'd have to look
>>at the referer which I thought was a bit inconsistant between
>>browser vendors. Thoughts?
>>
>>What about a PATH variable at the LAYER level, which if defined
>>would limit where DATA could be found. With out a limiting PATH
>>we could disable changing of the DATA property. Same thing
>>could apply to HTML templates.
>>
>>Steve
>>
>>Stephen Lime
>>Data & Applications Manager
>>
>>Minnesota DNR
>>500 Lafayette Road
>>St. Paul, MN 55155
>>651-297-2937
>>
> 
> 
>