Yes, chroot could potentially be escaped.
Although, if you chroot the main process, then you spawn child processes
under another userid, like in standard Apache config under Unix, I
expect it to be really very difficult to escape if
1. you are not root
2. if the only files available are log files and htdocs files (even no
HTML files in case of a reverse proxy
Obviously, we could imagine a vulnerability (like a buffer overrun) in
the child Apache process that would send a signal to the main process to
use a second vulnerability, but I really find that chrooting Apache
provides a very good defense.
Now, my main question is "do I add all executables, load modules,
libraries, etc. ?". I need to if I want graceful restart (and you
usually need that in a real production environment). This definitely
higher the risk, so why not trying to improve this ?
Defense in depth is a golden rule in security, no ? So, even if chroot
may not be totally bullet proof, it should, imho, be used. And, if we
want Apache to be as secure as possible, it should be as
"chroot-friendly" as possible.
I hope this could convince some key developers ...
Nick
Plüm wrote:
-----Original Message-----
From: Colm MacCarthaigh [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 24. Januar 2008 13:16
To: dev@httpd.apache.org
Subject: Re: High security
On Thu, Jan 24, 2008 at 01:10:23PM +0100, Nick Gearls wrote:
You specify one directive, and the only thing you have to
put in the
jail is your htdocs and logs directories; all other files (conf,
modules, httpd, libraries, etc.) are outside of the jail.
This is really
top security - it's almost impossible to find something to hack.
Well don't kid yourself, it makes privilege escalation by
certain routes
much harder, but it's not even clost to almost impossible. There are
many forms of IPC available between the children and the root-level
Apache process anyway, and if you manage to exploit that it's
game over
anyway (including breaking out of the jail).
Yep. chroot was never designed to be a security feature. It can make
things more difficult to leave a jailed area.
See also http://kerneltrap.org/Linux/Abusing_chroot
or have a look at
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>
int main(int argc, char *argv[])
{
FILE *file;
chroot("/tmp/zw/blah1");
chdir("/");
file = fopen("blah1", "w");
fprintf(file, "Hello\n");
fclose(file);
mkdir("foo", 493);
chroot("foo");
chdir("..");
chdir("blah2");
file = fopen("blah2", "w");
fprintf(file, "Hello\n");
fclose(file);
return 0;
}
which allows you to escape the chroot of /tmp/zw/blah1 if
you are still root at the point of time mkdir is executed
and write a file to /tmp/zw/blah2
Regards
Rüdiger
