[5017] in WWW Security List Archive
Re: Security issues in Apache?
daemon@ATHENA.MIT.EDU (Steve Phelps)
Thu Apr 10 12:41:35 1997
Date: Thu, 10 Apr 1997 14:45:15 +0100
To: www-security@ns2.rutgers.edu
From: Steve Phelps <steve@epic.co.uk>
Cc: <ben@algroup.co.uk>, <petrilli@amber.org>, <riddle@is.rice.edu>,
<rjc@n2k.com>
Errors-To: owner-www-security@ns2.rutgers.edu
>
>> Agreed. But Apache does need to run as root if you want to open port 80
>(or
>> any other low numbered port), as you well know.
>
>If you run Linux I would suggest patching the TCP/IP stack to remove this
>restriction, allowing processes in a group INET to connect to low numbered
>ports.
You then make it very easy for non-privelaged processes to masquerade as OS
services. An unpriveleged user could run a program that pretends to be a
mailer running on port 25, but which in fact is a malicious program that
makes connections to hosts behind, say, an internal packet filter. i.e.
you're making it very easy for users to forge source ports. If you had a
setup where you had a packet filter isolating your web server from an
internal network, and that packet filter had rules, saying, for example,
"connections from the web server to the internal network are allowed if the
source port is 25 because it is inbound email" then you could be in trouble.
This point is probably mute because you should never entirely trust the
source port in TCP/IP packet because it is so easy to forge anyway, but I'd
still feel a bit uncomfortable allowing non-privelaged processes to connect
below 1024.
The best way of dealing with the root problem if you're really paranoid is
to put a chroot'ed su wrapper around the httpd invokation and run it from
inetd, i.e. make a script called httpd:
<--tear here->
#!/bin/csh
/usr/sbin/chroot /usr/local/httpd bin/su nobody -c 'bin/httpd'
<------->
and run this from inetd. This would, of course, incur an overhead on making
a connection to the web server.
But there's really not a lot of point in doing this (IMHO) if the web server
program chroot's and setuid's itself and it should be really easy to verify
that it does in fact do so without resorting to formal proof of the
semantics of C code.
