Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!dual!ptsfa!qantel!ihnp4!ihlpl!marcus
From: marcus@ihlpl.UUCP (Hall)
Newsgroups: net.unix-wizards
Subject: Re: chroot(2) security
Message-ID: <1356@ihlpl.UUCP>
Date: Sat, 4-Oct-86 15:07:03 EDT
Article-I.D.: ihlpl.1356
Posted: Sat Oct  4 15:07:03 1986
Date-Received: Tue, 7-Oct-86 19:14:46 EDT
References: <158@itcatl.UUCP> <113@nonvon.UUCP>
Reply-To: marcus@ihlpl.UUCP (Marcus Hall)
Organization: AT&T Information Systems, Indian Hill West, Illinois
Lines: 30

In article <113@nonvon.UUCP>, apn@nonvon.UUCP (apn) writes:

> 	write a program that changes the root directory to /mnt23/user/test
> 	and then procedes to exec /bin/login

Which would really execute /mnt23/user/test/bin/login.  So what?

What you have to do is to find some writable directory in the same filesystem
as /bin.  If you find such a filesystem, it would be possible to create a
subdirectory, say /writable/dir/etc which contains a fake passwd file that
has a known password for root.  Then, create a hard link from /bin/login
to /writable/dir/login, chroot to /writable/dir, and execute /login which
is really /writable/dir/login, which is linked to /bin/login.  This would
let you log in as root, create a SUID shell in /writeable/dir/... .  Next,
get back to where you started (before the chroot), execute the SUID shell,
and there you go!

The best security in this case would to be sure that there are no writable
directories in the root filesystem, or for /bin/login to make sure that it
is SUID root and has only 1 link (I'm not sure if this could be gotten
around or not).

At any rate, programs on /usr (usually /usr/bin, /usr/local, etc.) have
problems because /usr/tmp and somewhere in /usr/spool is usually writable.

In BSD systems, where SUID shells work, explicitly specified paths for
commands would become questionable, which would present a real hazard.

Marcus Hall
..!ihnp4!ihlpl!marcus