You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by zeno <ze...@cgisecurity.net> on 2002/11/06 19:00:56 UTC
[users@httpd] Apache permission problem: No fix planned in near future...
Hello,
I noticed a permission issue in apache when dealing with modules. I recently
installed mod_proxy on apache 1.3.27 and setup caching of requested documents. I noticed
that these files where owned, and created by uid nobody(the webserver uid). Looking on another
box running mod_ssl I also noticed that the "mutex", and "ssl_scache.db" where also owned
by the webserver uid. I was then thinking what if a malicious cgi user attempted to modify
these files if SUexec wasn't enabled? I ran the test below.
cgi-new:/usr/local/apache/proxy# ls -al
total 44
drwxr-sr-x 11 nobody nogroup 4096 Oct 22 04:59 .
drwxr-sr-x 12 root staff 4096 Oct 18 07:07 ..
-rw-r--r-- 1 nobody nogroup 0 Oct 22 04:59 .time
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 0
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 2
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 A
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 H
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 P
drwx--S--- 5 nobody nogroup 4096 Oct 22 04:59 _
drwx--S--- 4 nobody nogroup 4096 Oct 22 04:59 g
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 h
drwx--S--- 3 nobody nogroup 4096 Oct 22 04:59 s
Now, if I have a cgi script or ssi tag running and suexec IS NOT enabled I now have the webserver
uid. This also means I have permission to modify the cache of mod_proxy, delete it, poison it
etc... (more points mentioned below)
So I created a little script to test this.
cgi-new:/usr/local/apache/proxy# cat ../cgi-bin/bad
#!/usr/bin/perl
#
$sys = `rm -rf /usr/local/apache/proxy`;
print "Content-type: text/plain\n\n";
print "Hello world!\n";
cgi-new:/usr/local/apache/proxy#
cgi-new:/usr/local/apache/proxy# lynx -dump 127.0.0.1/cgi-bin/bad
Hello world!
cgi-new:/usr/local/apache/proxy#
cgi-new:/usr/local/apache/proxy# ls -al
total 8
drwxr-sr-x 2 nobody nogroup 4096 Oct 22 05:02 .
drwxr-sr-x 12 root staff 4096 Oct 18 07:07 ..
cgi-new:/usr/local/apache/proxy#
In this example I deleted the cache of mod_proxy. This isn't just limited to cgi
execution. According to apache's SUexec page below Suexec only wraps CGI and SSI.
http://httpd.apache.org/docs/suexec.html
This means things like php,python, or other apache language plugins are not wrapped, and
all run as the webserver uid. This means the following.
1. A malicious cgi,php,etc user can disrupt a apache module. This can be achieved by modifying or
deleting a file used by a module. In mod_proxies case the cache files can be modified.
2. A web hacker finds a web application hole either in cgi(without suexec enabled on apache)
or php script. From here
the attacker notices the webserver is running mod_xxx. He can modify or delete any file
the module creates, which could yield to a denial of service attack, or in mod_proxies case
cache poisoning and cache deletion.
Now SUexec is a solution for protection against this type of attack for SSI and CGI scripts. People
running mod_php,python,etc do not have a wrapper that allows changing of user permissions.
I contacted apache numerious times and was told
that this is a well known issue. I asked them to show me some sort of documentation explaining this
"well known" threat. I was only pointed back to the suexec page (which doesn't fix users of php or
other language plugins). After further chatting I was told that apache 2.x in the future will
have something to address this, but that 1.3.x wouldn't. They suggested I contact each and every
module vendor and talk them into coding either a "daemon" or "suexec like" program which could allow
these modules to write to files as another user. Aka "we don't feel like fixing it so its your problem".
Does anybody else on this list find it disturbing that a well known vendor such as apache acknowledges
a problem, and rather then fixing it blame the third party module coders because of their API design
flaw?
- zeno@cgisecurity.com
PS: In case anybody is wondering apache was contacted by me 3 weeks ago therefore plenty of time
to address this if they wanted to...
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache permission problem: No fix planned in near
future...
Posted by Joshua Slive <jo...@slive.ca>.
On Wed, 6 Nov 2002, zeno wrote:
> Does anybody else on this list find it disturbing that a well known
> vendor such as apache acknowledges
> a problem, and rather then fixing it blame the third party module
> coders because of their API design
> flaw?
As has been pointed out to you several times, this is not some amazing new
problem you have discovered. This is a basic constraint of existing
server-side technologies in the unix world that is very well known to
anyone with a basic knowledge of the web. If you think you're going to
get it fixed by badmouthing sincere and very knowledgable volunteer
developers, then you are mistaken.
Getting back to the issue, there are several ways to work around the
problem:
1. Do not give cgi or other server-side programming access to non-trusted
users. This is a basic principal of web-server management that is clearly
documented and very well known.
If you must violate number 1, then there are some options:
2. Use a restricted environment like mod_include's IncludesNoExec or php's
safe mode.
3. Use a suid wrapper like suexec or cgiwrap.
4. Use an out-of-process apache module like mod_fastcgi to separate
the programs from the main server.
4. Isolate the server that handles the user-supplied programs by running
multiple servers fronted by a proxy, or using the (experimental) perchild
MPM in apache 2.
5. Change apache. How you would do this is not an easy question, given
the basic constraints of the unix permission model. The most likely
solution would be a process-separated API, which could wind up looking
much like mod_fastcgi. The other solution is perchild, which is already
under development.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache permission problem: No fix planned in
near future...
Posted by Rich Bowen <rb...@rcbowen.com>.
On Wed, 6 Nov 2002, Rich Bowen wrote:
> On Wed, 6 Nov 2002, zeno wrote:
>
> > Hello,
> >
> > I noticed a permission issue in apache when dealing with modules. I recently
> > installed mod_proxy on apache 1.3.27 and setup caching of requested documents. I noticed
>
> After extensive discussion on IRC, it appears that this security concern
> can be "fixed in documentation" to zeno's satisfaction. I'll be taking
> care of that this evening.
Just for the record, here's the proposed patch, which would go into the
security tips document.
'embedded scripting options which run as part of the server itself, such
as mod_php, mod_perl, mod_tcl, and mod_python, run under the identify of
the server itself, and therefore scripts executed by these engines
potentially can access anything the server user can. some scripting
engines may provide restrictions, but it is better to be safe and assume
not.'
Note that my alternate proposed patch was:
"note that third party modules can do whatever the hell they want, and
are therefore a festering source of bugs, security holes, and general
nastiness."
Along with, perhaps:
"Third party module may be written by any self-styled programmer who
bought an "in 24 hours" book on amazon.com. Note that they may be less
competent than your pet weasel. We disclaim all responsibility for
their code."
but I was overruled by various voices of sanity.
--
Who can say where the road goes
Where the day flows
Only time
--Pilgrim (Enya - A Day Without Rain)
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache permission problem: No fix planned in near
future...
Posted by Rich Bowen <rb...@rcbowen.com>.
On Wed, 6 Nov 2002, zeno wrote:
> Hello,
>
> I noticed a permission issue in apache when dealing with modules. I recently
> installed mod_proxy on apache 1.3.27 and setup caching of requested documents. I noticed
After extensive discussion on IRC, it appears that this security concern
can be "fixed in documentation" to zeno's satisfaction. I'll be taking
care of that this evening.
--
Rich Bowen - rbowen@rcbowen.com
ReefKnot - http://www.reefknot.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org