mkdir() and security hole ***** ONE-LINE FIX !! ****

Dan Lanciani ddl at husc6.harvard.edu
Thu Dec 22 13:26:03 AEST 1988


In article <379 at skep2.ATT.COM>, wcs at skep2.ATT.COM (Bill.Stewart.[ho95c]) writes:
| nice(-255);	/* always win race condition  - fixes security bug */
| 		/* nice(-255) is not very nice, but root has its privileges */
| 		/* works with official mkdir and Doug's */
| 
| The original articles in news.admin pointed out a race
| condition in the /bin/mkdir used by V7 and System V
| older releases.  (mkdir runs setuid root, mknod's a
| directory then chowns it to getuid() - if you're fast you
| can rmdir the directory and ln /etc/passwd, especially if
| you nice -19 mkdir.)  Doug Davis posted a public-domain
| mkdir which he claimed fixed the problem.  Other people have
| pointed out that it helps, but doesn't prevent the race
| condition, and it's free source for people who only have
| binary systems.
| 
| Put a nice(-255) as the first line of your mkdir, and you'll
| "never" lose the race!!  The race condition worked, because
| on a loaded system, you could guarantee that sometimes your
| rm-and-link hack would happen between the mknod() and the chown(),
| as long as you ran the mkdir niced so it had a low priority.

	Unfortunately, this analysis is incorrect.  The real window
occurs while the mkdir process is blocked on disk I/O to, e.g., look
up elements of the path name of the file to chown().  No matter how
good a priority the process has, other processes will run while it
waits for the disk.  In fact, it is doubtful that you would ever
see the mkdir attack succeed if it actually required that the system
preempt the mkdir process "between" the mknod() and the chown().  Tests
with a well-crafted mkdir-breaker program showed that success was
nearly independent of process priority.
	Incidentally, the fix proposed by jfh at rpp386 (using dir/./.
as the target of the chown()) doesn't help either.  It was a good
try (and happened to be included in the mkdir test mentioned above)
but breaks down since link() itself is not atomic.

				Dan Lanciani
				ddl at harvard.*



More information about the Comp.bugs.sys5 mailing list