nickgearls at gmail
Jan 24, 2008, 7:55 AM
Post #4 of 23
(521 views)
Permalink
|
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:colm[at]allcosts.net]
>> Sent: Donnerstag, 24. Januar 2008 13:16
>> To: dev[at]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
>
|
smime.p7s
