[mapserver-dev] Thoughts on MapServer security audits, vulnerability reports and security releases

[Stephen Woodbridge]

Hi Dev's,

This started out as some private emails, but it is probably more 
appropriate to open it to the dev list to get more input and ideas. So 
here it is:

Daniel Morissette wrote:
 >
 > Good points. I think we should be having this discussion on the -dev
 > list. I did a quick search and found RATS:
 > http://www.fortify.com/security-resources/rats.jsp
 > I'll add a note to my TODO list about doing a deeper search on this.


-------- Original Message --------
Subject: RE: [mapserver-users] Thoughts on MapServer security audits, 
vulnerability reports and security releases
Date: Fri, 9 Jul 2010 14:02:28 -0500
From: Lime, Steve D (DNR) <Steve.Lime at state.mn.us>
To: Daniel Morissette <dmorissette at mapgears.com>,    Stephen Woodbridge 
<woodbri at swoodbridge.com>
References: <4C374A7B.3090401 at mapgears.com> 
<4C3761F8.3090602 at swoodbridge.com> <4C3769B5.6030407 at mapgears.com>

I think ideally we'd have access to an automated tool that we could run 
as part
of standard regression testing. That way it would be an integrated part 
of the
release process. Wonder if there are some good freebies we could use as the
basis of the 6.0 inspection and then in an ongoing fashion. I think this 
might
be helpful in catching straight coding errors (off by one, etc...).

Also, I think we should add a "Security Impact" section to all RFCs to 
force folks
to think about it in the planning stage. This would help at catching 
functional or
architectural errors.

Steve

-----Original Message-----
From: Daniel Morissette [mailto:dmorissette at mapgears.com]
Sent: Friday, July 09, 2010 1:26 PM
To: Stephen Woodbridge
Cc: Lime, Steve D (DNR)
Subject: Re: [mapserver-users] Thoughts on MapServer security audits, 
vulnerability reports and security releases

Stephen Woodbridge wrote:
> 
> It raises an potential issue for 6.0 in my mind that we can probably be
> proactive about. It seems to me that with a major release like 6.0 that
> has many changes and in fact some significant portions of the code
> restructured and rewritten, that we run the risk of introducing new
> security issues.
> 
> I am wondering if it makes sense to line up some new audits around the
> 6.0 release with the intent of fixing security related issues in one of
> the early point releases if we need to?
> 

Hi Steve,

I see what you mean, but unfortunately we don't control when the
security audits happen, we just hear about them after the fact, so we
cannot really line them up in sync with the release. Maybe posting a
comment to that effect in reply to this thread on the list could
encourage potential security people to wait to review 6.0... I dunno?

Note that since the main changes in 6.0 are around the output rendering,
I am not too worried though. Most issues that we've had reported so far
were around validation of input files and parameters (or what one can do
via URLs), and string manipulations. Fortunately output generation comes
at the end of the pipe, once the inputs have been processed... not to
say that there is no risk, but hopefully it's not too high.

Other ideas/suggestions welcome of course

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/