[261] in WWW Security List Archive
Re: Secure W3 Server
daemon@ATHENA.MIT.EDU (Ken Shores)
Tue Dec 13 19:25:57 1994
Date: Tue, 13 Dec 1994 16:31:44 -0500
To: hharamis@cohesive.com, www-security@ns1.rutgers.edu
From: Ken Shores <kshores@draper.com>
Reply-To: Ken Shores <kshores@draper.com>
At 11:42 PM 12/12/94 -0800, hharamis@cohesive.com wrote:
>
>Does anybody have an opinion on which public domain w3 server is
>most secure? A lot of people talk about the fact that some of these
>servers are large in size. Sounds to me like the old sendmail problem.
Well, what do you mean by "secure"? All of the ones I know are secure, as
long as they don't have bugs which would prevent them from operating as
documented and the installer configures them in a reasonable manner. Both
the CERN and NCSA Unix daemons, and MacHTTP allow you to define what files are
accessible, and where executeables live. All three would be vulnerable to
either internal bugs, or misconfiguration by the user. Depending on your
security policy (explicit or implicit) this may be "good enough". There's
no such thing as absolute security.
The NCSA server is smaller, so if code size/complexity is your main concern,
it's probably better than CERN. Both are too large to really get comfortable
about, at least for me. I think CERN has better access controls, so
you have better control over how you want to configure it, and that may make
it a better choice depending on your requirements.
IMHO you are more likely to introduce an insecurity through a misconfiguration
than to be hit by a server bug, although I would plan for both on a server
I was installing (but that's MY security policy). (I'm counting a poorly
written "exec" script as a misconfiguration, and that's probably the easiest
way to introduce a vulnerability of any).
You can constrain the potential vulnerability by, as Dorian suggested, running
the server on a stripped down non-multitasking system (MacHTTP on a dedicated
Macintosh, for example). You can also constrain the vulnerability by running
the server changeroot on a Unix system. I prefer this method, as it removes
any dependance on complex access control code in the server, and replaces it
with trust of the simpler code in the OS. I'm actually surprised none of them
support this feature; it's pretty trivial to implement. I modified CERN with
about 25 lines of code, and most of that was to allow configuration through
the config file, all it really takes is one line in the right place:
if (chroot("/your/root/here") < 0 || chdir("/") < 0) exit(1);
All of this concerns server security, rather than protocol security, and I've
been yelled at before for discussing server security on this list, so please
take any followups to me private.
Ken
P.S. Note that the above will break "SIGHUP" processing since it can't reread
the config file once it's chroot'ed.
-----
Ken Shores, Sr. Network Analyst The Charles Stark Draper Laboratory, Inc.
kss1376@pop.draper.com 555 Technology Square, Cambridge, MA 02139-3563
(617) 258-2529 Mail Stop 33
