From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Viro To: 9fans@cse.psu.edu Subject: Re: [9fans] mv vs cp In-Reply-To: <12744.1002525193@apnic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 8 Oct 2001 03:44:16 -0400 Topicbox-Message-UUID: 011f83ac-eaca-11e9-9e20-41e7f4b1d025 [I suggest taking the thread off-list - further details of rename() races in *BSD may be interesting, but they are off-topic for 9fans] On Mon, 8 Oct 2001, George Michaelson wrote: > Are you saying that this problem demonstrably exploited the race condition > between cp/mv and rename as implemented in FreeBSD? Yes. ufs_rename() is racy and yes, that race is wide enough to be exploitable. BTDT. > I really do mean the question as put: > > when was the last time anybody saw a successful exploit of this race condition > or an unstable filesystem they can show came from it, exploit or accident? > > I have seen many problems with UFS/FFS, and Softupdates gave me the willeys > but I have also not yet seen serious corruption of the on-disk state which > lies directly with problems in the FS code itself. Side-effects of kernel > crashes during meta-state updates, sure. But this sounds to me like FUD which > in practice doesn't exist. process 1: current directory in /tmp/a/a/a/a/a, does rename("/tmp/b/b", "a"); process 2: current directory in /tmp/b/b/b/b/b, does rename("/tmp/a/a", "b"); Normal outcome: first process to do rename() succeeds, second - fails with ELOOP. With the right timing _both_ succeed, creating a loop and detaching it from the rest of filesystem. Notice that use of relative pathnames is critical here - otherwise lookup in the second rename() will block on the lock acquired by the first one. Code in /sys/ufs/ufs/ufs_vnops.c implicitly assumes that lookups ending in descendants of directory will have to pass through that directory. That assumption is obviously false - namei(9) can start in a descendant of directory in question. And no, it's not too narrow - window includes quite a bit of disk IO. Figuring out details of turning that into full-blown attack (i.e. what should be done to widen the window) are left as an exercise to anyone who can RTFS - it's pretty straightforward.