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).rick@seismo.CSS.GOV (Rick Adams) (11/16/86)
In article <1700002@gswd-vms>, andy@gswd-vms.UUCP writes: > > Gould is still HIGHLY confident in the security of UTX/32S > and is willing to 'up the ante'. Wow, Gould is really laying big money out now. Their first offer was a few pounds of chocolate, then a TV, now a TV and a VCR! They're probably risking over $500! What confidence! What's next? A digital watch maybe? Considering the big deal Gould has made over "challenging hackers" to break into their systems and having no successful breakins, you'd think they'd put up real money. If your system is that secure, why don't you offer say $20,000 for a legitimate bug in the system (no operator error type problems). Then, some of the more talented people who wouldn't waste their time over some chocolate or a TV might take an interest. That might show how much is confidence in your system and how much is marketing hype. ---rick p.s. It's sort of funny that your machine name is gswd-vms when you are running 4.3bsd unix.
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!"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!
huds@ur-tut.UUCP (hudson) (11/27/86)
In article <42081@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >Considering the big deal Gould has made over "challenging hackers" to >break into their systems and having no successful breakins, you'd >think they'd put up real money. > >If your system is that secure, why don't you offer say $20,000 for a >legitimate bug in the system (no operator error type problems). Then, >some of the more talented people who wouldn't waste their time over >some chocolate or a TV might take an interest. Oh come on! Give it a break, it's quite clear that they already have enough of our attention. I don't think $20k would buy them that much more publicity (the REAL point to this whole adventure). A. Hudson [seismo | decvax | allegra]!rochester!ur-tut!huds USENET ur-tut!huds@rochester.arpa ARPA
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.