Hacker Chronicles 1/HACKER1.ISO/cud3/cud300e.txt

Text File | 1992-08-18 | 16KB | 340 lines

  ****************************************************************************
                  >C O M P U T E R   U N D E R G R O U N D<
                                >D I G E S T<
              ***  Volume 3, Issue #3.00 (January 6, 1991)   **
  ****************************************************************************

MODERATORS:   Jim Thomas / Gordon Meyer  ([e-mail])
ARCHIVISTS:   Bob Krause / Alex Smith / Bob Kusumoto
BYTEMASTER:  Brendan Kehoe

USENET readers can currently receive CuD as alt.society.cu-digest.
Anonymous ftp sites: (1) ftp.cs.widener.edu (2) [e-mail]
E-mail server: [e-mail].

COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing
information among computerists and to the presentation and debate of
diverse views.  CuD material may be reprinted as long as the source is
cited.  Some authors, however, do copyright their material, and those
authors should be contacted for reprint permission.
It is assumed that non-personal mail to the moderators may be reprinted
unless otherwise specified. Readers are encouraged to submit reasoned
articles relating to the Computer Underground.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
DISCLAIMER: The views represented herein do not necessarily represent the
            views of the moderators. Contributors assume all responsibility
            for assuring that articles submitted do not violate copyright
            protections.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

From: Name withheld
Subject: Security on the Net
Date: Sun, 23 Dec 90 17:04:49 -0500

********************************************************************
***  CuD #3.00: File 5 of 6: Security on the Net                 ***
********************************************************************

COPS is a unix security package that runs through a checklist of sorts
looking for common flaws in system security.

I polled a security mailing list and got about 40 responses to a selected
number of questions dealing with security; it might be useful for inclusion
on how the net (at least some of the security minded ones) view security.
The answers to these questions shaped some of the philosophies of COPS and
might be indicative of the type of security tools to be developed in the
future.  My questions start with a number and a ")".

   1)  What kinds of problems should a software security system (SSS)
   such as COPS check for? (Mention specific examples, if you can.)

Just about everyone agreed that the more things checked, the better.  Some
specific wants of items I didn't mention, more or less in the order of # of
requests:

Some kind of _secure_ checksum method for checking up on binary files.

Checking binaries for known security problems - sendmail, fingerd, ftpd,
ect.

Checking the validity of the _format_ of key files rather than merely
checking if they are writable.

Checking for potential trojan horses; files such as "ls" in a users
account.

Finding things hidden under mount points.

Keeping track of accounts in a seperate file from /etc/passwd and run
periodic checks to see if any accounts have been added by any unauthorized
user.

Report unusual system activity, such as burning lots of CPU time.

Record unsuccessful login attempts and su's to root, when and by whom if
possible.

   2)  Are there any security problems too sensitive to be checked
   by a SSS?  That is, what things should *not* be built into a SSS?

Boy, this was a landslide.  Over 90% said NO, and not only no, but
basically "Hell No".  The only concerns I got were against password
cracking and problems that could not be easily fixed.  There was also a
small amount of concern about limiting access to root, but most realized
that no matter what, the benifits would outweigh any losses if the programs
were put out.

   3) What should the primary goal of a SSS be -- discovering as many
   security holes as possible in a given system (including bugs or
   design flaws that may not be easily fixed -- especially without
   source code), or merely uncovering correctable errors (due to
   ignorance, carelessness, etc)?

Another landslide.  Of all the responses, only one person objected to
finding all holes, although a few did say that finding the fixable holes
was top priority.

One view:

My use for an SSS is as a system monitor, not as a diagnostic tool.  I
suppose the diagnostic version also has its uses, but writing and
distributing such a program is asking for trouble.  I don't see anything
wrong with writing it and distributing only the binaries.

   4)  Do you feel that SSS are a security threat themselves?

Some dissent begins to show.... It was almost even here, with the no's
beating out the yes's by a single vote.  However, 2/3 of the yes votes
qualified there answer by stating something like "a tool can be misused"
and whatnot.  Here are some typical responses:

Of course.  They point to way for bad guys.  Such is life.  They are a
tool.  They have the potential for anything.  The security threat lies in
how they are used....

No, as long as they don't breed complacency. Just by running a SSS each
night should not make you thinks your systems are secure.

Fire is also dangerous but VERY useful.


   5) Do you think that the SSS should be restricted to be used only
   by system administrators (or other people in charge), or should
   they be accessible to all?

Here's where the problems start :-)  Everyone wants as many features as
possible, but quite a few of you don't want anyone else to have it.  Hmm...
Out of 35 responses on this question:

  12 - Yes, only SA's.
  10 - No.
   6 - It would be nice to have it restricted, but... How?
   5 - Have two versions; one restricted, one not.  Needless to say,
        the dangerous stuff should go in the first.
   1 - Restrict only parts that detect bugs/whatever that cannot be
        repaired.
   1 - Argh!  Help!

     Some quotable quotes:

I don't see how it could be restricted.

Admins, etc only. (possibly said because I'm an admin. From an intellectual
standpoint, I would want to know about this stuff even if I was just a
user)

I think the SSS should be restricted to system administrators with the
realisation that others can probably get their hands on the code if they
want to.

Definitely available to all, SA's can be as lazy as anyone and should not
be allowed to hide behind a veil of secrecy if, in doing so, they expose
the systems they administer.

It seems to me that only an "administrator type" will have sufficient
privilege levels to make _effective_ use of such a tool.  Ordinary users
may be able to garner _some_ benefit though, if run on their own files.  If
possible, can there be an "administrator" mode and a (restriced/limited)
"user" mode?

(and finally, my personal favorite...)

I think that a check for a hole that can't be closed shouldn't be a part of
the check, if that hole is widespread.  I have no examples of any such
hole, but a weak spot that can't be closed and has no workaround is one of
the few candidates for the security by secrecy concept.  I have mixed
feelings about this, but if I can't fix the hole, I'd rather not have it's
existence be "public" knowledge.  A freely available routine to locate the
hole would spread it's existence far and wide.....(?) But, if I didn't know
about it beforehand then it would be good to have a tool to tell me it
existed.  Gads, I hate moral conflicts!

   6) When a SSS finds a security flaw in a system, do you want it to
   indicate how they flaw could be used to compromise your system, or
   would you just accept the conclusion and apply a fix?

This question was ill worded and gramatically incorrect, but still managed
to conjure up a lot of comments.  Some thought it was asking if the system
should apply a fix.  In any case, almost 3/4 said Yes, indicate exactly how
to exploit any potential hole.  As usual, there were a few with
reservations about the info getting out, but....

Here are some of the more interesting comments:

                (Think about this one!)
*I* would like to know to futher my knowledge of Unix, but more importantly
to make sure that the version I have was not modified by a cracker to put
security holes *into* a system.  (That'd be sneaky :-)

Security by obfuscation doesn't work.

By definition, a SSS is a software system, and therefore has bugs in it.
If it reported a problem which would cause quite a bit of inconvenience if
fixed, or would be difficult to fix, then I would be much more apt to make
the fix if I knew how the problem could be exploited.  This is important,
because many, if not most, sites require only a moderate level of security,
and many security holes are fiendishly difficult to exploit.

We cannot assume that end-purchasers of a system can be as aware of the
internal workings of a system as the designers of the system (or SSS) are.
If a security flaw is discovered, the administrators need to be informed
about what changes are necessary to remove that flaw, and what
repercussions they may have.

Imagine a SSS that knew sendmail(8) was a security flaw allowing a worm to
enter systems.  It would report that sendmail is a security flaw, please
disable it like....  If the vendor had released a patch, and the SSS didn't
know how it, the administrator (in blind faith to this SSS program) might
disable a *very* useful program unnecessarily.

   7)  Do you think that there is too much, not enough, or just about
   the right amount of concern over computer security?  How about at
   your computer site?  At other sites?

The "not enough"s won, but not by much.  I thought that given the paranoia
of a security group, this would be a larger victory.  Lots of people said
it depends -- on the type of facility, the size, etc. Large sites seem to
have a healthier view of security (paranoia :-)) than
smaller/non-governmental.  Only 4 or 5 said there was enough concern.  A
couple of people mentioned _The Cuckoo's Egg_ as suggested reading (I
heartily agree.)

More quotes:

(I don't know if the next answer is true, but I like it anyway!)

This is really a deep philosophical question---something to talk about over
a few beers at the bar, but not here.

I think it's a site dependent problem, and all the above are true: too
much, too little, and just right. Computer is not a "one size fits all"
situation. Having offered that opinion, I think an assessment of my site or
other sites is extraneous, and I will reserve that opinion.

... more attention to unauthorized use of the networks.

   8)  Do you think that there should be a ruling body that governs
   and enforces rules and regulations of the net -- sort of a net.police?

Some of you wondered what this had to do with software security, but just
about everyone answered anyway.  This one scared me!  The "No's" only beat
out the "yes's" by one vote.  Yikes!  Maybe I'm from the old school of
thought, but....  Several people said that it couldn't be done anyway; a
couple mentioned they a CERT-like agency to help out, but not control, and
finally two said that the laws and government were already there to do
this.

It's there, defacto.  The free market is working pretty well.

Absolutely. I quarrel with the "net.police" designation, per se, of course,
as do many others. But perhaps something more like a recognized trade
association, and providing similar services. Also, it is time that the
basic duties which must be reasonably performed by a site in order for it
to remain on the net should become a requirement rather than a matter of
individual whim.

Yuck!  This is very distasteful to me.  It will probably be necessary
though as more and more people participate in the net.  Enforcement will
have to be judicious until secure networking is developed and implemented
generally.

No.  Aside from the fact that it'd never work, I like Usenet as an anarchy.
It has some rough edges, but for the most part it works.  What does this
question have to do with SSS-type programs?

Enforcement will be tough and may hold back legitimate users.  But we have
to start somewhere.  So I suppose that I agree with having net.police, as
long as they don't turn things into a police.state.net.

   9)  Do you believe that breaking into other people's systems should
   continue to be against the law?

Only one said "no", and s/he had a smiley following the answer.  But there
were some of you who voiced concern that it wasn't really against the law
to begin with.  In _The Cuckoo's Nest_, Cliff Stoll talked about a
(Canadian, I think) case that the only reason the cracker was prosecuted
was for stealing electricity!  Less than a watt or something.  A few of you
mentioned denial of services as being a just reason, but what if they break
in only at night, when no one else is on, and they really don't take
anything at all?  Should that be less punishable than someone who sucks
away user CPU/disk/whatever?

Breakins should be encouraged and rewarded (1/2 :-).

Yes.  Unquestionably.  However, those laws should not attempt to regulate
inter-system traffic to cause these things to happen.

Yes - and as a felony in all cases, without exception.

Yes but murder, rape, robbery... are more important and laws and sentencing
should reflect this. There are some around who want to treat cracking as a
capital crime!

Yes, from the denial of services standpoint.  I pay $XXX,XXX.XX for a
system, and joe blow slides in and sucks away at those resources, there
should be a nontrivial penalty for getting caught.  Don't behead the guy,
but monetary fines or community service would be just fine.

I don't know.  I'm not a philosopher.  Certainly causing damage to others
is wrong, including denial of service, compromising sensitive info, or
whatever.  I'm concerned though that clamping down on young kids will
discourage them from becoming computer geeks.  I think we need to encourage
our young people to become technically literate.  If we don't become a more
expert society we can kiss it goodbye; all we'll have left is our military
solutions, like some brainless jock bully...

I'm not sure that it is everywhere - but: Yes.  Should attempting to break
in be against the law: No.  Is this vague: Yes.

I did not know that it was. The laws about it have not been tested and are
vague and unclear. You need to be very clear about what the laws are going
to do.

**HELL FUCKING YES** Those of us who started in UNIX years ago have for the
most part *always* respected others!! This I can't stress strong enough.

  10)  Is your site academic, government, or commercial in nature?

Just over 1/2 of those that answered claimed university ties, with about
1/4 being commercial, 1/6 government, a few research sites, and a couple
that were a mixture.  Sites included Sun, AT&T, SCO (Xenix), the DoD, and
the Army, among others.

(Guess where this one came from :-)

Research.  We invented Unix.

Academic with commercial applications.

Primarily academic, but we are part of the government.

Academic, except when collecting student fees *) *)

********************************************************************
                           >> END OF THIS FILE <<
***************************************************************************