Tech Insider					     Technology and Trends


			      USENET Archives

Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!hc!pprg.unm.edu!kurt
From: k...@pprg.unm.edu (Kurt Zeilenga)
Newsgroups: comp.unix.wizards
Subject: UNIX security and passwords
Message-ID: <23731@pprg.unm.edu>
Date: 3 Jan 89 19:12:43 GMT
Reply-To: k...@pprg.unm.edu (Kurt Zeilenga)
Organization: U. of New Mexico, Albuquerque
Lines: 47

I've been following this discussion with some amazement.  I've
been managing computers for about eight years and have seen
hundreds of security incidents first hand.  Of them, I can
only remember one or two that actually tried to use a program
to guess passwords.  Hell, if I was going to break into a
computer I sure would waste my time trying to crack passwords.
Here is my list of methods I would try first:

	Open doors left my system admins
		blank or hosed lines in password files 
		write premissions
			/,/etc
			/etc/passwd
			/etc/group
			/bin/su
			dotfiles in / or sys admins home
		existance of a .rhosts/.netrc in / or sys admin home
		existance of /etc/hosts.equiv
		readable devices
		SUID programs (often breakable)
		Known passwords (note: these are not guessed)
		
	Trojan Horses
		fake getty's, etc.

	Insecure protocols, network agents
		RPC
		NFS
		UUCP
		FTP, SENDMAIL, FINGER
		X or NeWS

	Insecure network media
		Cleartext password grabbing (even more effective
			if you know how to abuse ARP and ICMP)

(I am sure I missed many ways, these were just off the top of my head).

So, I kind of agree with Barry.  P(crack password) * P(crack shadowfile)
is very close to P(crack password).  However, I much rather see all
this effort going into solving some of the basic issues.  Anyways, I
am glad to see security becoming a real issue.  

Until we educate our SYSTEM ADMINS what the hell is the point of
educating our USERS!

	- Kurt

Path: utzoo!attcan!uunet!lll-winken!ames!pasteur!agate!bionet!
csd4.milw.wisc.edu!mailrus!purdue!bu-cs!mirror!ima!minya!jc
From: j...@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: UNIX security and passwords
Message-ID: <14@minya.UUCP>
Date: 16 Jan 89 13:06:49 GMT
References: <23731@pprg.unm.edu>
Organization: (none)
Lines: 42

In article <23...@pprg.unm.edu>, k...@pprg.unm.edu (Kurt Zeilenga) writes:

> Until we educate our SYSTEM ADMINS what the hell is the point of
> educating our USERS!

Once again, it is pertinent to point out that we haven't been failing
to educate our system admins; rather we have been intentionally keeping
them ignorant.

Over and over, people say "If I tell the world about this security
problem I just found, then all the Evil Hackers will read it and
attack your systems, so I won't tell you."  The effect is to keep
the problems secret from system admins and software developers, so
they never learn how to protect themselves.

I've written lots of code, some of which may be incorporated into the
system you're now using.  I'm sure that I've built in lots of security
problems, out of ignorance.  As long as you turkeys keep me ignorant,
I will continue to do this.  Security problems are often subtle, and
it is totally unreasonable of you to expect me to figure them out all
by myself.  If I am to build better code, you have to tell me where
the problems are.

I've also been system admin for lots of machines, and exactly the same
argument applies.  For a simple example, I've demonstrated for lots of
other Unix administrators why they shouldn't have a blank line in their
/etc/passwd file.  Why the #@$^% aren't problems like this clearly and
readably documented in the manuals that come with Unix systems?  I don't
mean just a vague, unspecific warning that /etc/passwd shouldn't contain
blank lines.  That would pass right by almost everyone.  There should be
an explicit example showing how to exploit this bug.

True, many system admins would still not protect their systems.  Sometimes
it's not a concern.  (After all, look at all the MS/DOS systems out there,
despite its total lack of security.  :-)  But many would, if only someone
would warn them of the problems.

-- 
John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]

Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!mailrus!tut.cis.ohio-state.edu!
rutgers!bellcore!texbell!killer!rpp386!jfh
From: j...@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: UNIX security and passwords
Summary: All the world is not connected to USENET
Message-ID: <11215@rpp386.Dallas.TX.US>
Date: 17 Jan 89 23:55:05 GMT
References: <23731@pprg.unm.edu> <14@minya.UUCP>
Reply-To: j...@rpp386.Dallas.TX.US (John F. Haugh II)
Organization: River Parishes Programming, Dallas TX
Lines: 18

In article <1...@minya.UUCP> j...@minya.UUCP (John Chambers) writes:
>                                                         There should be
>an explicit example showing how to exploit this bug.

NO!  Not until the FIX has had a chance to work its way out to the
masses.

Too many systems are sitting out there with assinine vendors not
supplying bug-fixed software to their customers to let loose a real
security killer on the unsuspecting masses.

Post the fix, wait several months, then post a complete write-up.
Anything less is irresponsible.
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"UNIX doesn't have bugs,
InterNet: j...@rpp386.Dallas.TX.US       |         UNIX is a bug."
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/