lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200411232158.iANLw0nj015907@plug.fi>
Date: Tue, 23 Nov 2004 13:58:00 -0800 (PST)
From: "Troy" <tjk@...oft.com>
To: bugtraq@...ession.spiral-arm.org (James Youngman)
Cc: srevilak@...akeasy.net, parimiv@...haw.com, martin.buchholz@....com,
	levon@...ementarian.org, bugtraq@...urityfocus.com, bug-findutils@....org
Subject: Re: Changes to the filesystem while find is running - comments?


James,

Would it be possible to replace the sanity check for inode number with a
sanity check for cwd and directory name? After all, if the directory is 
moved (renamed or given another parent directory) while find is running, 
then the CWD will have changed. On the other hand, if stat'ing or chdir'ing 
the directory has caused automount to mount a new filesystem on it, the 
CWD will not have changed. This would seem to be a fix.

What do you think?


Troy
 


> 
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ