HDTenEightyP/NetNews huggingface dataset:
From: imp@solbourne.com (Warner Losh)
Subject: Re: passwd security check
Organization: Solbourne, User Interface Group
Date: Wed, 22 Jul 1992 21:45:53 GMT

In article <14kib3INN18l@moe.ksu.ksu.edu> rjq@phys.ksu.edu (Rob Quinn) writes:
>In <Brt2n3.GE9@solbourne.com> imp@solbourne.com (Warner Losh) writes:
>]In article <1992Jul22.190827.30077@iitmax.iit.edu> technews@iitmax.iit.edu (Kevin Kadow) writes:
>]>when 2 or more accounts have the same password, and other "holes" that would
>]>not be found by crack?
>]This is *NOT* a security hole.
> It can be an indication that one person is using two or more accounts, which
>could be a security issue for some systems.

As long as it is *NOT* disclosed to the two accounts that have the
same person, then I might agree with you.  However, it is quite
possible that two people indepently chose batman! (or r0bin!) as their
password after seeing the same movie.  I'm still not convinced that
this is a real hole....

Warner
-- 
Warner Losh		imp@Solbourne.COM
Interview Horror Story #882: "It's pretty informal around here.
Thursdays are clothing optional.."
Xref: sparky alt.security:3969 rec.arts.movies:22861
From: stoll@ocf.berkeley.edu (Cliff Stoll)
Newsgroups: alt.security,rec.arts.movies
Subject: Re: Cuckoo's Egg (Was: Re: Sneakers (Upcoming movie about "hackers"))
Keywords: Cuckoo's Egg, security, PBS
Date: 22 Jul 92 00:24:40 GMT
Organization: U. C. Berkeley Open Computing Facility
NNTP-Posting-Host: headcrash.berkeley.edu

Linda Snow writes:

>>Actually, it was made into a PBS show.  I think it may have been
>>an episode of Nova.  The author of the book (whose name completely
>>escapes me now) 'starred' in this re-creation of the book.

>His name is Cliff Stoll.
>He used to pop up on the net from time to time.
>In fact, his e-mail address is listed in the book.


Zooks!  I still do pop up on the net, when not answering e-mail.
Newsgroups: alt.security
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Thu, 23 Jul 1992 13:42:49 GMT

Casper H.S. Dik writes:
>
>BUGID: 1095935 
>	NFS server in which a client presenting a 32-bit uid in which 
>	the 16 low-order bits are 0 gets interpreted as root on the server.

Are there any operating systems available that present a 32 bit uid?

Brian
Xref: sparky alt.security:4028 sci.crypt:2757
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: alt.security,sci.crypt
Subject: Re: passwd security check
Date: 28 Jul 92 12:16:04 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: Tin 1.1 PL3

adam@gomez.intel.com (Adam Margulies ~) writes:
: DES has a theorectical weakness in that for any key there are exactly
: 7 other keys that will crypt to the same string. I.E. if your password
: is "batman!" there exist seven other keys which are not "batman!" that
: will allow access to your account. Fortunately they are almost
: certainly extremely strange strings like "@gW #s(u", and not likely to
: match a human generated password.

Not really.  DES only uses 7 bits out of each byte of its key, but if
we're assuming that the key is ASCII, there only are seven bits.  DES
assumes keys have odd parity.  So its key length is 56 bits, all of
which it uses for encryption.

: Another interesting thing about DES is that there are 8 keys that
: crypt to a string of all spaces and there are even keys that when
: encrypted reproduce themselves in the crypted output. Weird.

There are weak keys (e.g. 01 01 01 01 01 01 01 01) which do no real
scrambling at all, and some semi weak keys which do very little.  In
fact, these keys are very useful for testing DES implementations.
You'd have to be pretty determined to get these into an ASCII
terminal, though.

Andrew.
Newsgroups: alt.security
From: tencati@nssdca.gsfc.nasa.gov (NSI Security Manager +1-202-434-4541)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
News-Software: VAX/VMS VNEWS 1.41    
Organization: NASA - Goddard Space Flight Center
Date: Fri, 24 Jul 1992 15:49:00 GMT

In article <1992Jul23.113003.24332@jarvis.csri.toronto.edu>, flaps@dgp.toronto.edu (Alan J Rosenthal) writes...

>Ok, but I'm still wondering how important the patch is.  The CERT advisory said
>something fairly nasty, like "everyone can become root".  Does this apply to
>the *differences* between the new patch and the old patch?  Like, if a site I
>know (which for obvious reasons shall remain nameless, but it isn't at dgp) has
>installed the old jumbo patch but doesn't install the new one, can "everyone
>become root" or whatever the advisory said?
> 
  CERT wrote their bulletin based on an alert that Sun released. CERT 
  is merely relaying that information to you. The vendor is being 
  responsive and responsible. There are bugs in some of their old 
  patches, and there are some new patches available, all of which fix
  holes that could let an intruder into your system with root priviliges.

  CERT, and other FIRST members, are merely doing a public service by
  alerting the user community to something that the vendor felt was
  serious enough to warrant the release of an alert. Decide for yourself
  how important these patches are. 


Ron Tencati
Security Manager
NASA Science Internet

------------------------------------------------------------------------------
NASA Science Internet (TCP/IP & DECnet)| NSI/IP: Tencati@Nssdca.Gsfc.Nasa.Gov
Security and Incident Response Office  | NSI/SPAN: NCF::TENCATI/15548::TENCATI
Suite 950                              | Tele - +1-202-434-4541
700 Thirteenth St., NW                 | FAX  - +1-202-434-4599
Washington, D.C. 20005; USA            | Beeper +1-800-759-7243, Pin:5460866
------------------------------------------------------------------------------

Newsgroups: alt.security
From: marka@syd.dms.CSIRO.AU (Mark Andrews)
Subject: Re: passwd security check
Organization: CSIRO Division of Mathematics and Statistics, Australia
Date: Tue, 28 Jul 1992 07:37:33 GMT

In article <25980.Jul2801.49.4992@virtualnews.nyu.edu> brnstnd@nyu.edu (Dan Bernstein) writes:
>In article <1992Jul27.205704.14049@random.ccs.northeastern.edu> rogue@ccs.northeastern.edu (Rogue Agent) writes:
>  [ if he chooses the same password as someone else ]
>> No, tell me
>> it's not acceptable - but don't tell me why (in this case).
>
>Bad idea! The system should not perform this check, period.
>
>---Dan

No.
	It should do this check then recrypt with a different salt.
	It should keep doing this until it runs out of salts or it
	manages not to get a match.

	If it can't find a valid salt it should issue a security alert
	and close all effected accounts, be carful not to close root's
	:-), as this password is comprimised. 4096 people have chosen it
	as there password so it must be guessable.

	( You could apply the above with less clashes. If you get 05
	matches I would think the password chosen would be to guessable
	)

	Mark.
From: mboening.pad@sni.de (Martin Boening)
Newsgroups: alt.security
Subject: Re: passwd security check
Date: 30 Jul 92 09:11:48 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <Brt8GH.Guz@solbourne.com> imp@solbourne.com (Warner Losh) writes:

[ stuff deleted ]

>same person, then I might agree with you.  However, it is quite
>possible that two people indepently chose batman! (or r0bin!) as their
>password after seeing the same movie.  I'm still not convinced that
>this is a real hole....

Even if two people choose the same password, the chances are small that
both will have the same encrypted password in their passwd file. This is
because each encrypted password consists of 2 letters salt and the rest
is the real encryption for the password entered. The salt is calculated
in abstruse ways from process ids of passwd processes, times, and I know
not what random factors. It will be different for most invocations of
passwd, therefore the encrypted version of the password will be
different.

Conclusion: if you do find the same encrypted version of a password for
two or more entries in a /etc/passwd file, chances are that the password
was copied in from the first to the second entry. This can happen when a
lazy sys admin simply copies one user entry to another and then changes
the fields that need changing.

It should never occur if new accounts are generated using some sysadmsh
like interface.

So long,
Martin
--
Email: in the   USA ->  mboening.pad@sni-usa.com
       outside  USA ->  mboening.pad@sni.de
Paper Mail: Martin Boening, Siemens Nixdorf Informationssys. AG, SNI STO SI 325,
	    Pontanusstr. 55, 4790 Paderborn, W.-Germany  (Phone: +49 5251 835641)
From: dela@ee.rochester.edu (Del Armstrong)
Newsgroups: alt.security
Subject: Request for pointers on Internet Gateways
Keywords: gateway firewall
Date: 31 Jul 92 19:47:01 GMT
Reply-To: dela@ee.rochester.edu (Del Armstrong)
Organization: University of Rochester - Dept of Electrical Engineering

I'm trying to find out more about how to setup an Internet gateway.

I've got Cheswick's paper, are there other good references that
someone can point me at? Are there any commercial products that
provide some or all of the functionality of a Internet Gateway?

Any pointers or references would be greatly appreciated!

	
	Del Armstrong	

	Systems & Networking Staff - Dept of EE and ME
	University of Rochester, Rochester, NY
	Internet: 	dela@ee.rochester.edu
	UUCP:		...!rochester!ur-valhalla!dela

"If God had meant for us to use computers, (s)he would 	have given us
only two fingers to count with."
Newsgroups: alt.security
From: ddean@sapphire.risc.uni-linz.ac.at (Drew Dean)
Subject: Re: Phantom Access - EFF
Keywords: EFF does some things quietly
Reply-To: ddean@risc.uni-linz.ac.at
Organization: Wirtschaftsuniversitaet Wien
Date: Thu, 30 Jul 1992 20:17:42 GMT

In article <tbcm85=.blain@netcom.com> blain@netcom.com (Blain Strickel)  
writes:
> 186 people == did not ==
> approve of Mike Godwin's handling of situations where he deals with  
people,
> those that justified their feelings said he takes "everything to the  
level
> of lawyer sleaze, he won't just talk"  On the other side, the remaining  
95
> people felt == very == positive about Mr. Godwin.  

> Blain  | Yes my parents really did name me Blain
> Spins  | No, it doesn't end with an "e" maybe it
> NialB  | should, but why mess with fate!

Mr. Goodwin's job sometimes _requires_ confidentiality -- he certainly  
aided me in a quiet way in an incident in which publicity would have been  
ruinous to me.  We _need_ him; we need the EFF.  I don't necessarily agree  
with every position that Kapor takes, but we need a reasonable voice in  
the wilderness to help guide the public through cyberspace.  Hackers (not  
crackers, but real hackers) have a place exploring the frontiers, and they  
will always find things that certain corporations and/or governments would  
rather they not find.  But it's awful hard for an individual to stand up  
against the US Govt, IBM, AT&T, DEC, HP, or even Sun.  It's also hard for  
an individual to help make the government form rational cyberspace  
policies in the first place.  Neither extreme is correct, but hackers need  
some representation to make sure the results end up somewhere in the  
middle.

Drew Dean
ddean@risc.uni-linz.ac.at
Needless to say, I don't speak for RISC.
From: smith@sctc.com (Rick Smith)
Newsgroups: alt.security
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Date: 24 Jul 92 19:24:41 GMT
Organization: SCTC

casper@fwi.uva.nl (Casper H.S. Dik) writes:

>Secure NFS is the only solution in environments were clients can't be
>trusted.

Does anyone have experience with Secure NFS? Does it have any interesting
or unusual warts? Is it five times slower? Fifty times? Am I being
optimistic?

Rick.
smith@sctc.com          arden hills, minnesota
Newsgroups: alt.security
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Organization: FWI, University of Amsterdam
Date: Wed, 22 Jul 1992 21:23:29 GMT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>In comp.security.announce, cert-advisory-request@CERT.ORG (CERT Advisory) writes:
>    >CA-92:15                        CERT Advisory
>    >                                July 21, 1992
>    >                    Multiple SunOS Vulnerabilities Patched
>    >--------------------------------------------------------------------------

>    >NFS jumbo patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures

>What's new with THIS jumbo patch?  Is it the same jumbo patch?

From the README: (several fixes, but this is one that's security related)

BUGID: 1095935 
	NFS server in which a client presenting a 32-bit uid in which 
	the 16 low-order bits are 0 gets interpreted as root on the server.

>    >ICMP redirects patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures
>    ...
>    >     allows an intruder to close existing network connections to and from
>				^^^^^
>    ...
>    >II.  Impact
>    >     A remote user may deny network services on a Sun system.
>			    ^^^^

>So which is it, can they close existing ones or only deny new ones?

It's pretty much the same thing. Breaking of connections should
already be considered ``denial of service''. If you bomb a
sun with certain packets, it will reset TCP connections
all the time. It is not the case that you can send one packet (or a few)
to cripple a Sun (or another machine running similar networking code).

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
From: brnstnd@nyu.edu (Dan Bernstein)
Newsgroups: alt.security
Subject: Re: passwd security check
Date: 28 Jul 92 01:49:49 GMT
Organization: IR

In article <1992Jul27.205704.14049@random.ccs.northeastern.edu> rogue@ccs.northeastern.edu (Rogue Agent) writes:
  [ if he chooses the same password as someone else ]
> No, tell me
> it's not acceptable - but don't tell me why (in this case).

Bad idea! The system should not perform this check, period.

---Dan
Xref: sparky alt.security:4053 comp.security.misc:872 news.answers:2308
From: imp@solbourne.com (Warner Losh)
Subject: Re: passwd security check
Organization: Solbourne, User Interface Group
Date: Wed, 22 Jul 1992 19:40:14 GMT

In article <1992Jul22.190827.30077@iitmax.iit.edu> technews@iitmax.iit.edu (Kevin Kadow) writes:
>when 2 or more accounts have the same password, and other "holes" that would
>not be found by crack?

This is *NOT* a security hole.  However, informing both parties that
they have the same password would be.  Think about it....

Warner
-- 
Warner Losh		imp@Solbourne.COM
Interview Horror Story #882: "It's pretty informal around here.
Thursdays are clothing optional.."
Xref: sparky alt.security:3967 rec.arts.movies:22858
From: lsnow@ncrclm.ClemsonSC.NCR.COM (Linda Snow)
Newsgroups: alt.security,rec.arts.movies
Subject: Re: Cuckoo's Egg (Was: Re: Sneakers (Upcoming movie about "hackers"))
Keywords: Cuckoo's Egg, security, PBS
Date: 20 Jul 92 18:53:20 GMT
Reply-To: lsnow@ncrclm.ClemsonSC.NCR.COM (Linda Snow)
Organization: NCR E&M CLEMSON Liberty, SC

>
>Actually, it was made into a PBS show.  I think it may have been
>an episode of Nova.  The author of the book (whose name completely
>escapes me now) 'starred' in this re-creation of the book.

His name is Cliff Stoll.
He used to pop up on the net from time to time.
In fact, his e-mail address is listed in the book.
.
.
.
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: alt.security
Subject: Re: passwd security check
Date: 31 Jul 92 12:55:14 GMT
Organization: IR

In article <Bs396M.6wp@syd.dms.CSIRO.AU> marka@syd.dms.CSIRO.AU (Mark Andrews) writes:
> 	It should do this check then recrypt with a different salt.
> 	It should keep doing this until it runs out of salts or it
> 	manages not to get a match.

Again, bad idea! The passwd program should never look at any other
user's password for any reason. You could switch to a system where
passwords are encrypted together with the hostname and username; this is
the second most effective measure you can take to stop people from
attacking your password file.

---Dan
Newsgroups: alt.security
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Date: 23 Jul 92 15:30:03 GMT

lemson@ux1.cso.uiuc.edu (David Lemson) writes:
>We called Sun today and they said that this Jumbo patch supersedes
>the old Jumbo patch, even though the readme file doesn't say that.
>They said to install it even if you have done the old Jumbo patch.

Ok, but I'm still wondering how important the patch is.  The CERT advisory said
something fairly nasty, like "everyone can become root".  Does this apply to
the *differences* between the new patch and the old patch?  Like, if a site I
know (which for obvious reasons shall remain nameless, but it isn't at dgp) has
installed the old jumbo patch but doesn't install the new one, can "everyone
become root" or whatever the advisory said?

Someone else was wondering why I would care about the difference between
closing existing connections and denying new ones.  The answer is that I take
the closing-existing-connections problem more seriously (and it's sort of
almost nearly a superset of the other problem anyway).  If my telnet connection
to a machine of ours suddenly closes, I'd reconnect and if it connected ok I'd
think little of it, which would be bad.  However, if I got a connection denied,
I'd go out of my office across the lab and login on the console and see what
was up and remember the CERT advisory.  So I think of the ability to close
existing connections as more insidious because it's more subtle.  I know that
this isn't exactly really true, but in a practical way it might be.
From: rogue@ccs.northeastern.edu (Rogue Agent)
Newsgroups: alt.security
Subject: Re: passwd security check
Date: 27 Jul 92 20:57:04 GMT
Organization: Comp. Sci. @ NU

In article <1992Jul25.001141.10256@news.cs.indiana.edu> 
mvanheyn@whale.cs.indiana.edu writes:
>
>Of course, it would be easy to do it with a fascist passwd program.
>Just have it check the given password against all the ones in the file,
>and if it matches, it prints a message saying "Sorry, that is the same
>as the password for user flaps."  That way, people wouldn't use the same
>passwords, and security would be increased.

	Now _there's_ a bright idea.  If I should change my passwd, and
my choice happens to be the same as some other user, tell me the guy's
name, so I can go right out and 'rm -r *' all over his acct.  No, tell me
it's not acceptable - but don't tell me why (in this case).

	RA
Newsgroups: alt.security
From: lemson@ux1.cso.uiuc.edu (David Lemson)
Subject: Re: CERT ADVISORY - Multiple SunOS Vulnerabilities
Organization: University of Illinois at Urbana
Date: Thu, 23 Jul 1992 03:01:57 GMT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>In comp.security.announce, cert-advisory-request@CERT.ORG (CERT Advisory) writes:
>    >CA-92:15                        CERT Advisory
>    >                                July 21, 1992
>    >                    Multiple SunOS Vulnerabilities Patched
>    >--------------------------------------------------------------------------

>    >NFS jumbo patch upgrade, SunOS 4.1, 4.1.1, 4.1.2, all architectures

>What's new with THIS jumbo patch?  Is it the same jumbo patch?

We called Sun today and they said that this Jumbo patch supersedes
the old Jumbo patch, even though the readme file doesn't say that.
They said to install it even if you have done the old Jumbo patch.
-- 
David Lemson                                                 (217) 244-1205
University of Illinois NeXT Campus Consultant  / CCSO NeXT Lab System Admin
Internet : lemson@uiuc.edu                 UUCP :...!uiucuxc!uiucux1!lemson 
NeXTMail accepted                                   BITNET : LEMSON@UIUCVMD
Newsgroups: alt.security
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: passwd security check
Organization: FWI, University of Amsterdam
Date: Fri, 24 Jul 1992 07:41:14 GMT

adam@gomez.intel.com (Adam Margulies ~) writes:

>In article <14mgkaINN1uq@moe.ksu.ksu.edu> rjq@phys.ksu.edu (Rob Quinn) writes:
>>In <1992Jul23.092715.1@zodiac.rutgers.edu> leichter@zodiac.rutgers.edu writes:
>>]One thing it's important to remember is that there are many passwords that
>>]hash to the same value.  Even if you and I have the same salt and the same
>>]hash value, it doesn't mean we chose the same password - though it DOES mean
>>]that either of our passwords will work on either account.
>>
>> Can you provide an example? Or is there some mathematical proof? This question
>>has come up a lot before, and there have been answers on both sides, but no
>>proof either way that I have seen.

>DES has a theorectical weakness in that for any key there are exactly 7 other keys that will
>crypt to the same string. I.E. if your password is "batman!" there exist seven other keys which
>are not "batman!" that will allow access to your account. Fortunately they are almost certainly
>extremely strange strings like "@gW #s(u", and not likely to match a human generated password.

What's true of DES isn't necessarily true of crypt(3).
Remember that crypt runs (modified) DES 25 times and that your password is
used as the key. After the first encryption the eight keys will have encrypted
to the same value. But the resulting encrypted string is encrypted again, 
resulting in 8 different values. I think that it is pretty much an open
question whether there are password/salt combinations that yield the
same encryption string. For this property to be applicable to crypt(3)
you must have a 0 (..) salt and 2 of the 8 keys must be self-decoding.

>Another interesting thing about DES is that there are 8 keys that crypt to a string of
>all spaces and there are even keys that when encrypted reproduce themselves in the
>crypted output. Weird.

Crypt what to all spaces? The standard crypt(3) cleartext?

And try to keep your lines 80 columns.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
Xref: sparky alt.security:4029 rec.arts.movies:23403
From: olson@dstl86.gsfc.nasa.gov (Paul Olson)
Newsgroups: alt.security,rec.arts.movies
Subject: Re: Cuckoo's Egg (Was: Re: Sneakers (Upcoming movie about "hackers"))
Keywords: Cuckoo's Egg, security, PBS
Date: 28 Jul 92 13:12:00 GMT
Distribution: usa
Organization: Mission Operations and Data Systems
News-Software: VAX/VMS VNEWS 1.41

In article <14se7gINNkr9@wupost.wustl.edu>, bryan@wupost.wustl.edu (bryan o'connor) writes...
>>>I think Cliff should play Cliff.
>>nah - it's been done.  
> 
>I think that he should play one of the suits/spooks/etc. Imagine, if you will,
>Cliff in a suit, tie, and dark glasses; and a stuffy suit type with jeans,
>wrinkled shirt, long hair wig, and yoyo.:
>[stuff deleted]
>--bryan

I think Cliff should play Christopher Lloyd in, "The Making of Cuckoo's Egg -
The Movie Movie"! 8^D

+--------+-------------------------------------------------------------+
|      __| Paul J. Olson - VAX Systems Manager & Resident Amiga Addict |
| C=  ///| Voice -     301/286-4246, 301725-5501                       |
|__  /// | DECnet-    DSTL86::OLSON                                    |
|\\\///  | Internet - olson@dstl86.gsfc.nasa.gov                       |
| \XX/   | Disclaimer: Statements in my messages are wholely my own.   |
| AMIGA  | "[the universe originated] as a quantum fluctuation         |
| RULES! |  of absolutely nothing." - Guth & Steinhardt                |    
+--------+-------------------------------------------------------------+