Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!killer!vector!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (The Beach Bum) Newsgroups: news.admin Subject: Re: mkdir() and security hole *****FIX**** Summary: Nope, not a fix ... REALLY! Message-ID: <10115@rpp386.Dallas.TX.US> Date: 19 Dec 88 19:43:15 GMT References: <9466@merch.TANDY.COM> <851@husc6.harvard.edu> Reply-To: jfh@rpp386.Dallas.TX.US (The Beach Bum) Organization: Big "D" Home for Wayward Hackers Lines: 103 In article <851@husc6.harvard.edu> ddl@husc6.harvard.edu (Dan Lanciani) writes: > 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 wouldn't go THAT far. The fix is very simple and the resultant code should be significantly more secure. However, Doug's mkdir is no more secure than the AT&T version. Only the method required to break it is different, and yes it is breakable. Almost as easily so. To break in, the following behavior is required. The unlink() call is needed, along with mv(1) being able to rename a directory. In this case, a C program is really needed so the directory can be read. This is a plus since using nice(2) increases the window during which the directory can be cracked. You can even get around the need for a C program. Simply have ls tell you what files are there ... > 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. This is bunk. A completely secure version can be created using the outline provided by Doug. The '' feature is not required, the '.' link created inside of the `secure' directory is more than addequate since only root would be able to do anything to that link, once created. And, once inside the secure directory, the integrity of the entire directory can be tested. This should make it impossible to spoof mkdir. >1. Create (mknod) the desired directory with restrictive permissions. So far, so good. > (At this point, the user may delete the new directory and > move into place one of his own in an attempt to acquire ownership.) Yes, this is the flaw with the real mkdir and Doug's as well. >2. Change working directory to the created directory (chdir). This is part of the fix. You can't allow the secure directory to be accessed from outside of the secure directory by the program. That directory itself could be replaced with a `bad guy' version. >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. Not needed, and even still, this is spoofable [ I think ... ] in the absense of the '' bug. >4. Link the current working directory to "." (link("", ".")). If this > fails, something is seriously wrong. Exit. This requirement can be gotten around by verifing you have the correct ".." link in your directory along with the correct "." link. Hint: fstat the file descriptor you get after opening the directories and HOLDING them open. You will need 4 open files, the parent, the secure directory, and the . and .. entries in the secure directory. Test those to insure the links are to the correct files. Once the directory is secure, you can do all of the other tinkering inside of the secure directory without fear of compromise. >6. Change the ownership of the current working directory (chown("",...)). Would be nice if you could do it, no? However, we have validated our "." entry after 4), so we can chown (".", ...); THAT works. >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(). Again, we have validated our ".." entry to point towards our correct parent directory. There is no reason it should not work. > Ambitious security analysts might want to examine rmdir and >suid versions of mv for related, but less serious, problems. Ambitious nay-sayers should always call the programmer being brought to task and have a nice long conversation. Or do us a favor and point out the flaw explicitly. To summarize, Doug's mkdir has the same weakness as the AT&T version. It took 34 seconds to break this site [ after altering a few directories first ... ], after writing a suitable script it should take about the same amount of time using Doug's. Using a C program would take less time since the window of oppurtunity can be narrowed, and more attempts can be made to locate the `secure' directory. This is the only change required. Oh yes, I may do a mkdir of my own and post it. I suspect Doug will beat me to it ... Sorry, Doug, you better get ready on that 'C' key ;-) -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 |"Unix doesn't have bugs, InterNet: jfh@rpp386.Dallas.TX.US | Unix is a bug" UucpNet : !killer!rpp386!jfh +-- -- author forgotten --