Re: High security
hi all, sorry to enter so later in the discution... i'm ok with you torsten (+1), i think is the good place to do it, think adding hook like pre_childinit that occure before unixd_setup_child remove the root rigth (in child_init you lost the root right juste before) can be more generic way. and after use this hook to do implemente the chroot option as loadable module. and i think can be usefull for other module to have chance to use root right juste before is removed in child_init... existe other implementation of chroot in apache and i think many interesting hints to use chroot in apache are in the page of mod_chroot: http://core.segfault.pl/~hobbit/mod_chroot/caveats.html i think is interesting to add some of this in the documentation also... and loadfile of libgcc_s.so.1 is only needed in threaded mpm version. because the thread lib use some symbole of libgcc_s.so.1 that are autoloaded in child when create thread after unixd_setup_child occure... i've made modified version (at 02/08) of mod_chroot that work like your modification (chrooting juste before seting up setuid in the child) but without modifying apache code and working with ap 2.0 and 2.2... it work like that, i save the unixd_config.user_id in pre_mpm hook, and force it to 0 (root), in that way in child_init root your are root (unixd_setup_child skip changing user_id)! like i can do the chroot in child_init hook, and restore unixd_config.user_id and redo unixd_setup_child to remove root right. i think an other modification must be done to be complete... is to modify the way DocumentRoot global context cmd check if the path is directory or not, will be very good, to check document root path in chroot directory relative in place of server_root if chroot option is activated. without that modification you must have DocumentRoot in the chroot path and outside the chroot path like that : if chroot dir is /var/chroot and globale document root to /var/chroot/www in httpd.conf your globale document root point to /var/chroot/www/var/chroot/www. with that modification you can set globale document root in the jail path without problem... a work around exist... using documentroot in virtualhost... in vhost you can use path in the jail without problem because documentroot cmd in the jail are executed when vhost are checked... far later from the point the chroot occure (juste before unixd_setup_child)... in that way can be possible to set globale DocumentRoot to same dir of chroot, and use only vhost to specify Document root directory... but is not completely transparent because you must set a fake globale document root that exist ouside the jail and you are obliged to use vhost... in my mod_chroot modification in correcte all path transparantly on the fly (in translate hook, and map_to_storage hook) to work around this (to do it without modification in apache code!)...but is more havy modification... and more risky... Regards, Mathieu *From:* Torsten Foertsch *Sent:* Sat, 26 Jan 2008 08:44:17 +0100 On Fri 25 Jan 2008, Nick Kew wrote: A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) Sometimes I have missed a ChildPrivilegedInit hook that is run between fork() and dropping privileges in the worker. That would be the right place to chroot() I think. Torsten
Re: High security
If there's a chance to add it, I'm ready to write the doc patch Nick Dirk-Willem van Gulik wrote: On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding LoadFile libgcc_s.so.1 in httpd.conf, I don't have any more file in the chroot (except htdocs if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=revrevision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...]
Re: High security
On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch Lets get that in there - and then lets (or I'll) backport it - so it goes into the next release. Dirk-Willem van Gulik wrote: On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding LoadFile libgcc_s.so.1 in httpd.conf, I don't have any more file in the chroot (except htdocs if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=revrevision=611483 ). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...] Dw.
Re: High security
-Ursprüngliche Nachricht- Von: Dirk-Willem van Gulik Gesendet: Dienstag, 6. Mai 2008 16:20 An: dev@httpd.apache.org Betreff: Re: High security On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch Lets get that in there - and then lets (or I'll) backport it - so it goes into the next release. There is already a backport proposal in the STATUS file: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?revision=653778view=markup Regards Rüdiger
re: High security
-Ursprüngliche Nachricht- Von: Dirk-Willem van Gulik Gesendet: Dienstag, 6. Mai 2008 17:00 An: dev@httpd.apache.org Betreff: Re: High security On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch I did below a while ago. May be useful as a start. There is already a documentation in trunk for this: http://svn.apache.org/viewvc?view=revrevision=639005 Regards Rüdiger
Re: High security
On May 6, 2008, at 5:03 PM, Plüm, Rüdiger, VF-Group wrote: -Ursprüngliche Nachricht- Von: Dirk-Willem van Gulik Gesendet: Dienstag, 6. Mai 2008 17:00 An: dev@httpd.apache.org Betreff: Re: High security On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch I did below a while ago. May be useful as a start. There is already a documentation in trunk for this: http://svn.apache.org/viewvc?view=revrevision=639005 Aye - I edited on top of that version. Dw.
Re: High security
Can you tell me where to find the XML doc file ? It's not obvious from the site :-( Thanks, Nick Dirk-Willem van Gulik wrote: On May 6, 2008, at 4:12 PM, Nick Gearls wrote: If there's a chance to add it, I'm ready to write the doc patch Lets get that in there - and then lets (or I'll) backport it - so it goes into the next release. Dirk-Willem van Gulik wrote: On May 6, 2008, at 3:27 PM, Nick Gearls wrote: Just a little adding: by adding LoadFile libgcc_s.so.1 in httpd.conf, I don't have any more file in the chroot (except htdocs if not in pure proxy mode). Is there a patch for the docs as well ? Including above trick ? Nick Gearls wrote: I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=revrevision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...] Dw.
Re: High security
On May 6, 2008, at 8:10 AM, Nick Gearls wrote: Can you tell me where to find the XML doc file ? It's not obvious from the site :-( Check out the httpd trunk: svn co http://svn.apache.org/repos/asf/httpd/httpd/trunk httpd and the XML file we're talking about will be httpd/docs/manual/mod/mpm_common.xml S. -- Sander Temme [EMAIL PROTECTED] PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: High security
I'm running the patch for one week on a production server, and it works perfectly (http://svn.apache.org/viewvc?view=revrevision=611483). When using Apache as a reverse proxy, the chroot environment is totally empty (except libgcc_s.so.1). Could we include this in next build ? As it is very limited (basically 3 basic function calls plus the logging), it is trivial to review. +1 Regards, Nick [... discussion about chroot effectiveness and letting the final choice to the user to use it or not ...]
Re: High security
On Jan 25, 2008 1:30 PM, Nick Kew [EMAIL PROTECTED] wrote: ... A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) In ModSecurity I had to use one of the available hooks to execute the chroot call. As Torsten mentions, that might be a much better place to do it. Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. Can we expect your contributions to the apache core code in the not-too-distant? Possibly... Maybe I should aim to start with something simpler; for example, by proposing the suexec chroot patch I have lying around somewhere. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/ -- Ivan Ristic
Re: High security
I don't think this should be a discussion of whether chroot is worth using as a security measure. IMHO it should be about allowing Apache users to make a choice whether they will use chroot in this way or not. I am usually an advocate for user choice. For example, I am well aware of the various disadvantages of chroot but I still find some cases where it is useful. In particular, it is very good in preventing (or limiting damage from) automated attacks. It is also very good in significantly raising the effort required to compromise a server after a successful compromise of the web server installation running on it (e.g. through a badly written web application). For the record, I have regretted including the chroot feature in ModSecurity many times over. Not because of the feature itself (which -- I still think -- is very useful when the circumstances are right) but because of the support I was required to provide on the mailing list over the years. To troubleshoot chroot issues requires a very good understanding of how things work and takes a lot of time. Subtle problems may arise with modules that are not expecting to be cut-off from the filesystem half-way through, or with modules that fork at startup. With this in mind, I have always felt the reluctance of the Apache developers to include support for chroot has more to do with these support issues rather than with any technical reasons. A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. On Jan 24, 2008 8:33 PM, Ruediger Pluem [EMAIL PROTECTED] wrote: On 01/24/2008 04:55 PM, Nick Gearls wrote: 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. It is some kind of defense, but as stated chroot is not really a security tool (see also http://it.slashdot.org/article.pl?sid=07/09/27/2256235). Nevertheless, back to your problem. I think there is no gain at all doing a chroot in the httpd main process which keeps running as root. So IMHO mod_security is doing the chroot too early by doing it in the post config hook. I admit that I do not see any other hook at the moment to do this. But there is a patch in trunk that does chroot only for the child processes, just before the userid is switched. I haven't tested this so far, but this should work with graceful restarts. Plus: You do not need to keep your logs in the chroot jail as the logfiles are opened by the main process. Patch: http://svn.apache.org/viewvc?view=revrevision=611483 PR: http://issues.apache.org/bugzilla/show_bug.cgi?id=43596 Regards Rüdiger -- Ivan Ristic
Re: High security
On Fri 25 Jan 2008, Nick Kew wrote: A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) Sometimes I have missed a ChildPrivilegedInit hook that is run between fork() and dropping privileges in the worker. That would be the right place to chroot() I think. Torsten
Re: High security
On Fri, 25 Jan 2008 11:31:32 + Ivan Ristic [EMAIL PROTECTED] wrote: I don't think this should be a discussion of whether chroot is worth using as a security measure. IMHO it should be about allowing Apache users to make a choice whether they will use chroot in this way or not. +1. For the record, I have regretted including the chroot feature in ModSecurity many times over. Not because of the feature itself (which -- I still think -- is very useful when the circumstances are right) but because of the support I was required to provide on the mailing list over the years. To troubleshoot chroot issues requires a very good understanding of how things work and takes a lot of time. Subtle problems may arise with modules that are not expecting to be cut-off from the filesystem half-way through, or with modules that fork at startup. Thanks for the insight! Chroot problems are indeed a support issue (though still a fairly infrequent one) in apache's own support fora. I guess you've relieved us of some part (maybe most) of that burden. With this in mind, I have always felt the reluctance of the Apache developers to include support for chroot has more to do with these support issues rather than with any technical reasons. Still more likely: lack of round tuits. Builtin support could still happen. In fact I recently committed a patch to /trunk/. A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) Personally, I don't really have a need for the internal chroot feature ever since I discovered the makejail utility (part of Debian, and maybe other systems), which worked really well for me. On the other hand, I am interested in getting Apache to drop certain capabilities (where supported) at startup. I plan to look into it eventually. Can we expect your contributions to the apache core code in the not-too-distant? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
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). Unfortunately, the only thing that does not work is a graceful restart, as the process has no more access to all normal files. Couldn't it be possible to separate the main process in 2 - one real master performing the start/stop/restart, and one almost main chrooted process which would spawn the listening children processes ? The chrooted process could be implemented in the core, or it could be left to ModSecurity. It'd be a new MPM. That would be the top security, much more secure than any solution based on IIS for instance. Do you think this could be envisioned ? Can't see it happening personally. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
RE: High security
-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
Re: High security
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
Re: High security
On 01/24/2008 04:55 PM, Nick Gearls wrote: 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. It is some kind of defense, but as stated chroot is not really a security tool (see also http://it.slashdot.org/article.pl?sid=07/09/27/2256235). Nevertheless, back to your problem. I think there is no gain at all doing a chroot in the httpd main process which keeps running as root. So IMHO mod_security is doing the chroot too early by doing it in the post config hook. I admit that I do not see any other hook at the moment to do this. But there is a patch in trunk that does chroot only for the child processes, just before the userid is switched. I haven't tested this so far, but this should work with graceful restarts. Plus: You do not need to keep your logs in the chroot jail as the logfiles are opened by the main process. Patch: http://svn.apache.org/viewvc?view=revrevision=611483 PR: http://issues.apache.org/bugzilla/show_bug.cgi?id=43596 Regards Rüdiger
