Re: OT? Are chroots immune to buffer overflows?

["Kurt Seifried" <bugtraq () seifried org>]

As far as I am concerned, and most other security professionals I know,
chroot is a convenience function, not a security function. Several problem
exist with chroot:

It does nothing to prevent heap/stack/buffer overflows, format string
attacks, etc. Once I can execute code, I can upload more code.
It is a real pain in some cases to set up, copying all the neccesary
libraries and files into a chroot can be really annoying.
It is relatively easy to break out of for an attacker.

What can be done to improve the effectiveness of chroots:

either create a sepepate partition, or mount a file as a loopback interface,
this will allow you to use options such as "nosuid" and "nodev" and to mount
the partition read only if possible (this doesn't work for all services of
course, some like Bind running secondary zones must be able to write to the
filesystem). This also makes distribution of the chroot'ed daemons easier (a
single file you copy to the filesystem, and a single line for /etc/fstab).

make sure whatever is in the chroot runs as a non root user, and that there
aren't any setuid/setgid binaries/etc in the chroot. This may also not be
possible, but should be strongly strived for.

use better security mechanisms, on FreeBSD there is jail, on Linux there are
technologies like WireX's SubDomain, Argus Pitbull LX, and so on.

use secure daemons that don't get broken into in the first place where
possible.

use proxies or intermediaries when you have something like a custom closed
source application that may contain security flaws.

monitor what programs are doing, periodically run a find/md5sum/tripwire of
all the files/etc in the chroot to make sure nothing untoward has happened
or been attempted.

Kurt Seifried, kurt () seifried org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/
http://www.iDefense.com/