The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #4 1985-01-27 (1 file, 5046 bytes)
NOTICE: recognises the rights of all third-party works.


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: <[email protected]>

			*** 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
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...


	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
					[email protected]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Date: Mon, 21 Jan 85 14:43:45 est
From: allegra!seismo!harvard!dbr (Douglas Robinson)
Subject: 4.2 problems


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)


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

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':

		while (1) {

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
    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)


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)


    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).

	- 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??
	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!

    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

        Dave Lennert              ...{ucbvax, hplabs}!hpda!davel  [UUCP]
        Hewlett-Packard - ISO     [email protected]         [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 <[email protected]> [email protected] (Doug Gwyn <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
/* ---------- */