Message-ID: <20041122102712.GA21751@excession.spiral-arm.org>
Date: Mon, 22 Nov 2004 10:27:12 +0000
From: James Youngman <bugtraq@...ession.spiral-arm.org>
To: bugtraq@...urityfocus.com, bug-findutils@....org
Cc: parimiv@...haw.com, srevilak@...akeasy.net, martin.buchholz@....com,
	levon@...ementarian.org
Subject: Changes to the filesystem while find is running - comments?


Hello,

GNU find does a sanity check before and after calling chdir().  It
stats the directory it's about to move into, and stats "." after
chdir() succeeds.  It then compares the device numbers and inode
numbers returned by he two stat() calls.  This is done in a function
called wd_sanity_check().  If these are different, find prints an
error and exits fatally (in versions up to and including GNU findutils
4.2.5.

The intent here is to detect the situation when someone is moving
directories about while find is running.  This could be done with
malicious intent.  The thinking behind this is that (for example)
there is a risk that find be persuaded to search a part of the
filesystem which it hadn't planned to (e.g. find /foo -depth -delete).

If you are running an automounter, it will often mount a filesystem
when triggered by the fact that a process chdir()s into a mount point.
This will obviously trigger a failure in the check that
wd_sanity_check() performs.  Hence for many versions of findutils,
find will not be able to search a directory hierarchy containing an
automountd mount point.   That's obviously undesirable.

I have recently started trying to figure out a way to solve this
problem without entirely disabling wd_sanity_check().   

As of findutils 4.2.6/4.2.7, find will read /etc/mtab (/etc/mnttab, or
whatever it is called on the current system) to determine if the
directory it has just moved into has recently been either mounted or
unmounted.  It does this by reading the mount table at startup and
again when wd_sanity_check() detects a problem (if the filesystem
appears in one list but not the other, it has either been mounted or
unmounted).  If ...

1. the relevant directory has recently been mounted or unmounted
AND
2. find is travelling down the directory hierarchy, not up

... then wd_sanity_check() allows the program to continue but prints a
warning.  Otherwise, it will exit fatally as before.  The rationale
behind being sensitive to the direction of the chdir() is that
chdir("..") shouldn't cause a filesystem to become mounted and
although the automountd might time a filesystem out and unmount it,
this only happens after a period of inactivity, and find will have
just been using this particular filesystem.  The check in
wd_sanity_check() doesn't pay attention to the actual type of the
filesystem (though it does report the type in the error message).

I have run into a problem as of findutils-4.2.7.  This is simply that
there seem to be cases where automountd on Solaris works by exchanging
one mounted filesystem for another.  I could support/allow this
behaviour by noticing that the device number for the filesystem has
changed and allow the wd_sanity_check() test to succeed, but then the
effect of this change is that almost any combination of changes to the
filesystem device number is permitted.  Hence my question is :-

    Is it worthwhile at all to perform this "sanity check" or is it of 
    insufficient benefit?

If there is some benefit in making a test of this type, what scenarios
should find watch out for?  What tests are useful and practical to
help find determine if someone is trying to exploit or mislead it?

I'm not considering here cases where the find command line is
specified by an untrusted data source - for the purposes of this
discussion the source of untrusted data is the directory hierarchy
that find is traversing.

I'd be grateful for your thoughts.

Regards,
James.

Powered by blists - more mailing lists