AUSAM/distribut.doc/security.n

.HE "EECF" "UNIX in a Hostile Environment" "UNSW"
.FO "Peter Ivanov"
.ce 4

or

Mouse Watching by a Cat

by

Peter Ivanov

.PA
As supervisor of the largest UNIX system in Australia, I read
with some amusement the section on UNIX security in the July UK Newsletter
and decided to share with you some reminiscences about "UNIX cracking"
from my colleagues and myself.
The incidents described in this account are NOT fictitious, although some may
seem so.
.PA
Firstly, however, I must say that Ian and Mike from UKC really only touched
the surface of the problem and unfortunately showed admirable restraint
in NOT resorting to "inelegant expedients" which in my experience can make
a system about as stable as a teacup in a typhoon.
.PA
Our system in Computer Science at UNSW (see equipment summary) currently
supports more than 550 student users, a small proportion of whom would
very inelegantly stab the system in the back given half a chance.
Whether through malice, incompetance or chance all users are dangerous to
varying extents and a system cannot be called "secure" unless it at
least resists (if not defeats) all attempts to bring it undone!
Thus security, in my book, encompasses a number of aspects, some of which are
.BP 7 4
a)	Protection against depletion of system resources (such as disc space,
proc slots etc),
.NP
b)	Protection of individual users information (files) from corruption
or observation by other users, and
.NP
c)	Protection of priviledged or proprietary software from those
users not granted access.
.EP
.PA
Obviously when a system is cracked in such a way as to give the
"cracker" super-user status that is the end of all security but if any aspect
mentioned above is cracked, the results could be just as serious.
.PA
Now to some story telling.
.PA
We obtained our first UNIX system (level V) in 1975 and the first few tales
date from this period.
From the very first days "pseudo login" programs appeared, NOT
in order to steal names and passwords for our little 11/40 system
I hasten to add, but to crack the Cyber-Kronos system with which we shared
the terminals.
Soon it was quicker to see a second year student to get more money
put in your Cyber account
than to see the computing centre.
It is obviously very difficult to defeat a well written "login" program
and about all one can do
is try and break its grip on the terminal.
.PA
Soon the "computniks"
tired of "Cyber cracking" and turned their attention
to UNIX.
A super-user accidentally left the source mounted "readable by others" for
about 30 minutes.
In this time user file space soared (copies of source in various disguises)
and a bug was discovered in "login" where password length was not checked
properly and enabled a password of specific length to be entered followed
by its known encryption.
It took two days to clean up all the set-uid-root shells and spare source
AND ALL IN 30 MINUTES!!!!!
.PA
Another old favourite usable with shells which search in the order
"x, /bin/x, /usr/bin/x" was to leave a dummy command (eg "ls") in any
writeable directory (even your own) and wait for a super-user
to blunder past.
A simple "chmod, chown, unlink, exec" sequence worked wonders.
As with fishing most of the fun was in selecting the correct bait and tackle.
.PA
A variation of the above method works well on sloppily maintained systems
where "writeable-by-others" commands are some times available for even the
shortest periods of time.
By over-writing the command
with one which does "that little extra" you once more wait for a super-user
to execute it for you.
The shell problem is easily fixed by changing
the search order for uid zero, but its variant is more difficult
and will be discussed later.
.PA
Inevitably, holes in existing code are always popping up.
Our local classic was the "lpr-lpd" combination.
Our "/dev" directory used to be fairly rigidly protected and in order
for lpr and lpd to access user files and "/dev" they were set-uid-root.
All was well until people discovered the remove (-r) after printing flag on
lpr.
I leave you to contemplate what could happen and assure you that it did.
.PA
Looking over a super-users shoulder can give exhaustive encryption programs
a very good head start.
Early on we discovered that passwords
should be at least 10 characters long and, if possible, totally meaningless.
Fortunately, Australia abounds in 10-30 character aboriginal place names
that few would dare to pronounce.
.PA
In late 1977 our prayers for a larger PDP for teaching purposes were answered
and I was given the rare opportunity of supervising building modifications,
cabling, installation, maintenance, software development and making the
afternoon tea for the workers,
all of which, believe it or not, affect security.
.PA
The reason why building modifications and installation are important
was summed up
beautifully by a salesman of "secure systems" who said
.IN
"This system is guaranteed secure as long as it is
	not removed from the concrete box....."
.OT
Several people I know could, given access to the front panel, crack any
machine on campus in less than 30 seconds.
To lay hands on our 11/70 one must pass through four lockable doors, the
last of which has a unique key and is always locked.
.PA
Terminal laboratories should be located nearby and be laid out in a systematic
manner so that during brief, irregular and frequent visits, particularly
out of normal hours, budding computniks may be identified by sight and
login name.
They may then be watched and, when they have progressed sufficiently,
asked around for a cup of tea and given something useful to do in return
for "certain favours".
This way they get to further their skills and we get cheap programmers.
.PA
Local software developments have resulted in a system as secure as humanly
possible.
AUSAM, described elsewhere,
has implemented resource limits (procs, disc space, page limits etc) so
well that I can recall
only once running out of disc space, caused by a bug in a super-user
program.
.PA
Other software changes are:
.BP 7 4
a)	"Bug" programs to watch computniks and warn of their presence.
.NP
b)	Programs to scan file systems setting modes and owners, and reporting
on "funny" files (those with names containing unprintable characters
or starting with '.', or
having set-uid-root modes).
.NP
c)	Alteration of "init" to fork a "login" instead of a super-user
shell in single user mode.
.NP
d)	Alteration of "login" to cope with the "no password file" situation.
.NP
e)	Changes to a vast array of programs (work still in hand) to create
files mode 600 or 700 so that users are protected by default.
This is a partial solution to the shell variant mentioned earlier
but unfortunately one must still depend on super-users never being clumsy.
.NP
f)	Fixing "sgtty" to disallow calls setting modes on a tty not owned
by the user.
This practice was being used to acquire terminals and
access to other users accounts by setting incorrect baud rates
or parity and forcing
the unsuspecting victim to leave because he thought the terminal had stopped
working.
.NP
g)	Modifying "passwd" so it asks for the new password without echo
so that users passwords are not visible on a "ps".
.EP
.PA
Finally some random points:
.BP 7 5
a)	We only have one super-user, root, and refrain from
using this login name
on any terminals except those over which
we have absolute control, in or near the 11/70 room.
.NP
b)	Our shell searches in the order "/etc/x, /bin/x, /usr/bin/x, x" for
uid zero and placing all super-user needed commands in "/etc" actually
makes ones life easier.
Also placing "su" in "/etc" completely removes any worries about
"using
the wrong one"
when super-user status is required since "/etc/su" must be used.
.NP
c)	Periodically I run off a complete "ls -ali" of the mounted system
and take it home for some sunday morning reading, along with lists of all
set-uid files and copies of "my computniks" latest creations.
.NP
d)	To combat "login" programs a "grep login" of the whole system
will usually obtain the desired results unless unusual measures have been
taken to disguise the programs presence.
.NP
e)	When confronted with a user who has obviously been acting the fool
(eg sending billions of nulls to some poor buggers terminal or stealing
other users login names) he should be immediately "excommunicated".
That is all his files should be made inaccessible and his initial shell
should be changed to give a curt message to "see the system supervisor"
before exiting.
Nothing hurts a computnik like no computing.
When he comes grovelling simply tell him what he did wrong (not what
he is accused of doing wrong, note), promise that if it happens again
the removal will be final, and give him back his fun.
Naturally watch him very closely for the next few months.
.EP
.PA
At this point I was going to say something trite about our system never
having been cracked but alas I cannot.
During a normal "ps -agl" last week, the first year computniks were
discovered running a setuid shell made up to look like a "getty".
They were sprung in the act and under the threat of excommunication revealed
that we too are sloppy.
They had found a writeable command thanks to a poorly written run file, had
compiled a special version of the command
and had waited for a super-user to execute it.
They were rather peeved that they only had about 30 minutes to explore
before being caught but swore that they
had done nothing nasty in that time.
.PA
I suppose the only thing I can say in defence is that these gentlemen
have recently
cracked several other machines on campus, but we asked them
around for that cup of tea months ago.