iaw4 has asked for the wisdom of the Perl Monks concerning the following question:

Dear Perlmonks:

My linux apache web server was recently hacked, so I have become more security conscious. Amazing what a little hack will do to one...

I was thinking that it would be a good idea to jail each perl cgi program that I am running to the file system hierarchy that it needs to read/write into. my perl cgi program would first load all the necessary external modules, then do a 

chroot("/var/www/user1/"); chdir("/");

[download]
Even if my perl script later does something truly stupid and a web user can gain control of my perl cgi program, the damage will be limited to stuff in /var/www/user1/. Because apache runs cgi and fcgi program not as root, breaking out of such a jail will be difficult.

alas, this has the obvious issue that the chroot() call itself requires super user privileges. I am a little confused by this--why is this security restriction there to begin with? before the chroot, I already have access to everything that I have access to after the chroot. I am whittling down what I can do, not expanding it.

can I make a non-setuid program capable of executing the chroot() call? I also tried 

system("/usr/sbin/chroot","/var/www/user1")

[download]
does not work even if I setuid /usr/sbin/chroot, because the system call wants access to "/bin/bash". I am not sure why---I thought this version would exec the chroot directly.

I would think it would be a bad idea to change my perl cgi scripts themselves to be setuid root, so that I can chroot from inside perl. I know I can drop the setuid privileges later, but the whole idea is to protect myself from stupidity afterwards. giving my cgi programs root privileges is something I would rather avoid.

advice appreciated.

/iaw

Replies are listed 'Best First'.
Re: chroot() security in cgi script?
by JavaFan (Canon) on Jan 03, 2012 at 22:52 UTC
    Making /usr/sbin/chroot suid is a potential security hole in itself. The BSD manual page explicitly warns against that (perhaps the GNU page as well, but I did not check).

    And super user privs are required because that's the underlaying requirement of the chroot(2) call.

    As for the system command wanting access to /bin/bash, that's documented behaviour. What do you expect /usr/sbin/chroot /var/www/user1 does? A process that would only change directory, and not actually execute something isn't very useful. So, if you don't give chroot a command to execute, it defaults to starting an interactive shell.

[reply]
Re: chroot() security in cgi script?
by Anonymous Monk on Jan 04, 2012 at 00:18 UTC

    Securing and Optimizing Linux: RedHat Edition -A Hands on Guide

    Chapter 29. Software -Network Server, web/Apache

    Apache in a chroot jail

    http://www.faqs.org/docs/securing/chap29sec254.html

[reply]
      I know. Running a full chroot apache is too painful, though. I think what I want is impossible. I want to start my script, then load a couple of perl modules and libraries, grab everything that I need from the real filesystem, then drop as many privileges as I can, and only then start interacting with my user or processing whatever he has given me in the query string. This should make it much harder for a user to create mischief. It would seem like a smart security idea, somewhere in between a full apache chroot (with its double maintenance requirements), and the no drop of privileges whatsoever. I know it wont help against many other vulnerabilities, of course.

      It does not really matter how the last hack happened, although I am sure that someone reading this here knows exactly how it happened. (Happened after my first question on security here on perlmonks. Ironically, it was indeed not related to perl, but to a stupid error elsewhere.) It is more important for me to take precautions against my next coding error. Sony has proven that it can happen to anyone.

      I still do not understand why chroot is not a permissible privilege reducing operation (which therefore should not require privileges). But it does not really matter if linux does not allow me to. It is not really a perl question in this case, anyway.

      Yes, system("chroot") could not work, because it does not apply to the current process. Oh well...

      Iaw

[reply]
Re: chroot() security in cgi script?
by TJPride (Pilgrim) on Jan 03, 2012 at 20:58 UTC
    How did your Perl program manage to "hack" the server, exactly? Were you trusting input and then inserting it into paths or queries or whatnot without first running it through a converter? Sounds more like you need to practice untainting. But you could theoretically use a wrapper, like one of the ones mentioned here:
    http://www.w3.org/Security/faq/wwwsf4.html (bit more than halfway down the page)
[reply]
      How did your Perl program manage to "hack" the server, exactly?

      Where does iaw4 say Perl is even related to the hack job, except in speculation after the fact?

      Q:   The sky is blue. I thought maybe I should change my socks
      A:   How,, exactly, did changing your socks manage to change the sky color?

[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.
Re: chroot() security in cgi script?
by Anonymous Monk on Jan 04, 2012 at 13:21 UTC
    How do you know that the penetration happened through the web server/page? It probably didn't ...
[reply]

Back to Seekers of Perl Wisdom