HDTenEightyP/NetNews huggingface dataset:
From: spaf@cs.purdue.EDU (Gene Spafford)
Subject: Re: Tripwire release
Organization: Department of Computer Sciences, Purdue University
	<1992Nov06.173036.28994@watson.ibm.com>
	<BxMEuE.CwC@mentor.cc.purdue.edu>
	<1992Nov13.004708.26881@cs.sandia.gov>
Date: Sun, 15 Nov 1992 18:56:16 GMT

In article <1992Nov13.004708.26881@cs.sandia.gov> mccurley@cs.sandia.gov (Kevin McCurley) writes:

   From: mccurley@cs.sandia.gov (Kevin McCurley)
   Newsgroups: comp.security.misc,alt.security,comp.unix.admin
   Date: 13 Nov 92 00:47:08 GMT

   I stated earlier that NONE of these, including MD5, Snefru, and MD4,
   are signatures in the cryptographic sense.  A true signature would
   require something like RSA or DSA layered on a one-way hash function
   like MD5 or SHA.

We have seen the word "signature" used in different ways in the
literature and the general user community.  Our use of the word in the
Tripwire documentation was in the sense of other uses we had seen.
Perhaps we should put little quote marks around the word, or put a
footnote that some people have a more restrictive definition of
signature than what we used....

The basic point made by GeneK was that the program has a
simple-extension feature to include whatever other algorithm you wish.
For instance, if you wish to apply DES in CBC mode, and save the last
64 or 128 bits as a signature, you can (and it doesn't need to be
layered on top of anything else to work).  Or encode using your
favorite RSA key before running the CRC...whatever method you choose.

Is anyone using Tripwire, or is the only traffic about the terminology
used in the README file? :-)
Newsgroups: comp.security.misc
From: jlaiho@ichaos.nullnet.fi (Juha Laiho)
Subject: Re: Anti-Piracy by Serial Number ?
Organization: NullNet r.y.
Date: Wed, 4 Nov 1992 19:55:27 GMT

In article <1992Nov4.111537.1806@rz.uni-karlsruhe.de> S_TITZ@iravcl.ira.uka.de (Olaf Titz) writes:
>Copy protection is generally a complicated thing, and many people
>argue that a complete protection cannot be achieved. And many think
>that forcing the users to use dongles or keydisks is a Bad Thing.
>
And the keydisk/dongle code can be dug out from the program binary and altered
or removed. I am one of those who think that any human-made copyprotection
CAN BE broken by another human. The case is just whether or not breaking
the copy protection is "worth the job".

Look for example at AutoCad. At least the versions officially sold in Finland
are protected with some hardware kludge that plugs into the parallel port.
I've heard about "versions" of AutoCad from which the code related to the
parallel port "kludge" has been removed. As AutoCad is very expensive program,
and a program of very good quality, this definitely has been worth of the job.

I think if a program that costs just some USD 30 had some parallel port
protection, it would not be cracked. The same holds true (I think) for programs
of inferior quality.

..Wolf

PS. Flames about supporting piracy to /dev/null. These were just my thoughts.
Newsgroups: comp.security.misc
From: craig@jido.b30.ingr.com (Craig Presson)
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Reply-To: craig@jido.b30.ingr.com
Organization: Intergraph Corporation, Huntsville, Alabama
Date: Thu, 12 Nov 1992 22:06:10 GMT

In article <6pq1n6h@rpi.edu> fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
[...]
   >	A complaint filed in federal court charges that Anderrson and
   >Katsaniotis gained access to the District Court computer by using a home
   >computer to scan for telephone modem numbers. Modems are used to send
   >data from one computer to another over telephone lines. 
   >	``Once the system was accessed, Anderson copied the file containing
   >the passwords controlling access to the computer system,'' an affidavit
   >filed with the charges stated. ``He then transferred the password file
   >to a Boeing Company computer, where he decrypted the passwords.''
   >	That process gave Anderson the ``root'' password, which allowed him
   >to have unrestricted access to the computer system at the courthouse,
   >the affidavit said. Once inside, it said, ``the hackers were able to
   >view numerous confidential records, including some grand jury material.''
[...]
   >	``Intrusion was limited due to effective security systems being in
   >place, and no government-classified systems were entered,'' Boeing said.
[...]
If the attack was exactly what this story says, then "effective
security systems" is quite the preposterous claim. Hopefully, there's
a bit more to it.

-- Craig Presson

Newsgroups: comp.security.misc
From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
Subject: Re: Encryption in a routed network?
Reply-To: cmaae47@imperial.ac.uk
Organization: Imperial College of Science, Technology and Medicine
Date: Thu, 5 Nov 92 15:36:08 GMT

In article <1992Nov4.092951.49@ntet.nctr.fda.gov>, rbowen@ntet.nctr.fda.gov writes:
- Are there any encryption devices that would allow the passing of 
- encrypted traffic across a routed network? I have seen devices such
- as DEC's DECSNC, but it only will work in a bridged environment, not
- a routed one.

Which means it is an inept implementation. Encryption should be done at
presentation level, after normalization and compression.

If you want to avoid listeners at network or data link layers to analyse 
your traffic patterns you could make sure that you connect over several
networks and hope your receiver dos so as well, and will consolidate the
messages.

For more info on layered communications, see A. S. Tanenbaum, 
Computer Networks, Prentice Hall.

                                  Thomas
-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
From: bsy+@CS.CMU.EDU (Bennet Yee)
Newsgroups: comp.security.misc
Subject: Debugging login (Re: Forging E-mail from root to get users to change passwords)
Date: 7 Nov 92 17:41:28 GMT
Article-I.D.: cs.BxCx55.L5J.2
Reply-To: bsy+@cs.cmu.edu
Organization: Cranberry Melon, School of Cucumber Science

In article <id.Z9RU.L6K@ferranti.com>, peter@ferranti.com (peter da silva) writes:
>In article <ratner.720811773@ficus.cs.ucla.edu> ratner@ficus.cs.ucla.edu (Dave "Van Damme" Ratner) writes:
>> Yes, it is true that root never needs to know a user's password ---
>> root can always su to the user without knowing the password.
>
>Not if root is trying to debug a problem in login or rlogin where the user's
>password is entered. I had one case where a user's password included a pound
>sign... which worked fine on the Suns but he couldn't login on Xenix for some
>reason.

The reason is that on some systems, the default erase/kill characters
are #/@ which is behavior left over from the days when Unix had real
teletypes as terminals.  Not a bug in login at all -- the tty driver
just had different defaults.

-bsy

-- 
Bennet S. Yee		Phone: +1 412 268-7571		Email: bsy+@cs.cmu.edu
School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890
From: faigin@aero.org (Daniel P. Faigin)
Newsgroups: comp.security.misc
Subject: Re: Computer security books
Date: 12 Nov 92 08:06:31
Organization: The Aerospace Corporation, El Segundo, CA
NNTP-Posting-Host: soldan.aero.org
In-reply-to: ifbb657@ccwf.cc.utexas.edu's message of 12 Nov 92 03:10:20 GMT

On 12 Nov 92 03:10:20 GMT, ifbb657@ccwf.cc.utexas.edu (Douglas Floyd) said:

There are a number of good books out there. Looking at my shelf I see...

Computer Security Basics, by Deborah Russell. O'Reilly Press

Computer Security, by John Carroll

Building a Secure Computer System, by Morrie Gasser

You might try looking at these.

Daniel
--
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
		    "And as they say, the rest is compost"
From: 873nikorawal@gw.wmich.edu
Newsgroups: comp.security.misc
Subject: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Date: 10 Nov 92 20:15:03 EST
Organization: Western Michigan University

  What I do not understand is that how a user can send mail to a different user
on the same system, and make it appear as though it has been sent by the
operator or any other user on the system. Unless Of-course he has access to the
operator/other persons account !!!!!

							Curiocity !!!!!!

Newsgroups: comp.security.misc
From: jns@ace.nas.nasa.gov (John N. Stewart)
Subject: Re: Setuid file
Organization: NAS, NASA Ames Research Center, Moffett Field, California
Date: Mon, 9 Nov 92 18:33:58 GMT


In article <1d9ggiINNsfb@sequoia.ccsd.uts.EDU.AU> mgream@acacia (Matthew Gream) writes:
>Robert Earl (chupchup@ferkel.ucsb.edu) wrote:
>: 
>: |    Found this on one of our systems.  Anyone know if there is any way
>: |    this could be used to obtain root access?
>: |    -rwsr-xr-x  1 root            0 Apr  7  1992 file
>: 
>: | Yes, most of the holes that work for setuid-shell scripts will work
>: | for this file, even though it is empty.

>No one yet asked what OS this was, HP-UX doesnt clear the setuid-bit on
>an append (at least It didnt in one of its installed versions ive seen),
>so appending a shell script to make a setuid shell is a trivial job.
>
>Correct me if im wrong.


Not wrong -- SGI's don't do it either (e.g. the files setuid-bit is
left alone). The only addition to this is that this file can only be
appended to by root -- and if the whole point is to get root through
this method -- well, it seems to be a catch-22.

There is a simple logic -- anything that is setuid has a potential --
it's intuitive. Sure, an empty file may not seem bad -- but there are
potential risks.

My $0.02 worth ...

--Ace



John Stewart (Ace)
CSS/DSS/Security/Postmaster/NewsAdmin
NASA Ames Research Center
(415) 604-4345
From: ifbb657@ccwf.cc.utexas.edu (Douglas Floyd)
Newsgroups: comp.security.misc
Subject: Grabbing your pw file from anonymous FTP
Date: 10 Nov 92 20:56:04 GMT
Reply-To: ifbb657@ccwf.cc.utexas.edu (Douglas Floyd)
Organization: The University of Texas at Austin, Austin TX
Originator: ifbb657@donald.cc.utexas.edu


  What keeps any person who can anonymous ftp from going down your
etc directory and grabbing the passwd file?  Does ftp log this?  I
know that some Unix systems use a chroot system to lock anonymous
ftp users into a restricted section of the directory.  Do all
ftp systems do this?

adTHANKSvance,

-- 
******* ifbb657@ccwf.cc.utexas.edu (Douglas R. Floyd) ******
            Disclaimer: I speak for myself.

            Please, no NeXTMail at this time.
Newsgroups: comp.security.misc
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Organization: Mount Holyoke College
Date: Wed, 11 Nov 1992 03:21:45 GMT

In article <1992Nov10.201503.6288@gw.wmich.edu> 873nikorawal@gw.wmich.edu writes:
>  What I do not understand is that how a user can send mail to a different user
>on the same system, and make it appear as though it has been sent by the
>operator or any other user on the system. Unless Of-course he has access to the
>operator/other persons account !!!!!

It's trivial, but we're not going to tell you how to do it.

>							Curiocity !!!!!!

I don't ever flame people for bad spelling, but the six exclamation marks
are unforgivable.

--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629



Newsgroups: comp.security.misc
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Re: Setuid script - is this unsecure?
Organization: Mount Holyoke College
Date: Wed, 11 Nov 1992 04:04:32 GMT

In article <AMOSS.92Nov6102549@shuldig.cs.huji.ac.il> amoss@shuldig.cs.huji.ac.il (Amos Shapira) writes:
>If you want an suid programme write it in C (even if it does dumb things) and
>don't use the system(3) and popen(3) functions because they call /bin/sh and
>hance it's almost like writing a shell script.  I bet people can find some more
>rules-of-thumb but these are the very basic ones you should follow.

Or better yet, use Perl, which won't allow you to perform "unsafe" operations
when running setuid.

--
Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Newsgroups: comp.security.misc
Subject: Re: Forging E-mail from root to get users to change passwords
Date: 5 Nov 1992 06:49:47 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: decel.ecel.uwa.edu.au

ifbb657@ccwf.cc.utexas.edu (Douglas Floyd) writes:

>Knowledgable users would be *VERY* suspicious because (to by knowledge)
>root **N-E-V-E-R** needs to know a user's password to effect changes
>to an account or the system, but this attack could work on novice UNIX
>users.

>What is the best way to prevent/slow down this form of attack?

Make it clear to all users when they are given the account the sort of
things that they will be asked to do and the sort of things they should be
aware of.  eg a list that states.

  Do not change your password to anything that someone tells you to.
  Report this to your superuser.

  Do not mail the file /etc/passwd to people requesting it.  Report them to
  your superuser.

  If you see something you don't think looks right.  TELL SOMEONE.

  Don't run xwindows :-)

This is by far the best way to combat this sort of problem.  You can also
install a program such as tcpd which will let you prevent telnet and
certain other service access from non-trusted sites.  You still accept mail
from anywhere because it won't get to you otherwise, but you don't have to
accept telnet connections from anyone you don't think needs access to your
machine.  If they can't get on, they can't do any (much) damage.

Craig
--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au Dvorak Keyboards RULE!  "Messes are only acceptable
if users make them.  Applications aren't allowed this freedom" I.M.VI 2-4
Newsgroups: comp.security.misc
From: wag5@quads.uchicago.edu (john peter wagner)
Subject: Mundane Decoy
Reply-To: wag5@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Date: Thu, 5 Nov 1992 22:54:08 GMT

	In response to an earlier poster's intent to find a secure method of
protecting the ibm hard drive, perhaps a decoy could be used. That is,
make your intital password system time-sensitive; add a single decimal
digit for the hour and another for the ones-digit in the day of the month.
Thus, one could have a relatively simple password made more complex-
Ex.-gibber37, could be a valid password at 3:15pm, on , say, Nov. 27.
A trojan would record the inputted password for the password.  As soon
as it is used on the system incorrectly by the hacker(The only way to use
the same password correctly is to use it in a ten-day increment, or whatever.)
The system would then allow the hacker into a prepared decoy-system, which
would have little useful data, probably 'crashing' at the first execution
of any binary file.  Warning messages would be sent to everyone to change
their passwords and even to redefine the modification of the time-generated
password scheme(Soem other numbers used, etc.).   Note, the decoy system
should have a password or user file or whatever which will give re-access
to the decoy for any of the passwords listed on it.

			Only an idea.

			John
From: barr@pop.psu.edu (David Barr)
Newsgroups: comp.security.misc
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Date: 12 Nov 92 23:19:56 GMT
Organization: Penn State Population Research Institute

In article <1992Nov12.141902.5402@ghost.dsi.unimi.it> cotrozzi@ghost.dsi.unimi.it (Massimo Cotrozzi) writes:
>probreak@kitty.ksu.ksu.edu (James Michael Chacon) writes:
>
>>pretty trivial to accomplish this. Basically I could send you mail from
>>root on your machine without ever having logged in or been near that 
>>machine.
>
>>James

>Even if I installed tcp wrapper ?

You spawn sendmail out of inetd?  How would you disable forgeries without
affecting legitimate mail connections?

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
From: genek@mentor.cc.purdue.edu (Gene Kim)
Subject: Re: Tripwire release
Organization: Purdue University
Date: Thu, 12 Nov 1992 20:42:12 GMT

uri@watson.ibm.com (Uri Blumenthal) writes:

>I'd say two things:

>	a) The signature should be cryptographically strong.   It
>	   means that it's infeasible for an adversary to compose
>	   a message with the same signature as yours.  There are
>	   several algorithms available, MD5 one of them... There
>	   is no reason to be afraid of an adversary  being  able 
>	   to "make backward calculation" [using decent sig, that 
>	   is].

    Tripwire supports hooks for up to ten signature routines.  We
ship it with MD5, Snefru, CRC32, CRC16, MD4, and MD2.  Although
the CRC routines are not "signatures" in the cryptographic sense,
they are nice to have since they are considerably faster than the
more secure algorithms -- which are (hopefully) one-way hash
functions.

    By default, Tripwire checks a file's MD5 and Snefru signature.
However, any combination of signature checks may be used to fit
your system's performance vs. security equation.  e.g., checking
MD5 signatures once per day, but checking CRC32 once every hour
is possible using Tripwire.

    Furthermore, if you have the newest and most secure signature
algorithm, say the super-secret Gurgleblatz Mark VIbis XIX routine,
you can simply add an interface to it to Tripwire's arsenal.  The
interface is simple enough:

	    int signature_routine(int fd, char *sig, int siglen);

    (Tripwire stores an array of pointers to the signature functions,
so it's very general.  Just compile it right in!)

>	b) The database of signatures is to be protected from [malicious] 
>	   modifications [because since the algorithm is known, an enemy,
>	   even if he can't modify your file  to fit the "old" signature,
>	   could in this case to change the file AND the signature]. I'd
>	   think, DES/CBC is quite enough of protection...

    Tripwire includes a 'sigfetch' utility that simply spits out the
signature for a given file.  A simple shell script could offer this
functionality.  As part of the Tripwire design, we require that the
database be immediately moved to a safe location (e.g., some read-only
media).

    In fact, I'll make sure a shell-script wrapper to do this is
included in the next Tripwire release.

Gene
Newsgroups: comp.security.misc
From: dave@jato.jpl.nasa.gov (Dave Hayes)
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Reply-To: dave@jato.jpl.nasa.gov
Organization: Jet Propulsion Lab - Pasadena, CA
Date: Fri, 13 Nov 1992 19:55:15 GMT

ddv@unix.brighton.ac.uk (Domenico De Vitto) writes:
>Any org. that has a _root_ password in _a_ dictionary gets all it deserves.

They didn't explicitly say that they cracked the root password. 
-- 
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
dave@elxr.jpl.nasa.gov       dave@jato.jpl.nasa.gov         ...usc!elroy!dxh

He is truly wise who gains wisdom from another's mishap.
Xref: sparky comp.security.misc:1655 alt.security:4759 comp.unix.admin:6065
From: limes@ouroborous.eng.sun.com (Greg Limes)
Newsgroups: comp.security.misc,alt.security,comp.unix.admin
Subject: Re: Tripwire release
Date: 5 Nov 92 20:20:00 GMT
Organization: Sun Microsystems Computer Corporation
NNTP-Posting-Host: ouroborous
In-reply-to: owens@acsu.buffalo.edu's message of 5 Nov 92 04:29:30 GMT

In article <Bx8757.HoF@acsu.buffalo.edu> owens@acsu.buffalo.edu (Bill Owens) writes:
|   Without adding the overhead of a digital signature for each file which
|   tripwire is keeping track of, could the program perhaps be set up to
|   check a cryptographic signature on the entire database?  If the key
|   used to make the signature were kept secure, presumably by encrypting
|   it, then I think this setup would be equally secure.

I think this is insufficient.

Let's say you protected a key program with such a signature, and used
a shell that would check such signatures before executing the program.

I'm a baddie, with sufficient (but maybe temporary) privileges on your
system that I can change the bits in the program (or maybe I'm a
virus). I change what I want to change, subverting the program. Then I
find some other bits that I don't care about, and twiddle them until
the signature is right. If I can make that backward calculation either
directly or by trial-and-error in a reasonable time, then your
signature protection system is no protection.
From: jon@hill.lut.ac.uk (Jon P. Knight)
Newsgroups: comp.security.misc
Subject: Re: Setuid file
Date: 5 Nov 92 09:01:20 GMT
Organization: Dept of Comp. Studies, Loughborough University of Tech., UK.

In article <1d9ggiINNsfb@sequoia.ccsd.uts.EDU.AU> mgream@acacia (Matthew Gream) writes:
>Robert Earl (chupchup@ferkel.ucsb.edu) wrote:
>: 
>: |    Found this on one of our systems.  Anyone know if there is any way
>: |    this could be used to obtain root access?
>: |    -rwsr-xr-x  1 root            0 Apr  7  1992 file
>: 
>No one yet asked what OS this was, HP-UX doesnt clear the setuid-bit on
>an append (at least It didnt in one of its installed versions ive seen),
>so appending a shell script to make a setuid shell is a trivial job.
>

But you'd need to be root to write to this file anyway...

Still, if you don't know what it is, back it up and then delete it. 
Better safe than sorry.

Jon


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
** I can't even talk to you without the aid of chemicals or lies. - Pele **
Newsgroups: comp.security.misc
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Forging E-mail from root to get users to change passwords
Organization: Texas Instruments Inc
Date: Thu, 5 Nov 1992 17:42:13 GMT

In <92309.193737CXF111@psuvm.psu.edu> Charles Fee <CXF111@psuvm.psu.edu> writes:

>Why would a hacker (who apparently has root access) need to tell users to
>change their password?  On my system (Linux) all root has to do is wipe out
>the users' old password and then the account is free.  You could then log in
>as that user without a password and run the passwd program to change it to
>whatever the cracker feels like doing.  Similarly, couldn't this also be
>done to the root password as well?  This is all assuming that there is a
>normal /etc/passwd file.  I don't know what the story is with Yellow Pages..
>If a user has access to the passwd file, he can change the users group Id to
>0, too no?

You don't even have to go through all this, if you already have root
access.  Just use passwd from root with the username argument and you
can change it directly from root.

>I'm curious as to (if the above is correct) what can be done to cut down the
>chances of such an attack..

Mail forgery is a problem inherent in the non-encrypted non-verified
SMTP mail world.  Tell your users not to do certain things when you
give them the account.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.security.misc