From owner-freebsd-bugs  Tue Jul  9 02:40:07 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA23563
          for bugs-outgoing; Tue, 9 Jul 1996 02:40:07 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA23518;
          Tue, 9 Jul 1996 02:40:03 -0700 (PDT)
Resent-Date: Tue, 9 Jul 1996 02:40:03 -0700 (PDT)
Resent-Message-Id: <199607090940.CAA23518@freefall.freebsd.org>
Resent-From: gnats (GNATS Management)
Resent-To: freebsd-bugs
Resent-Reply-To: FreeBSD-gnats@freefall.FreeBSD.org,
        zach@blizzard.gaffaneys.com
Received: from freebsd.gaffaneys.com ([134.129.252.29])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22846
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 9 Jul 1996 02:30:09 -0700 (PDT)
Received: (from zach@localhost) by freebsd.gaffaneys.com (8.6.12/8.6.12) id EAA05222; Tue, 9 Jul 1996 04:31:02 -0500
Message-Id: <199607090931.EAA05222@freebsd.gaffaneys.com>
Date: Tue, 9 Jul 1996 04:31:02 -0500
From: zach@blizzard.gaffaneys.com
Reply-To: zach@blizzard.gaffaneys.com
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: bin/1377: Possible security hole in mv(1)
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>Number:         1377
>Category:       bin
>Synopsis:       mv(1) retains the setuid bit when it is unable to preserve the uid.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul  9 02:40:01 PDT 1996
>Last-Modified:
>Originator:     Zach Heilig
>Organization:
Zach Heilig (zach@blizzard.gaffaneys.com)
>Release:        FreeBSD 2.1.0-RELEASE i386
>Environment:
FreeBSD 2.1.0-RELEASE
	

>Description:

	
mv(1) will retain the setuid bit on a file when it is unable to
preserve the uid.  This would, for example, allow one user to create a
setuid executable, and if they should somehow convince a different
user to mv(1) it to a different filesystem, they have access to that
users account.  mv(1) should not retain either the setuid or setgid
bits when it is unable to preserve both the uid and the gid of the
file.  This would bring it in line with cp(1) which mv(1) is
theoretically supposed to be using.  I would track it down, but I
don't have the mv(1) source online.

>How-To-Repeat:

	
Script started on Tue Jul  9 03:50:45 1996
$ whoami
user1
$ pwd
/usr/home/user1
$ mkdir foo
$ chmod 777 foo
$ cd foo
$ touch bar
$ chmod 6755 bar
$ ls -l bar
-rwsr-sr-x  1 user1  user  0 Jul  9 03:51 bar
$ exit
Script done on Tue Jul  9 03:51:14 1996

Script started on Tue Jul  9 03:51:24 1996
$ whoami
user2
$ cd /tmp
$ mv ~user1/foo/bar .
mv: ./bar: set owner/group: Operation not permitted
mv: ./bar: set mode: Operation not permitted
$ ls -l bar
-rwsr-xr-x  1 user2  wheel  0 Jul  9 03:51 bar
$ exit
Script done on Tue Jul  9 03:51:39 1996

>Fix:
	
	
>Audit-Trail:
>Unformatted:
sw-bug