-----Original Message----- From: Philippe Vogel [mailto:filiaap@freenet.de] Sent: Wednesday, 16 February 2005 9:49 a.m. To: suse-security@suse.com Subject: Re: [suse-security] Security enhancements with Chrooted Apache?

Mike Tierney schrieb:

| Yes people can escape from Chroots. There is no extra protextion in | the SuSE Kernel yet. And trying to apply any 3rd party patches can | be a real pain (at least for the 2.4 kernel) owing to the extensive | backports of stuff into it. | Is there any proof of concetp or any article on the net, even if you disable /proc access in chroot-apache? What about the use of capabilities in that context (and grsecurity-patches)?

Disabling /proc wont stop the chroot being escaped, though it might rule out certain methods. I used the power of Google to find an example of how you can break out of a Chroot using a double "chdir". They may well be other pages out there detailing other methods. Or maybe there is only the "chdir" method. /shrug http://www.bpfh.net/simes/computing/chroot-break.html Note that you need to have root access. So AFAIK, to escape a Chrooted Apache you would need to: 1) Crack of exploit Apache to get a local shell 2) Execute a local kernel exploit to escalate yourself to Root 3) Execute a chroot escape exploit Now that should stop most people. I'd hope it would stop 99.9% of script kiddies/bored teenagers. However a highly skilled and determined attacker could do it. So yes running Apache Chrooted improves on your security enormously, but it's not crack-proof. But then maybe nothing is! I believe the Grsecurity patches tighten up Chroot to stop the double-chroot escape mechanism from working (among many other useful things). The linux-vserver patches also do a similar thing + more.

From that article, if you can 1) change your directory to a place where you can create a new directory and 2) make a new directory there and 3) you are root, then you can "possibly" break out. They don't need to be able to actually run anything in those directories, just make a directory and then reference it.

So if someone can change directory into your writable /tmp or /var, they can possibly do it. At least that is my understanding of it. Note that they still need to have used an apache exploit to get a shell, then used another exploit to get root user before they attempt to escape the Chroot. That's a hopefully quite a lot of work in the first place! Using a read-only file systems is quite a nice idea though. At least it would stop people defacing your websites. Well if they do, it's nothing a reboot won't fix! I've been meaning to cut a self-booting ISO for our firewall and applications servers! Of course updates become a little trickier! :) Having a completely read-only filesystem (except for /tmp and /var) should make you root-kit proof. Well I'd hope so! Of course if people can get in at will somehow then they don't need a root-kit. Patch and pray!!!!

-----Original Message----- From: Kai Pfeiffer [mailto:pfeiffer.kai@gmx.net] Sent: Thursday, 17 February 2005 10:52 a.m. To: suse-security@suse.com Subject: Re: [suse-security] Security enhancements with Chrooted Apache?

...

Disabling /proc wont stop the chroot being escaped, though it might rule out certain methods. I used the power of Google to find an example of how you can break out of a Chroot using a double "chdir". They may well be other pages out there detailing other methods. Or maybe there is only the "chdir" method. /shrug

http://www.bpfh.net/simes/computing/chroot-break.html

I read this example, but I think it couldn't work in my case. The hole chroot-jail is an isoimage where no further files or directories could be created. The only wrtitable directories like "tmp" and "var" ar mounted "noexec" and the are no executables in the Chroot-jail to remount partitions or chroot to another directory.

Am I right or did I miss something?

cu Kai

-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here