Path: utzoo!attcan!uunet!yale!cmcl2!husc6!ddl
From: ddl@husc6.harvard.edu (Dan Lanciani)
Newsgroups: news.admin
Subject: Re: mkdir() and security hole   *****FIX****
Summary: not a solution
Keywords: mkdir hole fix
Message-ID: <851@husc6.harvard.edu>
Date: 17 Dec 88 01:46:51 GMT
References: <9466@merch.TANDY.COM>
Organization: Harvard University, Cambridge MA
Lines: 41


	The proposed mkdir replacement does not solve the problem.  I
do not know if it introduces additional problems of its own, but I
would not recommend running it since the gain in security is minimal.
I will not describe in detail the variation required to subvert the
mkdir replacement, but consider the interval immediately before its
chown() call.  I will outline a mechanism for creating a mkdir program
which can at worst be tricked into changing the ownership of a corrupt
(0-length) directory to which the (ab)user already has write/rename
access or to which s/he can (sym)link.  Unfortunately, this mechanism
requires that "" refer to the current working directory and this
feature/bug has been eliminated from System V.

1.  Create (mknod) the desired directory with restrictive permissions.

	(At this point, the user may delete the new directory and
	move into place one of his own in an attempt to acquire ownership.)

2.  Change working directory to the created directory (chdir).

3.  Obtain the size of the current working directory (stat).  If it
    is non-zero, someone is trying to spoof the program.  Exit, make
    a log entry, or whatever.

4.  Link the current working directory to "." (link("", ".")).  If this
    fails, something is seriously wrong.  Exit.

5.  Link the parent to "..".  Exit if it fails.

6.  Change the ownership of the current working directory (chown("",...)).

Note that since this procedure changes the current working directory
of the process, a multiple-argument mkdir must fork() n - 1 times
to make n directories.  It is inadvisable to attempt to return to
the previous current working directory in order to avoid the fork().

	Ambitious security analysts might want to examine rmdir and
suid versions of mv for related, but less serious, problems.

				Dan Lanciani
				ddl@harvard.*