[mapserver-users] Map server security issue

[Thorsten Fischer]

> Hi Folks:
> Does anyone know map server security issue  ? We just installed the
> MapServer on our system. We would need  a fairly detailed report on
> any security issues of a from-scratch server-based application.

Doing some security consulting work in addition to my job at mapmedia,
(which besically involves setting up mapserver applications) i wondered
about that question myself, but I did not find the time so far to
investigate to the extent I would like to.

First you should refine your question; what do you mean by security
issues. Do
you need protection from mapserver being used as an entry point to your
network? Do you need protection of data stored on the same box along with
it? Or do you rely heavily on the software, such that you do not want to
have it brought down? And do you want to connect it to the internet or
have it deployed for internal use only?

Hmm, instead of bringing general security knowledge to you (that your app
relies on the security of your environment and so on), i would
concentrate on the question if mapserver can serve as an entry
point to the box itself. I suggest that you look for suspicious lines of
code like the dreaded strcpy() and his brethren to locate potential buffer
overflows:

~/src/CVS/mapserver # grep "strcpy" *.c | wc -l
     49

Which means there are 49 cases of strcpy() usage in the base source dir.

This is generally not a good thing. Though most of those lines involve
only fixed strings (like file type suffixes), strcpy() should be avoided.
A lot of other functions can be abused in this way, causing buffer
overflows to inject code to be executed, possibly delivering a remote 
shell to the attacker which grants him the rights of the program executing
it.

You should probably watch out for people overloading the box if you plan
to run it on lot of data; placing a thousand or so requests at the same
time is done easily by a script, while processing all of them can prove
difficult. You might want to restrict the number of
connections to your server on a per-ip basis or a similar scheme.
A customer of ours once decided to use Java/Mapscript. Unfortunately for
them, they also decided to do most of the implementation work themselves.
Because they never told us exactly what they did, we still do not know
whether it was their own hacking of mapscript, or the fault of swig, or
maybe mapserver itself; but the thing segfaulted away when ~¹00
connections were coming in at the same time. So you want to have your
installation undergo a lot of stress testing before you are possibly the
target of a DoS.


Make sure you do not store any important or sensitive data along with
mapserver on the same box. It might not have a bad security record, but it
has not security record at all. That said, you will not find a written
security report or extensive testing of the app so far.


To end this, a short anecdote from some friends of mine. They wondered
about security in the predecessor of the current ArcIMS, I think it's name
was Mapobjects server? Anyway, they started to send the thing some lines
of parameters, which, after them exceeding 256 characters, caused the
server to crash. The bug was reproduced easily, and they even tried it
online on one of ESRI's own demo sites. Of course, it worked.

Hence they contacted ESRI. The reply: a) the bug is known, b) it would not
be fixed and c) you could write an ASP page to wrap around it and parse
overlong lines away.

Add your own thoughts on that yourself


Hope that helps a bit.


Please note that anything said in this mail is based on personal opinion
and insight only, and is in no way related to my employer.

thorsten fischer

--

thorsten fischer : frosch (at) derfrosch (dot) de

hostien in groesseren mengen sind schwer zu beschaffen