andy@gswd-vms.UUCP (11/06/86)
SUMMARY: Darryl Wagoner broke into the system and deserves
(will get) the TV.
Some of the concerns expressed were results of errors
made at the show by booth personnel who had performed
a 'quick' UTX/32S (*) installation.
Security involves H/W, S/W *and* PEOPLE!
Gould is still HIGHLY confident in the security of UTX/32S
and is willing to 'up the ante'.
This episode has very nicely illustrated one of the key issues
associated with security --- if one is overly enamored with the
technological aspects and shortchanges the people aspects, the
'system' will be just as susceptible to penetration as it would be
without the 'security' technology. For this reminder, we thank
Mr. Wagoner.
So how is it that Darryl broke into the 'system' so easily?
Darryl noticed that the restricted environment mechanism could
not be defeated so he approached the problem using the "unwary-
system-administrator" bag of tricks combined with several trojan
horses.
Off-hand, it may seem that what Darryl did wasn't fair. However,
it was quite fair, and furthermore, this method of penetration is
rather common and is usually quite a bit easier to use than
defeating the software mechanisms. No secure system will remain
secure for very long if the administrators and the users are not
security conscious.
As part of the C2 requirements set by the National Computer
Security Center, good system administration manuals are required
to train the system administrators about good security practices
and warn them about common threats.
For instance, the UTX/32S System Administrator's Guide (SAG)
says:
A secure operating system shares the responsibility of
enforcing security with the system hardware and system
administrators. Each of these three elements -
operating system, hardware, and administrators - must
be trusted; this is, they must be relied upon to uphold
the security policy."
In the case of UNIX expo, the system administrators made a few
*mistakes*. The two main mistakes were putting "." as the first
thing in their PATH and executing a user's program for him, as
superuser no less! Losing the audit trail file also ranks up
there with the first two.
The system administrator's guide also says:
When you are working as superuser, any command or file
executed, directly or indirectly, may run with
superuser privileges. Therefore, avoid running any
file that could have been created or modified by a
general user. It is imperative that superuser
privileges be used as sparingly as possible.
Unfortunately, our staff at the booth at the EXPO faithfully
followed the instructions for a piece of third party S/W that
explicitly asked that "." be put in the PATH. This documentation
is being fixed. Securely administering a system is not easy.
This is, however, a weak excuse, and certainly a fatal excuse in
an environment where security is critical. System administrators
have to be aware of potential security threats.
There is a place for software mechanisms in the protection of a
system. UTX/32S has a number of mechanisms, mostly transparent
to the user, like the restricted environment, a stronger access
policy for /dev devices, crosschecks on passwd and group files,
and the removal of the setuid bit.
There are a number of other security mechanisms that can be used
and a number of different ways to build a secure UNIX. Darryl
feels that the setuid bit is necessary for it to remain UNIX.
This is a valid viewpoint held by many. There are equally many
on the other side of the fence claiming that removing the setuid
mechanisms is necessary. Security is not free.
In UTX/32S the setuid bit has been removed. Yes, this has
been painful but there are just too many ways to subvert UNIX
using the setuid mechanism. Those mechanisms that required a
setuid mechanism of some kind have been replaced by what we
call trusted servers, secure sockets, and clients.
There were a number of other problems that Darryl had with
UTX/32S.
sucsh(8)
Darryl thought the command was called cshsu(8) rather than
sucsh(8). However, there was a time at the show that
sucsh(8) was disabled by the system administrator.
Darryl said that "." should not have been in the PATH.
He is *absolutely* right. Putting "." at the end of
the PATH may be a good compromise. We are also considering
having the sucsh shell totally ignore ".". The sucsh(8)
command does not have "." in its PATH. However, the system
administrators explicitly put "." in their PATH for
reasons stated above. This should not have been done!!!
Audit Trail
As delivered on the boot tape, the UTX/32S audit trail
mechanism does not remove the audit file at boot time.
Again, the problem was due to a system administration
error. When the system was rebooted, the audit trail
file was removed because the system administrator had
put "rm <audit file>" in the rc file right before the
audit system was enabled.
kill character
Darryl suggested having a kill character or secure
attention key to kill all processes and get a trusted
login. This is known as a trusted path, is required
at higher security levels and will be in a subsequent
(higher security level) release of UTX/32S.
Now to address Darryl's overall question, is a trojan horse a
legitimate way to break into a system.
First you have to define the word "system". Since security is a
combination of the computer and the administrative procedures,
the security "system" may also be defined as both. In this case,
a trojan horse, bribing the security guard to let you in to the
console room, or adding trap doors at the software development
site previous to software completion, are all legitimate means of
breaking into a system.
It should also be noted that the C2 level (at which UTX/32S
is being certified), exists primarily to protect non-malicious
users from each other and to protect the system from user mistakes.
Only at B1 and above is the malicious user a required consideration.
In the real world, the bottom line is that if someone wants to
access your computer's data, anything is fair game. This is why
physical security and proper administrative procedures are so
critical.
SO ....
THE CHALLENGE REMAINS:
An offer is extended to Mr. Wagoner to try again *without* our assistance.
If he successfully gets into a file that we will create, he will get a VCR
to go along with his new TV!!!!
p.s. For those who feel that they can break UTX/32S and wish to have a
go at it, please send 'e-mail' to the following address for details.
(The stakes are a color TV plus the VCR [Thanks to Darryl])
{ucbvax,decvax}!pur-ee!gould!securix
We request the following info:
Name
Title
Company
Address
Phone #
Best network address
James E. Clark ... Director, Systems Marketing, Gould Inc
{ucbvax,decvax}!pur-ee!gould!jclark
Andy Schuelke ... Project Manager, Secure Systems, Gould Inc
{ucbvax,decvax}!pur-ee!gould!aschuelke
Mikel Matthews ... Project Scientist, Secure Systems, Gould Inc
{ucbvax,decvax}!pur-ee!gould!mmatthews
--------
* UTX/32S is a secure version of Gould's UTX/32 operating system
and is certifiable at the C2 level as defined in the Department
of Defense Trusted Computer System Evaluation Criteria (TCSEC).mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) (11/16/86)
This is probably going to blow any chances I had of working for Gould, but given what I've heard about them over the year or so, I'm not too interested anyway... Flame/Snickers/Jabs On>>> In article <1500001@gswd-vms> andy@gswd-vms.UUCP writes: > > >SUMMARY: Darryl Wagoner broke into the system and deserves > (will get) the TV. > > Gould is still HIGHLY confident in the security of UTX/32S > and is willing to 'up the ante'. Ha. Double or nothing, huh? You guys are sorry losers. And, no, guys, I will __NOT__ volunteer to do your homework for you. If you want to _pay_ me to sit down with the src to the whole system, and give me unlimited time, I'll bet that I can find holes. >In the case of UNIX expo, the system administrators made a few >*mistakes*. The two main mistakes were putting "." as the first >thing in their PATH and executing a user's program for him, as >superuser no less! No kidding. This is only about the _most_ well known trick in the book. I used it (successfully) when I was a sophomore in college. Did you guys ever read the paper on Unix security? Just in case... "UNIX Operating System Security", Grampp & Morris, AT&T Bell Labs Tech Jour 63, pp 1649-1672, October 1984. You might check it out, it's a neat article. >The system administrator's guide also says: > > When you are working as superuser, any command or file > executed, directly or indirectly, may run with > superuser privileges. Therefore, avoid running any > file that could have been created or modified by a > general user. It is imperative that superuser > privileges be used as sparingly as possible. > >Unfortunately, our staff at the booth at the EXPO faithfully >followed the instructions for a piece of third party S/W that >explicitly asked that "." be put in the PATH. Chuckle, chuckle. It really helps if you _read_ the documentation, but I bet the guy running the booth _knew_ what he was doing. He'd already RTFM. He was a Unix _guru_. Snort, snicker, chuckle. (My apologies if he was a "she"). >This is, however, a weak excuse, and certainly a fatal excuse in >an environment where security is critical. No kidding, really? And you are trying to sell this product? >In UTX/32S the setuid bit has been removed. Oh, I get it, it's not Unix, it just looks like Unix. Next thing you know, they'll take out job control, and signals (those are really dangerous, ya know). >* UTX/32S is a secure version of Gould's UTX/32 operating system >and is certifiable at the C2 level as defined in the Department >of Defense Trusted Computer System Evaluation Criteria (TCSEC). Yeah, right. <<<<Flame/Snickers/Jabs Off OK, a few comments. Let me see if I have this straight; You spent years of effort to cripple Unix, got it rated as a secure system, and then in your first (I hope it was the first) public demonstration you let some bozo throw all your effort down the tubes. Good move. (I _hope_ it was a salesman running the both, not someone who claims to know unix). Seriously, if I were trying to buy a secure OS, I'd stay away from Unix. I'd probably stay away from anything that allowed logins. And I'd certainly stay very far away from a product that was sold by a company that screwed up this badly. The bottom line is this: security is not just code (as you've discovered). And screwing up like this suggests that your security is not anywhere near as good as you'd like us to believe. We have no way of knowing what other holes are still unplugged. How can you expect us to believe that you've done a good job when you fail the simplest test? And this bit about removing the setuid bit. Tsk, tsk. In my eyes, you guys are just lazy. I think it would be pretty easy to deal with setuid programs. For shell scripts, start them out with "unalias *" "set path=()" For C programs, change the system(3), exec??(3), and exec(2), calls to check and see if these programs are "known" to be safe. You could still allow execs; just turn off setuid in the exec call. That gets rid of exec-ing to csh. And the finger bug... And that leaves stuff like the sendmail bug. Well, you can probably get around that one by using groups and setgpid. Very few things _have_ to be setuid to root. -- Larry McVoy mcvoy@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"
mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) (11/17/86)
>In article <1700002@gswd-vms>, andy@gswd-vms.UUCP writes:
[See previous articles]
In all fairness to Gould, I should probably say that they do have
a fairly nice machine with fairly nice software. And the people
that I've met from Gould have been very laid back. It wouldn't
be a bad place to work.
None-the-less, this still has to be one of the bigger screwups I've
ever seen and I agree with Rick Adams: if Gould is serious about
having their system worked over, they should offer the big $$$$,
not toys. We all have better things to do.
--
Larry McVoy mcvoy@rsch.wisc.edu,
{seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy
"They're coming soon! Quad-stated guru-gates!"rlk@mit-trillian.MIT.EDU (Robert L Krawitz) (11/19/86)
Seems to me that the advice not to use block mode terminals is the right thing. I'd be even more restrictive: always use a hardcopy terminal as the console, at least in a multiuser system. When you have problems, it IS nice to see just what happened. -- Robert^Z
rick@potpourri.UUCP (11/21/86)
> [See previous articles] > > In all fairness to Gould, I should probably say that they do have > a fairly nice machine with fairly nice software. And the people > that I've met from Gould have been very laid back. It wouldn't > be a bad place to work. Yes, GOULD is a very nice place to work. Not all of the people are "laid back", but that is not one of my requirements for employement! As a GOULD employee I enjoy benefits that are equal to or better than that of other major corporations (with the added benefit of LIVING in Ft. Lauderdale). ============================================================================= ____________ / /] GOULD COMPUTER SYSTEMS DIVISION ###########] ] __________ #######] ]________ in the cultural wasteland of / /] ####]/ /] #########] ] ##########] ] beautiful Fort Lauderdale, Fla. #########] ] ########] ] #########] ] ######] ] #########] ] ########] ] #########]/ ##########]/ ####] ] #######] ] ...mcnc!rti-sel!gould!rschneider ###########]/ ...akgua!ucf-cs!novavax!houligan!potpourri!rick The opinions expressed are not only not those of my employer, but they are not those of my own!
jc@cdx39.UUCP (John Chambers) (12/05/86)
Not to change the subject or anything, but I've been
hearing rumors for some time of a security mailing
list that is supposed to exist somewhere. I've been
interested in system security for some time, both out
of personal interest and because I am an administrator
for a bunch of machines and consultant to others with
machines where there are security interests.
Now, I've done my share of breaking and entering, mostly
on my own machines to learn how others might do it to me,
and also on others to illustrate to their owners how you
might do it to them. But I don't consider myself a real
security expert. When I try to learn more, I usually
find that everything printed is the easy stuff that I
already know about. The more sophisticated stuff I can't
learn about, because, well, it is too sensitive to let
just anyone know about it...
As a result, we have a situation where system administrators
don't learn how people can break into their systems, while
there is a small population around that knows much more than
you or I do about the subject.
Is there any way that someone not already working for the
NSA or CIA or DOD or whoever can really learn the good stuff
about system security?
The Gould discussion illustrates a good point. It is obvious,
given a little thought, that a super-user shouldn't have '.'
early in the search path. I sort of suspect that it shouldn't
be there at all, but I haven't yet figured out the proof. Until
I read these articles, it simply hadn't occurred to me that this
was a security problem. (Well, it was obvious that '.' shouldn't
be first in $PATH; I can claim at least that much intelligence. :-)
I'll add this to my list of things to tell security-conscious
administrators about. Where can I get a comprehensive list of
all the other security holes known to Unix wizards?
--
John M Chambers Phone: 617/364-2000x7304
Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193
Clever-Saying: For job offers, call (617)484-6393 evenings and weekends.