Date: Fri, 12 Mar 1999 00:48:48 -0700 From: Warner Losh <imp@harmony.village.org> To: "Geoff Rehmet" <geoffr@is.co.za> Cc: hackers@FreeBSD.ORG Subject: Re: The infamours "temp cleaner" debate Message-ID: <199903120748.AAA16897@harmony.village.org> In-Reply-To: Your message of "Fri, 12 Mar 1999 08:20:43 %2B0200." <199903120620.IAA09997@hangdog.is.co.za> References: <199903120620.IAA09997@hangdog.is.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
There is at least one winnable race here. If someone changed the
dierctory between the -d and chdir, then you could chdir someplace
else.
In message <199903120620.IAA09997@hangdog.is.co.za> Geoff Rehmet writes:
: lstat($subdir) || die "Cannot stat $subdir";
: -d _ || die "$subdir is no longer a directory!!";
attacker removes subdir and replaces it with a symbolic link to some
other place in the tree.
: chdir ($subdir) || die "Could not chdir from $item to $subdir";
boom. You have just followed the symbolic link. You are now in the
wrong part of the tree. Files start to disappear from places they
shouldn't disappear from.
: do_dir("${item}${subdir}/");
:
: # We intentionally "chdir .."
: chdir ("..") || die "Could not chdir to parent";
And you compound the problem by using relative paths.
fts(3) handles these problems already. Unless you can do a fchdir,
you won't solve the races that are plague this problem.
Finally, you die too much. An attacker could launch a denial of
service attack against cleaning programs which would cause them not to
run.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903120748.AAA16897>