Re: mod_perl in chroot environment
On Tue, 12 Dec 2000, Gunther Birznieks wrote:
> At 09:58 AM 12/11/00 +, Matthew Byng-Maddick wrote:
> >On Sun, 10 Dec 2000, Gunther Birznieks wrote:
> > > For example, perhaps the mod_perl server and the HTML/images server should
> > > be separately chrooted from each other? That way, someone who breaks the
> > > dynamic script won't be able to mess with the frontpage of the website to
> > > deface it assuming the hacker could get around permissions issues within
> > > the chroot jail.
> >Why do you need the proxy server to be chrooted at all? what does that
> >gain you. After all if apache is insecure, you can break out of the
> >chroot()ed jail anyway.
> If Apache is insecure it's not necessarily possible to break out of the
> chrooted jail. It depends on if the part of Apache that grabs the socket is
> insecure which is a tiny part of Apache.
Ah. I see what you're getting at. By insecure I really meant that you
could achieve root. I see that if you were trying to read files on the
system, yes, a chroot would help.
> Apache itself is large and complex and if you are talking about a front-end
> server, you are talking about having at minimum mod_proxy, mod_rewrite and
> maybe even mod_backhand. These modules are not trivial code but breaking
> them wouldn't allow someone to break out of the chroot jail with root
> privileges.
yes, you can only break out of the jail once you have achieved root.
> > > BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
> > > necessary once the chroot jail is in effect? The author creates a shadow
If you can't break up to root in the jail, then you don't need to worry
about a shadow file.
> >Well, you've lost if you break root inside a traditional chroot() (as
> >opposed to FreeBSD4's jail() -
> >1) attacker can mknod() (and can therefore attack kmem.
> >2) attacker can call chroot()
> >- int j; mkdir("./bin"); chroot("./bin");
> > for(j=0;j Doesn't this require the root ID in order to issue .. chroots? I may be
> misunderstanding this portion of your statement.
Yes, but I'm showing that in a traditional chroot, if the attacker can get
root (in order to read the /chroot-path/etc/shadow file), then you've lost
anyway, because he can break out of the jail by the trick above.
> >In which case the shadow file can be there. What isn't there is a way to
> >get root (any suid programs or similar). You hope. :)
> I agree that it's an important point to make is that any binary copied
> to the chroot jail should not be suid root as that would allow a point
> of attack.
That's why chroot() is useful. :)
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
Think Honk if you're a telepath.
Re: mod_perl in chroot environment
I've snipped some stuff out of both sides.
At 09:58 AM 12/11/00 +, Matthew Byng-Maddick wrote:
>On Sun, 10 Dec 2000, Gunther Birznieks wrote:
> > At 03:33 PM 12/10/00 +0100, Stas Bekman wrote:
>
> > For example, perhaps the mod_perl server and the HTML/images server should
> > be separately chrooted from each other? That way, someone who breaks the
> > dynamic script won't be able to mess with the frontpage of the website to
> > deface it assuming the hacker could get around permissions issues within
> > the chroot jail.
>
>Why do you need the proxy server to be chrooted at all? what does that
>gain you. After all if apache is insecure, you can break out of the
>chroot()ed jail anyway.
If Apache is insecure it's not necessarily possible to break out of the
chrooted jail. It depends on if the part of Apache that grabs the socket is
insecure which is a tiny part of Apache.
Apache itself is large and complex and if you are talking about a front-end
server, you are talking about having at minimum mod_proxy, mod_rewrite and
maybe even mod_backhand. These modules are not trivial code but breaking
them wouldn't allow someone to break out of the chroot jail with root
privileges.
> > BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
> > necessary once the chroot jail is in effect? The author creates a shadow
>
>Well, you've lost if you break root inside a traditional chroot() (as
>opposed to FreeBSD4's jail() -
>1) attacker can mknod() (and can therefore attack kmem.
>2) attacker can call chroot()
>- int j; mkdir("./bin"); chroot("./bin");
> for(j=0;jIn which case the shadow file can be there. What isn't there is a way to
>get root (any suid programs or similar). You hope. :)
I agree that it's an important point to make is that any binary copied to
the chroot jail should not be suid root as that would allow a point of attack.
Re: mod_perl in chroot environment
At 10:51 AM 12/11/00 -0500, Vivek Khera wrote: > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > >SB> Do you think I should include the scenario of making Apache run in >SB> chroot enviroment in the guide? > >That require quite a bit of stuff be crammed into the chroot jail. >You'll need an entire perl install there, wouldn't you? It might make >sense for a front-end of a two-tier setup, but the mod_perl instance >seems to me a bit big. But I guess some people will want the extra >safety of it. Personally I think it is a bit much to cram into a >chroot environment. I believe it is especially the dynamic application portion of a web server that should be chrooted from the rest of the OS. How many CGI scripts have you seen that allow /etc/passwd to be read? Or arbitrary commands to be run on the system versus buffer overflows in Apache? Even mod_perl and taintmode may not prevent this stuff (well maybe the arbitrary commands). Furthermore, I trust Apache to be more secure from buffer overflows than the Perl interpreter stuck inside Apache (same with mod_php though)... Language interpreters are large and complex beasts. It's probable that if they still have memory leaks that some of the bugs in the interpreters could result in buffer overflow too. I guess I trust the Apache group to be more diligent on security than Perl programmers developing custom apps in a highly pressured environment (eg startups, or whatnot) and that it is the Perl developers (or web app developers of any genre) which are more likely to have security bugs. I know very few web developers who have read anything on security beyond a few security advisories if they made main news... They are so busy learning Java or the latest Perl trick. I am not saying this is bad, but just realistic. Of course, I'd rather all developers get educated in security. But frankly, speaking as a developer, I find myself overwhelmed by the complexity of the custom apps that are being demanded these days in real environments, and I can only imagine that there are security bugs in those apps even with the knowledge I now have. Why? Because I'm a bad developer? Well, maybe, but it's closer to what Lincoln Stein says in the W3C Security FAQ. Paraphrased: because all programs have bugs, large and complex programs have more bugs, and there is always a probability that some of those bugs are security bugs. The more complex the program, the more likely there are security bugs. Of course, as Stas pointed out earlier, he is saying he would still have just one copy of the Perl interpreter but the hard-copy of it would be in the chroot jail, so it wouldn't take up a lot of extra space. So hopefully even space won't be an issue. Later, Gunther
Re: mod_perl in chroot environment
On Sun, 10 Dec 2000, Gunther Birznieks wrote:
> At 03:33 PM 12/10/00 +0100, Stas Bekman wrote:
> >Do you think I should include the scenario of making Apache run in chroot
> >enviroment in the guide?
> I think chroot Apache is important especially for dynamic services.
Definitely.
> For example, perhaps the mod_perl server and the HTML/images server should
> be separately chrooted from each other? That way, someone who breaks the
> dynamic script won't be able to mess with the frontpage of the website to
> deface it assuming the hacker could get around permissions issues within
> the chroot jail.
Why do you need the proxy server to be chrooted at all? what does that
gain you. After all if apache is insecure, you can break out of the
chroot()ed jail anyway.
> BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow
> necessary once the chroot jail is in effect? The author creates a shadow
Well, you've lost if you break root inside a traditional chroot() (as
opposed to FreeBSD4's jail() -
1) attacker can mknod() (and can therefore attack kmem.
2) attacker can call chroot()
- int j; mkdir("./bin"); chroot("./bin");
for(j=0;j file but it seemed odd to me. He also advocates copying it over and then
> creating a new one from scratch which seems redundant and potentially
> dangerous if the second step is forgotten.
Very much so, agreed.
MBM
--
Matthew Byng-Maddick Home: <[EMAIL PROTECTED]> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <[EMAIL PROTECTED]> +44 7956 613942 (Mobile)
philosophy, n.: Unintelligible answers to insoluble problems.
Re: mod_perl in chroot environment
> > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> Do you think I should include the scenario of making Apache run in > SB> chroot enviroment in the guide? > > That require quite a bit of stuff be crammed into the chroot jail. > You'll need an entire perl install there, wouldn't you? It might make > sense for a front-end of a two-tier setup, but the mod_perl instance > seems to me a bit big. But I guess some people will want the extra > safety of it. Personally I think it is a bit much to cram into a > chroot environment. Well, chroot wants everything to be inside, so you pretty much have no choice if you go for it. I suppose that I'll just give some incentives hints and point to these resources that hopefully will no go dead soon. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl in chroot environment
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> Do you think I should include the scenario of making Apache run in SB> chroot enviroment in the guide? That require quite a bit of stuff be crammed into the chroot jail. You'll need an entire perl install there, wouldn't you? It might make sense for a front-end of a two-tier setup, but the mod_perl instance seems to me a bit big. But I guess some people will want the extra safety of it. Personally I think it is a bit much to cram into a chroot environment. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: mod_perl in chroot environment
> The key to successful chroot'ing, I've found, is running strace or trace > (depending on your platform) and looking at what files your httpd is > looking for, importing them into the chroot environment and doing that > iteratively until you're httpd is running and answering requests fully w/o > errors. It's a PITA the first time but simple enough to later turn into a > tarball and/or a shell script for later re-use. Doesn't sound like a working solution at all for Perl modules :( You cannot exhaustively test all of your code fast, you will miss something. So copying /lib/perl5 sounds like a more feasible solution when you don't have loads of time on your hands. Of course if you are talking about other libraries and conf files than directly Perl-related onces, you have a good advise here :) at least you should run: strace -e trace=open ... to skip hunderds of irrelevant traced syscalls... Thanks, Ian! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl in chroot environment
Tomorrow, Gunther Birznieks <[EMAIL PROTECTED]> frothed and gesticulated...: > > > >http://www.securityfocus.com/focus/sun/articles/apache-inst.html Yup, that's good. > http://penguin.epfl.ch/chroot.html Yup, that's good too. The key to successful chroot'ing, I've found, is running strace or trace (depending on your platform) and looking at what files your httpd is looking for, importing them into the chroot environment and doing that iteratively until you're httpd is running and answering requests fully w/o errors. It's a PITA the first time but simple enough to later turn into a tarball and/or a shell script for later re-use. Has anyone on the list run hosted mod_perl installations? I'm curious about ISP's how they provision their users with mod_perl environments safely. -Ian -- Salon Internet http://www.salon.com/ Manager, Software and Systems "Livin' La Vida Unix!" Ian Kallen <[EMAIL PROTECTED]> / AIM: iankallen / Fax: (415) 354-3326
Re: mod_perl in chroot environment
At 05:21 PM 12/10/00 +0100, Stas Bekman wrote: > > At 03:33 PM 12/10/00 +0100, Stas Bekman wrote: > > >Do you think I should include the scenario of making Apache run in chroot > > >enviroment in the guide? > > > > I think chroot Apache is important especially for dynamic services. > > > > >Check out the last section of this article: > > >Installing and Securing the Apache Webserver with SSL > > > by Dale Coddington <[EMAIL PROTECTED]> > > >http://www.securityfocus.com/focus/sun/articles/apache-inst.html > > > > > >Of course it's incomplete as it doesn't take into account all the stuff > > >located under /lib/perl, but it's a good start. > > I am not sure if this part is so hard. Why can't you copy the the > /lib/perl > > to the chroot area and repeat the process everytime you install a CPAN > module? > >Because I'd do all the installation into the chroot area in first place. >Why keeping track of what should be copied (other than main /lib/lib* >stuff) when you can install everything into /chroot and maintain it as a >master (assuming that you have only one mod_perl server). I suppose you could test an installation of a module on the main Perl and if it works, then copy /lib/perl to the web server chroot jail itself. > > If this is not that hard, then you may just want to reference the chroot > > docs that exist out there. Of course, I could be mistaken about how hard > > this is. > >It proved not to work. I've referenced to a few resources on the web and >now they all gone dead and I cannot find the new links. So I've these >tails in the guide where I show results but no sources :( Therefore from >now on, unless it's something really big and it's known that the info is >there to stay, I'm integrating the info as is and providing the link to >the source as long as it's alive. OK, here's another source you might like. To give credit for notification, Lyndon Drake sent this one to me last week. http://penguin.epfl.ch/chroot.html > > For example, perhaps the mod_perl server and the HTML/images server should > > be separately chrooted from each other? That way, someone who breaks the > > dynamic script won't be able to mess with the frontpage of the website to > > deface it assuming the hacker could get around permissions issues within > > the chroot jail. > >If you have no scripting mods in front end, why would you want to put it >into chroot at all? Because it's possible a module you use on the front-end could also be exploited. For example, if you use mod_rewrite and mod_proxy. If one of those turns up to have a buffer overflow problem or the like, then someone could break into your front-end server and you wouldn't want the hacker to run around the rest of your OS. > > BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow > > necessary once the chroot jail is in effect? The author creates a shadow > > file but it seemed odd to me. He also advocates copying it over and then > > creating a new one from scratch which seems redundant and potentially > > dangerous if the second step is forgotten. > >If you don't have the password for httpd user (and you shouldn't have >one), you probably don't need it at all. I suppose that this scenario was >copied from the ftp chroot env setup, where it's needed. I think you need >/chroot/etc/passwd only to get the uid in place. But then you should be >careful since the main /etc/passwd doesn't know about this secondary >/chroot/etc/passwd and may give some user the same uid/gid, which is bad. >I doubt that one need /chroot/etc/passwd and /chroot/etc/group at all. I think passwd and group get read quite often on-the-fly for permissions. So I think you would almost always need those no matter what. Again, I could be wrong on that. I haven't tried it without these files. Later, Gunther
Re: mod_perl in chroot environment
> At 03:33 PM 12/10/00 +0100, Stas Bekman wrote: > >Do you think I should include the scenario of making Apache run in chroot > >enviroment in the guide? > > I think chroot Apache is important especially for dynamic services. > > >Check out the last section of this article: > >Installing and Securing the Apache Webserver with SSL > > by Dale Coddington <[EMAIL PROTECTED]> > >http://www.securityfocus.com/focus/sun/articles/apache-inst.html > > > >Of course it's incomplete as it doesn't take into account all the stuff > >located under /lib/perl, but it's a good start. > I am not sure if this part is so hard. Why can't you copy the the /lib/perl > to the chroot area and repeat the process everytime you install a CPAN module? Because I'd do all the installation into the chroot area in first place. Why keeping track of what should be copied (other than main /lib/lib* stuff) when you can install everything into /chroot and maintain it as a master (assuming that you have only one mod_perl server). > If this is not that hard, then you may just want to reference the chroot > docs that exist out there. Of course, I could be mistaken about how hard > this is. It proved not to work. I've referenced to a few resources on the web and now they all gone dead and I cannot find the new links. So I've these tails in the guide where I show results but no sources :( Therefore from now on, unless it's something really big and it's known that the info is there to stay, I'm integrating the info as is and providing the link to the source as long as it's alive. > For example, perhaps the mod_perl server and the HTML/images server should > be separately chrooted from each other? That way, someone who breaks the > dynamic script won't be able to mess with the frontpage of the website to > deface it assuming the hacker could get around permissions issues within > the chroot jail. If you have no scripting mods in front end, why would you want to put it into chroot at all? > BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow > necessary once the chroot jail is in effect? The author creates a shadow > file but it seemed odd to me. He also advocates copying it over and then > creating a new one from scratch which seems redundant and potentially > dangerous if the second step is forgotten. If you don't have the password for httpd user (and you shouldn't have one), you probably don't need it at all. I suppose that this scenario was copied from the ftp chroot env setup, where it's needed. I think you need /chroot/etc/passwd only to get the uid in place. But then you should be careful since the main /etc/passwd doesn't know about this secondary /chroot/etc/passwd and may give some user the same uid/gid, which is bad. I doubt that one need /chroot/etc/passwd and /chroot/etc/group at all. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl in chroot environment
At 03:33 PM 12/10/00 +0100, Stas Bekman wrote: >Do you think I should include the scenario of making Apache run in chroot >enviroment in the guide? I think chroot Apache is important especially for dynamic services. >Check out the last section of this article: >Installing and Securing the Apache Webserver with SSL > by Dale Coddington <[EMAIL PROTECTED]> >http://www.securityfocus.com/focus/sun/articles/apache-inst.html > >Of course it's incomplete as it doesn't take into account all the stuff >located under /lib/perl, but it's a good start. I am not sure if this part is so hard. Why can't you copy the the /lib/perl to the chroot area and repeat the process everytime you install a CPAN module? If this is not that hard, then you may just want to reference the chroot docs that exist out there. Of course, I could be mistaken about how hard this is. For example, perhaps the mod_perl server and the HTML/images server should be separately chrooted from each other? That way, someone who breaks the dynamic script won't be able to mess with the frontpage of the website to deface it assuming the hacker could get around permissions issues within the chroot jail. BTW, OT Question on the subject -- does anyone know if /chroot/etc/shadow necessary once the chroot jail is in effect? The author creates a shadow file but it seemed odd to me. He also advocates copying it over and then creating a new one from scratch which seems redundant and potentially dangerous if the second step is forgotten. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_perl in chroot environment
Do you think I should include the scenario of making Apache run in chroot enviroment in the guide? Check out the last section of this article: Installing and Securing the Apache Webserver with SSL by Dale Coddington <[EMAIL PROTECTED]> http://www.securityfocus.com/focus/sun/articles/apache-inst.html Of course it's incomplete as it doesn't take into account all the stuff located under /lib/perl, but it's a good start. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
