From mark@linus.demon.co.uk  Tue Jun 25 18:41:11 1996
Received: from linus.demon.co.uk (linus.demon.co.uk [158.152.10.220])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA21334
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 25 Jun 1996 18:36:40 -0700 (PDT)
Received: (from mark@localhost) by linus.demon.co.uk (8.7.5/8.7.3) id CAA08997; Wed, 26 Jun 1996 02:36:22 GMT
Message-Id: <199606260236.CAA08997@linus.demon.co.uk>
Date: Wed, 26 Jun 1996 02:36:22 GMT
From: Mark Valentine <mark@linus.demon.co.uk>
Reply-To: mark@linus.demon.co.uk
To: FreeBSD-gnats-submit@freebsd.org
Subject: security problem with mv(1)
X-Send-Pr-Version: 3.2

>Number:         1351
>Category:       bin
>Synopsis:       security problem with mv(1)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    guido
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 25 18:50:02 PDT 1996
>Closed-Date:    Mon Mar 10 20:19:39 MET 1997
>Last-Modified:  Mon Mar 10 20:20:14 MET 1997
>Originator:     Mark Valentine
>Release:        FreeBSD 2.2-CURRENT i386
>Organization:
>Environment:

	n/a

>Description:

	There appear to be several bugs in mv(1) which might result in
	a file being readable and/or writeable by unauthorised users during
	and after a cross-device 'move' - see function fastcopy().

	One example is a file with mode 660, group 'bin', created in
	/tmp.  If I move this to my home directory (I'm not in group
	'bin'), mv warns me about `set owner/group: Operation not
	permitted', yet leaves the file writeable by anyone in the
	group to which my home directory belongs.

	Even in cases where the final fchown() will succeed, there's a
	window during the move (which may be significant for a large
	move across file systems) in which the same problem exists
	(at least for read permissions).

	I'm sure it's possible to imagine more serious real world
	examples - I only contrived this example because I spotted
	it while trying to figure out whether it's valid to shut up
	mv about the failed fchown() - I note that SunOS 5.5 mv
	doesn't give the warning, but has part of the bug (in an
	example similar to the one above, it left the target file
	readable but not writeable to the wrong group).

	(Another bug involves failing to remove the target when
	hit by a signal during the copy, but I think I remember
	some discussion on that one already.)

>How-To-Repeat:

	$ touch /tmp/foo
	$ chmod 660 /tmp/foo
	$ mv /tmp/foo $HOME

	(For the last part, I used a small file and added a sleep to
	fastcopy()...)

>Fix:
	
	The second problem might be fixed by moving the fchown/fchmod
	to between the open and read/write loop.

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 21:16:47 PDT 1996 
State-Changed-Why:  

Anyone out there familiar with mv, and, potentially, this bug? 
Responsible-Changed-From-To: freebsd-bugs->guido 
Responsible-Changed-By: mpp 
Responsible-Changed-When: Fri Feb 21 14:02:27 PST 1997 
Responsible-Changed-Why:  
This should be evaulated by one of our secirity officers... 
State-Changed-From-To: feedback->closed 
State-Changed-By: guido 
State-Changed-When: Mon Mar 10 20:19:39 MET 1997 
State-Changed-Why:  

>Unformatted:
