[lug] preventing malicious scripts

[D. Stimits]

Gus Huber wrote:
> 
> It should be noted that if you use chroot, if the person can obtain the
> root userid or the script is executed as root, it is trivial to break
> out of the chroot environment.  Take a peek at
> http://www.google.com/search?q=cache:o-wwoSfD6Q0:www.bpfh.net/simes/comp
> uting/chroot-break.html+Break+out+of+chroot&hl=en  that was the best
> copy I could find.. But it is fairly well known information.

It's an interesting/informative article. It actually was intended for
cgi. I'm not surprised that root has a way out of chroot, but one of the
first things is that the attacker has to know it is chroot, and be more
than a script kiddie (or at least it seems no particular attacks combine
a chroot breakout with other flaws, so the attacker would have to
understand the possibility of chroot jails). FYI, the above link is long
because it credits google as a referrer. Here is the shorter web link:
http://www.bpfh.net/simes/computing/chroot-break.html

One of the good-side notes from the article mentions that several root
exploits require access to suid root programs, and the chroot
effectively removes that access. So even though root can do nasty
things, it becomes harder to gain root. Plus there are all kinds of
files that are just no longer available until chroot is broken...a
chicken-and-egg thing for the attacker. chroot isn't perfect, but it is
a strong aid.

D. Stimits, stimits at idcomm.com

> 
>         cheers,
>                         gus huber <gus at pbx.org>
> 
> -----Original Message-----
> From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]
> On Behalf Of D. Stimits
> Sent: Thursday, September 06, 2001 9:29 PM
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] preventing malicious scripts
> 
> charles at lunarmedia.net wrote:
> >
> > is there a method to set a directory as a able to execute cgi scripts,
> 
> > however limit which scripts within the directory are executable?
> >
> > i thought about the possibility of limiting it based on name, however
> > i would assume the crafty client would simply upload a malicious
> > script with the name of the accepted script and still be able to
> > gather the info i am trying to prevent them from retrieving.
> >
> > any ideas on how to let clients have access but still be able to sleep
> 
> > at night?
> >
> > thanks -charles
> >
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> You can create a chroot environment. What chroot does is that the
> particular application sees the chroot point as the new root directory,
> and nothing to its parent is visible. But that also means any support
> needed to run must be duplicated in the chroot environment. Even if that
> entire environment is destroyed, nothing outside can be seen. For
> example, if I have a statically linked executable, with no outside
> requirements except maybe /lib, /bin, and parts of /usr/bin, you could
> do this: create /usr/local/sandbox create /usr/local/sandbox/bin (give
> it a copy of /bin) create /usr/local/sandbox/usr/bin (give it a copy of
> /usr/bin, selectively copying only what is needed)
> 
> Then in your application, have it chroot /usr/local/sandbox Your
> application can no longer see anything that is a parent to
> /usr/local/sandbox, and in fact thinks /usr/local/sandbox is actually
> "/". If you fail to provide any resource needed for the application to
> run, it will fail. I haven't tried this for cgi, but you could
> conceivably put your entire web system in chroot so it is independent of
> the rest of the system. Once it goes chroot, it won't come back till you
> reboot.
> 
> The only time I've actually used chroot is that I have booted from a
> rescue CD, then did a chroot to the root partition of the real install,
> which was mounted somewhere like /mnt/rescue, and I'd run chroot
> /mnt/rescue. I'm then running from the rescue kernel, but everything
> will now be in relation to my regular hard drive install instead of the
> CD. Running lilo will do the proper thing at that point, and instead of
> looking for /etc/lilo.conf from the CD, it'll see
> /mnt/rescue/etc/lilo.conf. You could conceivably run from a rescue
> floppy and chroot, then have your full install available. From a
> security standpoint, you can do the reverse, and take a full install,
> and cause a shell or other program chroot to a smaller, contained
> environment. Check out "man -a chroot", it'll give both the command line
> version, and the C API call to do it. If you want to get an estimate of
> what is required to run a particular program, use ldd and search out the
> libraries it wants. If you run something like a bash script or a perl
> script, then you have to instead find out what bash or perl want, ldd
> won't work on a script.
> 
> D. Stimits, stimits at idcomm.com
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug