From owner-freebsd-security  Sun Feb 23 05:55:08 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA10624
          for security-outgoing; Sun, 23 Feb 1997 05:55:08 -0800 (PST)
Received: from nic.follonett.no (nic.follonett.no [194.198.43.10])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA10619;
          Sun, 23 Feb 1997 05:55:05 -0800 (PST)
Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id OAA02292; Sun, 23 Feb 1997 14:53:00 +0100 (MET)
Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.8.5/8.7.2) with SMTP id OAA11550; Sun, 23 Feb 1997 14:49:02 +0100 (MET)
Message-Id: <3.0.32.19970223144902.00c19100@dimaga.com>
X-Sender: eivind@dimaga.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 23 Feb 1997 14:49:03 +0100
To: Julian Assange <proff@iq.org>
From: Eivind Eklund <eivind@dimaga.com>
Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of
  chroot enviroments
Cc: peter@spinner.DIALix.COM (Peter Wemm), hackers@freebsd.org,
        security@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

At 07:10 PM 2/23/97 +1100, Julian Assange wrote:
>> What's to stop a user from setting LD_CHROOT to a "hostile" invironment,
>> running a setuid program (which ignores LD_CHROOT), which happens to set
>> it's uid's to the new id, and that process exec's some binary with uid ==
>> euid now, so that new binary now takes note of LD_CHROOT and is now
>> vulnerable to the "hostile" chroot environment...
>
>Same argument applies to all the LD_* variables. This technique was used
>to undermine the sync:: account under sunos with login -p etc

Not quite.  If we allow users to do this to setuid binaries, they can make
setuid programs read dangerous config files, and exploit the new behaviour.
 A really simple example would be to create a fake /etc with a new
master.passwd and run su.  Sure, you have su only in the chroot()ed
environment, but you could easily create a new suid binary...

There is a reason chroot() is restricted to root, and I think we'd better
keep that.  If the patch was changed to restrict use to non-suid only (ie,
root only), I'd be much more comfortable with it.



Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org