From zach@blizzard.gaffaneys.com  Tue Jul  9 02:30:11 1996
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
Subject: Possible security hole in mv(1)
X-Send-Pr-Version: 3.2

>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:    guido
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul  9 02:40:01 PDT 1996
>Closed-Date:    Mon Mar 10 20:20:44 MET 1997
>Last-Modified:  Mon Mar 10 20:21:40 MET 1997
>Originator:     Zach Heilig
>Release:        FreeBSD 2.1.0-RELEASE i386
>Organization:
Zach Heilig (zach@blizzard.gaffaneys.com)
>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:
	
	
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 21:31:52 PDT 1996 
State-Changed-Why:  

Confirm Status 
State-Changed-From-To: feedback->open 
State-Changed-By: scrappy 
State-Changed-When: Wed Oct 23 00:09:24 PDT 1996 
State-Changed-Why:  

It still exists in 2.1.5-RELEASE.  I will see what I can do to fix 
that particular problem, meaning make it emulate cp(1) if it cannot 
preserve permissions.  That seems to be the most sane route to take at 
this point (and the mv(1) man page says that is does in fact emulate 
cp(1) in the case of permissions). 

I just grabbed the 2.2 source to see if it existed there too, assuming 
ftp://freebsd.cdrom.com/pub/FreeBSD/FreeBSD-current/src/bin/mv is a 
current snapshot. (it does) 

There was a short discussion about what the behavior of mv(1) should 
be in that situation, but I don't think anything came of it. 

--  
Zach Heilig (zach@blizzard.gaffaneys.com) | ALL unsolicited commercial email 

Responsible-Changed-From-To: freebsd-bugs->guido 
Responsible-Changed-By: mpp 
Responsible-Changed-When: Fri Feb 21 14:10:19 PST 1997 
Responsible-Changed-Why:  
Needs to be evaulated by a security officer. 
State-Changed-From-To: open->closed 
State-Changed-By: guido 
State-Changed-When: Mon Mar 10 20:20:44 MET 1997 
State-Changed-Why:  
Solved in rev 1.12 of mv.c 
>Unformatted:
sw-bug

