HDTenEightyP/NetNews huggingface dataset:
From: mcdowell@exlog.com (Steve McDowell)
Subject: Re: early Trojan Horse
Organization: EXLOG, Inc.
Date: Thu, 19 Nov 92 19:40:57 GMT


In message <956@dsbc.icl.co.uk> kev@dsbc.icl.co.uk (Kevin Walsh) writes:
>In article <1992Nov18.202710.9652@mcs.kent.edu> keithf@Nimitz.mcs.kent.edu (Keith Fuller) writes:
>
>> I heard that early UNIX systems came with a Trojan Horse.
>> As I remember, the C compiler would compile one of the utilities
>> in a way that would give a knowledgable person entry into any UNIX
>> system.
> 
> As I remember it, cc used to recognize a peice of code as being
> from the login program.  When you compiled login, the resulting
> executable would have a back door login in it.

Well, I don't know if that was ever implemented and I'd be very surprised if it
ever made it out of the lab if it was. 

This means of attack was discussed by Dennis Ritchie in an early papaer (mid-70's) 
on UNIX security as an option that's available to would-be-crackers with source code. 
If I remember correctly, the paper was distributed with the Version 7 manual set. 

-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<
From: oleg@gd.cs.csufresno.edu
Newsgroups: comp.security.misc
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Date: 20 Nov 92 14:40:53 GMT
Organization: Computer Science Departement of California State University in Fresno

In article <1drec6INNmf3@kitty.ksu.ksu.edu> probreak@kitty.ksu.ksu.edu (James Michael Chacon) writes:
>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 !!!!!
>
>>							Curiocity !!!!!!
>
>Its a rather simple exercise to forge email from anyone at anywhere.
>I of course am not going to say how its done, other than to say it's
>pretty trivial to accomplish this. Basically I could send you mail from

So, you don't study this in university? :) Well, to satisfy Curiocity !!!!!!
of original poster I would recommend ftp'ing to nic.ddn.mil and grabbing 
/rfc/rfc821.txt. Don't assume e-mail is secure. des the message with password
known to recipitant if you want to send anything important.

Oleg
From: hmj@cs.tut.fi (J{rvinen Hannu-Matti)
Newsgroups: comp.security.misc
Subject: Re: Setuid script - is this unsecure?
Date: 23 Nov 1992 09:34:05 GMT
Organization: Tampere University of Technology
Distribution: world
NNTP-Posting-Host: kuukkeli.cs.tut.fi

>>Equivalent would be that you let anybody execute mount (i.e., set
>>mount suid), which is not reasonable. Also you have to deny suid
>>programs on the floppy, and ensure that there does not exist special
>>devices on the floppy.

>>I've written a set of programs (fdmkfs, fdmount, and fdumount) to give
>>users access to the floppy. They are available by anonymous ftp on
>>site cs.tut.fi (130.230.4.2), file pub/src/tut/floppy.shar. Use on
>>your own risk.

>Everybode executing mount isn't indeed a good idea:
>How about mount /dev/fd /etc

That's exactly what I meant - perhaps I was not too clear. The orignal
C-code above lets anybody to execute mount as a suid-program, which is
equivalent to set mount suid.

My set of programs mount /dev/fd0c always on /floppy/disk to avoid
such problems. They also set privileges of /dev/fd0* and
/dev/rfd0* to prevent creation of devices using editors after the
mount.
-- 
-----
Hannu-Matti Jarvinen, hmj@cs.tut.fi
Opinions of tut != opinions of mine, and vice versa.
TTKK on samaa mielt{ kanssani siit{, ett{ en edusta sen mielipidett{.
Newsgroups: comp.security.misc
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
Date: Sun, 15 Nov 1992 19:17:28 GMT

>>student, and Costa George Katsaniotis, 21, of Seattle. Both were charged
>>with fraud against the government, which carries a maximum penalty of a
>>$10,000 fine and and five years in prison. The two were ordered to
>>appear before a U.S. magistrate on Monday.

Hmm .. looks very much like "crime against society".

//Jyrki
Newsgroups: comp.security.misc
From: tomd@stsci.edu (Tom DiGiacinto)
Subject: Security software query
Keywords: Raxco's Security Toolkit/UNIX
Reply-To: tomd@stsci.edu
Organization: Space Telescope Science Institute, Baltimore MD
Date: Tue, 17 Nov 1992 19:43:29 GMT

<If this is a FAQ please provide a pointer...>

I am looking for information regarding existing, and future, UNIX system security
software packages.  I have cops but am interested in something more.  
I have the sales literature from Raxco on their Security Toolkit/UNIX product.
It has a lot of nice features but they are asking a lot of $$$ for it.

Has anyone purchased this product?  Are there other "good" UNIX security
software packages available?  I will be receiving a demo copy from Raxco,
if anyonr is interested I will let them know how I feel about the product...



Newsgroups: comp.security.misc
From: mellan@syst06.acri.fr (Alain Mellan)
Subject: gnumake SGID: potential security hole?
Organization: A.C.R.I., Lyon, France
Date: Tue, 17 Nov 1992 12:19:50 GMT


I just discovered today that gnumake is installed with SGID bit, and
belongs to user root, group kmem.

Am I right to be suspicious ?  The kmem SGID will allow gnumake to
read into /dev/kmem the info needed for load balancing, but is that
all?



--
Alain Mellan                          
Advanced Computer Research Institute 
1 Bvd Marius Vivier Merle             voice:  (+33) 72 35 84 92         
69443 LYON CEDEX 03 - FRANCE          email:    amellan@acri.fr

Newsgroups: comp.security.misc,alt.security,comp.unix.admin
From: spaf@cs.purdue.EDU (Gene Spafford)
Subject: Re: Tripwire release
Organization: Department of Computer Sciences, Purdue University
	<1992Nov13.174545.145856@watson.ibm.com>
Date: Sun, 15 Nov 1992 18:57:42 GMT

In article <1992Nov13.174545.145856@watson.ibm.com> uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,) writes:

   Why not just prompt the user for the key, and encrypt the database?
   You could have plugs for DES, IDEA, FEAL (for those not very much
   security-concerned :-)...

Well, there are several reasons.  First, protecting the database by
encryption won't prevent it from being deleted or truncated.  Nor will
encryption protect the program itself.  For that, you need to have it
on read-only media.

Second, if a key is required every time Tripwire is run, then there is
no safe way to run the program out of "cron" every night or every few
hours (or every month -- whatever).

Third, we wanted to ship a self-contained program that anyone could
use without needing outside utilities (other than a compiler).  If we
built in reliance on encryption, it would have required that we ship
the encryption code with it -- something that we didn't want to do
because of the incredibly stupid export control laws in the US and
other places.  Furthermore, few people would be able to detect if the
encryption code had been tampered with to introduce a backdoor or
weakened form of the algorithm.

Fourth, there is a window of vulnerability to catching a key
(password) using most encryption programs that are out there.  We
believe that creating a read-only disk version of the database in
single-user mode is safer.

Last of all, not every encryption routine that someone might use is
very strong.  Thus, if we put the hooks in place for someone to drop
something in, undoubtedly someone would drop in rot13 and think that
their system was protected by Tripwire.  It would seem pretty silly to
run every file through MD5 and Snefru, only to protect the results
with a Caesar cipher, no?  Thus, we decided to encourage something we
believe is less likely to get screwed up, although we suspect that
many people won't pay attention to our recommendation as is...sigh.

Of course, by shipping the source code, a knowledgeable user can put
in whatever other extensions and features they wish.  Our particular
preferences and prejudices many not be appropriate for every site.
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: Mon, 23 Nov 1992 20:49:17 GMT

stanley@skyking.OCE.ORST.EDU (John Stanley) writes:
>>>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
>If decrypting the passwords gave him the root password, then yes, Dave,
>they cracked the root password.

"That process gave Anderson the root password". That could also mean
that by getting a random account on the machine they _acquired_ root
access, and then changed the password. 
-- 
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
dave@elxr.jpl.nasa.gov       dave@jato.jpl.nasa.gov         ...usc!elroy!dxh

Penitent (adj.) - 1. Someone who has been made incapable of enjoyment.
Newsgroups: comp.security.misc
From: craig@osh3.OSHA.GOV (Craig Nordin)
Subject: Re: Crack vs. Decrypt (was Re: Two hackers caught...)
Organization: U.S. D.O.L - Occupational Safety & Health Admin.
Date: Sun, 22 Nov 1992 20:43:53 GMT
Keywords: decrypt crack media

In <1992Nov22.113138.26493@mtu.edu> mrmach@mtu.edu (MARK ROMAN MACH) writes:

>From the original article way back:
>>``He then transferred the password file to a Boeing Company computer,
>>where he decrypted the passwords.''

>    I've always had the tendency to differentiate "cracking" and
>"decrypting" as two separate things.  I always considered "decrypting"
>to imply that the key was used to convert from cipher text to plain
>text, or that the appropriate inverse algorithm was used.  "Cracking"
>seems to imply things like randomly guessing the plain text until a
>cipher text match is found, crunching out computationally difficult
>inverse algorithms, or other illegitimate & unsanctioned methods to
>discover the plain text.

>    Am I wrong in believing this?  Does anybody else feel that the
>newspaper was irresponsible (or at least misinformed) by saying he
>"decrypted" the passwords?

Well, yes and no.  I think your delineation was more correct, but
possibly from a too-technical point of view.

You are using descriptions of technical operations to separate the
two meanings, but you also hint at the more simple difference of
morality between the two words.  Cracking being an immoral action
while decrypting being moral - or decrypting being somehow peaceful
and cracking being combative.

Crack is the new verb here.  Decrypt ought to mean, to a layman,
"unhide" or even "reveal".  To a techie, it ought to mean other 
things too.

How much do you expect the non-expert to carry around in his 
head anyway? :-)

>--
>Mark R. Mach, mrmach@mtu.edu

 -
 US Department of Labor      Craig Nordin          craig@osh3.osha.gov
 OSHA OMDS FSDB #N3661                  uunet!osh1.osha.gov!osh3!craig 
 200 Constitution Ave. NW Phone (FTS/202) v:219-7788 x57  fax:219-5830
 Washington D.C. 20210    Standard, Complete, and Constant Disclaimers
From: tgll@datasci.co.uk
Newsgroups: comp.security.misc
Subject: What has happened to the comp.security.announce newsgroup
Date: 18 Nov 92 11:15:49 GMT
Reply-To: tgll@datasci.co.uk
Organization: Data Sciences UK Limited


 
What has happened to the comp.security.announce newsgroup.  I used to read the
CERT advisories in it regularly, but I have reveived nothing on it since the
summer, and I have a feeling that the newsgroup has even been deleted.

(Its quite possible that I never received the rmgroup mesage, because our news
has been very flakey since summer; similalry I would almost certainly have
missed any discussion about the group either in comp.secirity.misc or
news.groups)

Where should I get CERT advisoiries from now?

Thanks,
Tim Lyons.
Newsgroups: comp.security.misc
From: mrmach@mtu.edu (MARK ROMAN MACH)
Subject: Crack vs. Decrypt (was Re: Two hackers caught...)
Keywords: decrypt crack media
Organization: Michigan Technological University
Date: Sun, 22 Nov 1992 11:31:38 GMT

From the original article way back:
>``He then transferred the password file to a Boeing Company computer,
>where he decrypted the passwords.''

    I've always had the tendency to differentiate "cracking" and
"decrypting" as two separate things.  I always considered "decrypting"
to imply that the key was used to convert from cipher text to plain
text, or that the appropriate inverse algorithm was used.  "Cracking"
seems to imply things like randomly guessing the plain text until a
cipher text match is found, crunching out computationally difficult
inverse algorithms, or other illegitimate & unsanctioned methods to
discover the plain text.

    Am I wrong in believing this?  Does anybody else feel that the
newspaper was irresponsible (or at least misinformed) by saying he
"decrypted" the passwords?

--
Mark R. Mach, mrmach@mtu.edu
Newsgroups: comp.security.misc
From: keithf@Nimitz.mcs.kent.edu (Keith Fuller)
Subject: early Trojan Horse
Organization: Kent State University
Date: Wed, 18 Nov 1992 20:27:10 GMT

I heard that early UNIX systems came with a Trojan Horse.
As I remember, the C compiler would compile one of the utilities
in a way that would give a knowledgable person entry into any UNIX
system.

Does anyone know anything about this?
Like some other people who are asking such questions,
I am indeed writing a term paper on UNIX security.

THANKS!

______________________________________________________________________________
keithf@mcs.kent.edu
Keith Fuller
"What's up?"          Obtaining an MA in        Ich bin ein Virus.
"Gimme five!"         Computer Science from     Mach' mit und kopiere
"Have a nice day!"    Kent State University     mich in Deine .signature.
From: wack@ariel.ncsl.nist.gov (John Wack)
Newsgroups: comp.security.misc
Subject: Re: anonymous ftp checklist
Date: 20 Nov 92 14:50:43 GMT
Organization: National Institute of Standards & Technology


I'd recommend that you ftp to cert.org -- they have a checklist for
anonymous ftp and, since they're running their own anonymous ftp
and are a likely target for crackers, it contains some good advice.
Unfortunately, I can't locate my own copy right now, otherwise I'd
include it here.  But, I'd take a look at what they have to say.

Well, as long as I'm typing, another thing I'd recommend is to use
a non-stock ftpd that does better logging and access control.  We're
using the one from wuarchive.wustl.edu, which logs transfers and
many other items (configurable) and also uses an access-control file
that will allow you to disable ftp based on load, time of day, point
of origin, etc.  You might want to take a look at that as well.

Good luck,
John Wack

Newsgroups: comp.security.misc,comp.org.eff.talk
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Subject: Internet worm
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland
Date: Mon, 23 Nov 1992 13:57:13 GMT

In article <Nov.22.20.51.11.1992.20989@inferno.rutgers.edu>, gaynor@inferno (Silver) writes:
>THE PERSECUTION OF MORRIS WAS UNJUSTIFIED (and I _hate_ using all-caps for
>emphasis).  It was his graduate project in computer risks and security.  Given
>the worm's tenacity, the likelihood of its accidental release is high enough to
>believe that its release _was_ accidental.  Regardless, it did nothing more
>than propagate itself.  Many consider his worm a good thing.

[ in comp.admin.policy among other groups ]

So, was it a graduate project?

//Jyrki
From: drector@math.uci.edu (David Rector)
Subject: Re: anonymous FTP checklist
Newsgroups: comp.security.misc
Keywords: anon FTP
Date: 19 Nov 92 18:07:33 GMT

francis@monod.Biol.McGill.CA (Francis Ouellette) writes:

>Dear csm readers,

>I have just installed anon ftp on my machine, and I was wonderring if
>there is a checklist somewhere of things that have to be checked for
>me to assure myself that everything is OK from a security point of
>view.

>Any pointers would be most appreciated,

>regards to all,

>francis


>--
>| B.F. Francis Ouellette  
>| manager, yeast chromosome I project
>| dept of biology, McGill university, Montreal, Qc, Canada
>| francis@monod.biol.mcgill.ca

If you find it necessary to have an "incoming" directory, that is a
directory with write privileges, be sure to check it regularly for
unwanted material, or you might find yourself playing host to an
unwanted---or even illegal---bulletin board.  A favorite trick of
bb creators is to hide their files from the ls command by prefixing the
file names with periods or other unprintable characters.  Use the
-a option to ls, or use du, to search for unwanted files.

I need hardly add that I am a recent victim of this scam.  I forgot
about the -a option.


--
David L. Rector				drector@math.uci.edu
Dept. of Math.				U. C. Irvine, Irvine CA 92717

Newsgroups: comp.security.misc
From: stehman%citron.cs.clemson.edu@hubcap.clemson.edu (Jeff Stehman)
Subject: Re: responsibility of admins (was: Two hackers
Reply-To: stehman%citron.cs.clemson.edu@hubcap.clemson.edu
Organization: Clemson University
Date: Tue, 17 Nov 1992 14:13:30 GMT

From article <1992Nov16.225740.16227@den.mmc.com>, by jhull@vulcan-gw.den.mmc.com (Jeff Hull):
> 
> Would you still feel this way if the venue were a small business and the topic
> were locking up the cash box?  How about a bank and putting the money in
> a 1700's style safe?  How about a credit reporting company and their credit
> database?  With *your* credit history stored on it?
> 
> The real point is raising the level of awareness of *all* users and sysadmins.
 

How!?!  *We* do not have contact with *all* users and sysadmins.  *Vendors*
do, and they are the *only* ones who do.

--
Jeff Stehman			Systems Staff, G-18A Jordan
stehman@cs.clemson.edu		Dept. of Computer Science
(803)656-2639			Clemson University
Newsgroups: comp.security.misc
From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
Subject: Re: responsibility of admins (was: Two hackers
Summary:  What you don't know can kill you.
Keywords: security awareness sysadmin training certification
Reply-To: jhull@vulcan-gw.den.mmc.com
Organization: Martin Marietta Astronautics Group
Date: Mon, 16 Nov 1992 22:57:40 GMT

In article 12580@hubcap.clemson.edu, 
stehman%citron.cs.clemson.edu@hubcap.clemson.edu (Jeff Stehman) writes:
|>
|>Familiarity is a dangerous thing.  Seems like many of you have forgotten what
|>it is like not to be familiar with computer security issues.
...
|>Try seeing it from Joe's perspective before you flame him.

Would you still feel this way if the venue were a small business and the topic
were locking up the cash box?  How about a bank and putting the money in
a 1700's style safe?  How about a credit reporting company and their credit
database?  With *your* credit history stored on it?

The real point is raising the level of awareness of *all* users and sysadmins.

Somebody told me once, "What you don't know won't hurt you."  Do *you*
believe that?  Let me tell you about this land in Florida I have for sale...

---
	   _   _
    /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir  
/_/ \_/ /   /	  Aurora, CO 80012    303-977-1061

No matter where you go ... there you are.
#include <standard.disclaimer.h>
From: hudgens@SCRI.FSU.EDU (Jim Hudgens)
Newsgroups: comp.security.misc
Subject: Re: anonymous FTP checklist
Date: 22 Nov 92 18:02:46 GMT
	<1992Nov22.021756.25285@ugle.unit.no>
Organization: SCRI, Florida State University
In-reply-to: agulbra@flipper.pvv.unit.no's message of 22 Nov 92 02:17:56 GMT


   In article <drector.722195714@math.uci.edu> drector@math.uci.edu (David Rector) writes:
   ...
   >If you find it necessary to have an "incoming" directory, that is a
   >directory with write privileges, be sure to check it regularly for
   >unwanted material, or you might find yourself playing host to an
   >unwanted---or even illegal---bulletin board.  A favorite trick of
   >bb creators is to hide their files from the ls command by prefixing the
   >file names with periods or other unprintable characters.  Use the
   >-a option to ls, or use du, to search for unwanted files.
   >
   >I need hardly add that I am a recent victim of this scam.  I forgot
   >about the -a option.

   I, too, once had 100 FTP logins in 24 hours... my advice is to patch
   the ftp daemon so files uploaded by guests have to be chown'd or cp'd
   before they can be downloaded by guests.

We've installed a patch like this on an ftp server here, and it has
worked really well in stopping 3rd party transfers.

Basically, we brought up a ftp server which had writable directories,
no logging of transfers, and took a very casual approach to running the
machine (i.e. check it was still up every couple of days).  During
that period, we unwittingly hosted *lots* of transfers of files.  Once
it was discovered what was happening, the first option was to kill the
writable subdirectories, but that got overruled, since alot of valid
stuff gets put on the machine by external scientists wanting to
transfer files to some user here.  So, we basically tag each file as
"remotely uploaded" or "locally uploaded", and disallow "remotely
uploaded" files from being downloaded from a remote site.  We run the
logging, too, and basically, all problems have ceased for at least the
last year or so.  So we started with the basic berkeley ftpd, with
some logging patches applied (don't know who did these patches,
either), and about 100 or so lines of locally applied patches.

I'd  suggest that anyone starting up an anon-ftp server, should 
enable logging at the very least.

JHH



--
Jim Hudgens 			Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edu      

Newsgroups: comp.security.misc
From: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Reply-To: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Organization: Motorola Codex, Canton, MA
Date: Fri, 20 Nov 1992 18:54:35 GMT

In article <84008@ut-emx.uucp>, ifbb657@ccwf.cc.utexas.edu (Douglas Floyd) writes:
[lots deleted]
|>Here is another item:  If the data is vital, back it up, and store
|>the data and the backups on removable media.  Then, when you leave,
|>store the original in a safe that is bolted down, and store the backups
|>in a secure area, like a safety deposit box at your local bank.  This
|>method will secure from basically everything but scavenging for
|>palempsits (spelling?), or putting the operator under duress.
|>
|>Any other ideas?

In a lot of places it is standard practice to make _two_ backups.  One is
used for day-to-day restores and is stored somewhere handy, normally near
the computing system.  The other is taken off-site and held somewhere really
safe, like a bank or a firesafe.  This is very similar to the previous
poster's idea, except that it doesn't need the original data to be stored
on removable media.  Incidentally, it's a good idea to invest in a firesafe
and make sure that at least one copy of your backups is put in it.

If you think that this is all way too much, just ask yourself one question -
how long would your company last if all the data from your computer system
disappeared?

Lezz Giles