HDTenEightyP/NetNews huggingface dataset:
From: pc123@cus.cam.ac.uk (Pete Chown)
Newsgroups: comp.security.misc
Subject: Re: Mail forging
Date: 15 Nov 92 19:14:57 GMT
	<4225@bcstec.ca.boeing.com> <BxrJCL.9sC@mtholyoke.edu>
Organization: U of Cambridge, England

In article <BxrJCL.9sC@mtholyoke.edu> jbotz@mtholyoke.edu (Jurgen
Botz) writes:

   >Can you say how to detect it?

   Detection is trick... if the message was a forgery of a "local"
   message on a Unix system, you can probably detect it from the
   sendmail logs; if they message were authentic it would not have
   passed through SMTP.

Be careful.  Remember that different users will use different programs
for reading their mail.  Some of these programs connect to the local
mail server by SMTP, while others use /bin/mail.

   If done correctly, the header of a forged message will be *exactly*
   identical to the header of the message had it been authentic.  If
   there's any way of identifying the forgery in such a case it's via
   logs of network activity, not the message itself.  And yes, if you
   have a resonably good understanding of what a correct message
   header /should/ look like, it's quite trivial to execute such a
   forgery.

If you run a modern mail server it should be detectable.  For example
there is a mail server on a dedicated machine here - ppsw1.cam.ac.uk -
but it won't let you pretend to be an arbitrary person.  If your
machine is running RFC931 you won't be able to pretend to be anyone at
all; if not you will be able to pretend to be any user on the machine
you are sending the forged message from.  This is very different from
being able to pretend to be any user on the Internet.

Old mailers will accept anything they are fed by the forgers, and
these mailers should really be upgraded.
--
---------------------------------------------+ "A tight hat can be stretched.
Pete Chown, pc123@phx.cam.ac.uk (Internet)   |  First damp the head with steam
            pc123@uk.ac.cam.phx (Janet :-)  -+  from a boiling kettle."
From: zen@death.corp.sun.com (d)
Newsgroups: comp.security.misc
Subject: Re: anonymous FTP checklist
Date: 19 Nov 92 11:34:33
Organization: savage hackers
NNTP-Posting-Host: death.corp.sun.com
In-reply-to: francis@monod.Biol.McGill.CA's message of Thu, 19 Nov 1992 06:49:05 GMT


In article <francis.722155745@monod> francis@monod.Biol.McGill.CA (Francis Ouellette) writes:
>   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.

  You can try running ftp.chk with the -a flag, which comes with cops
(available via anon-ftp, archive.cis.ohio-state.edu, ~pub/cops.)  The
comment header has some tips on how to set up anon-ftp securely; if
nothing else, you should look at that (I've enclosed it below.)

 -- d


#  Usage: ftp.chk [-a]
#
#   This shell script checks to see if you've set up (mainly anonymous)
# ftp correctly.  The "-a" option forces a check on your anon-ftp setup
# (without the flag, this will look in your /etc/passwd, to see if user
# ftp exists, and proceed onwards anyway) without that, this script 
# doesn't do a whole lot -- just check to see if your ftpusers file 
# doesn't have any root accounts in it.  There seems to be some different
# types of ftp's around; for instance, some allow "chmod" -- and if the home
# dir is owned by "ftp", you're toast.  So I've tried to err on the side of
# safety...
#
#   See the man page for a more detailed description, here's what this
# checks for:
#
# - User ftp exists in the password file.
# - root (or all root equivalents) are in ftpusers file.
# - Home directory for ftp should exist, and not be /
# - The ~ftp/etc/{passwd|group} should not be the same as the real ones.
# - Various critical files/directories should exist, and have correct
#   permissions and owners; variables "$primary" and "$secondary" can be set
# to whomever you want owning the files:
#
#  File/Dir          Perms           Owner      Other
#  =========         ======          ======     ======
#  ~ftp              non-w.w.        root
#           or
#  ~ftp              555             ftp	if no chmod command exists
#
#     All of these are ftp owned iff no chmod exists...
#
#  ~ftp/bin          non-w.w.        root/ftp
#           or
#  ~ftp/bin          non-w. and ftp w. ftp
#  ~ftp/bin/ls       111             root/ftp
#  ~ftp/etc          non-w.w.        root
#           or
#  ~ftp/etc          non-w. & ftp w. ftp
#  ~ftp/etc/passwd   non-w.w.        root/ftp   0 size or nonexistant
#  ~ftp/etc/group    non-w.w.        root/ftp   0 size or nonexistant
#  ~ftp/pub          non-w.w.        root/ftp
#  ~ftp/incoming     world-writable  root/ftp   This can be set to "pub"
#  ~ftp/.rhosts      non-w.w.        root       0 size, is optional
#  ~ftp/*            non-w.w.                   other dirs/files in ~ftp
#
Newsgroups: comp.security.misc
From: jru@Comtech.com (Jimmy R. Upton)
Subject: Re: encryption for wireless networks
Organization: Comtech Labs Inc, Palo Alto
Date: Sat, 21 Nov 1992 23:43:09 GMT

In article <1992Nov19.235934.7362@pcnntp.apple.com> normile.j@applelink@apple.com (James Normile) writes:
>Hi there,
>I'd appreciate any information on practical techniques for encrypting data on 
>wireless networks, are standards developing?, is any technology available?
>Thanks
>James Normile

I am responsible for the development of an encryption chip here at Comtech
called PED (the Programmable Encryption Device).  It is a single chip that
contains all the necessary support for the entire range of cryptographic
functions: secret key, public key, random numbers, hashing, etc.  The chip
is under development and an emulator will be available in 1Q93 and prototype
chips in 3Q93.

The chip provides all the crypto support - if you are asking about protocol
standards, I am not aware of any standards that have gained wide acceptance
for wireless networks.  If you want to encrypt your data at layer 3 or 4
of the OSI model then standards have been established in the U.S and are 
being submitted for international standards.  None of that however would
be specific to wireless communications.  Most (if not all) standards work
attempts to be algorithm non-specific.  Therefore you have two selections
to make - one to select the protocols and one to select the actual crypto
to use.  If you wish to imbed the crypto at a low level in your wireless
network, you may very well establish your own "protocol" which would be
simple and specific to your product.  Then you still need the hardware
to perform the encryption.  You can either go buy all the components to
put all that together or you can get a single chip that does all the
crypto.  To the best of my knowledge we are the only company offering such
a single chip solution.

NIST (National Institute of Standards and Technology) in 1977 established
and encryption standard called DES (the Data Encryption Standard).  They
currently have in draft form a DSS (Digital Signature Standard) and a SHS
(Secure Hashing Standard).  The do not currently have a standard for using
public key to handle key management.  There are several options available
for that.  So, in terms of crytographic algorithms, there is a sufficient
suite of "standards" to provide what you would need.  All of these are
implemented in PED.

Your question did not indicate what level of experience you have in these
areas.  If my response was too tutorial, my apologies.  If I can provide
additional assistance or explanation, please let me know.

Jimmy Upton
Comtech Labs
(415)813-4546
jru@Comtech.com

P.S.  I attempted to mail this response directly to you and save bandwith.
However you return address appears to be corrupted.  If you wish to 
continue this dialogue please send me your address.  Thanks.
From: kev@dsbc.icl.co.uk (Kevin Walsh)
Newsgroups: comp.security.misc
Subject: Re: early Trojan Horse
Date: 19 Nov 92 15:15:03 GMT
Organization: Cursor Software Limited, London, England

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.
> 
> 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.
> 
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.

You could log in as "bell" and get in as root.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/     K e v i n  W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/      kev@dsbc.icl.co.uk
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/
Newsgroups: comp.security.misc
From: chris@barrister.ucs.uoknor.edu (Chris L Petroff	)
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Originator: usenet@midway.ecn.uoknor.edu
Date: Tue, 17 Nov 1992 16:38:15 GMT
Reply-To: chris@barrister.ucs.uoknor.edu
Organization: University of Oklahoma Cumputing Services

|>From: ddv@unix.brighton.ac.uk (Domenico De Vitto)
|>
|>What does FTFRFC mean ??????
|>
|>Semi-seasoned unix guru is puzzled ?
|>
|>Dom
|>

how about....  Read The FIne RFC  (Request For Comments)    ;-)

If you don't know what an RFC is, you need more seasoning!  ;->

Chris.
Newsgroups: comp.security.misc
From: zeus@vxcrna.cern.ch
Subject: Avoiding the FBI, security agencies read this!!!
Summary: Security agencies note: Why don't you just give up now?
Reply-To: /dev/null
Organization: CERN European Lab for Particle Physics
Date: Sun, 22 Nov 1992 22:45:13 GMT

Just had an idea, a new encryption system to spoof the FBI but
nobody else.

Consider the problem, we are mandated to give the keys for anything we
send in encoded form ove a network.

So what we need is an encryption system with a switch. The first
key is used to send our real data, the second is used to send
the King James bible.

We set up the system such that only every other byte is actualy
used to encrypt, the other byte is taken from the king James bible.

When the FBI ask for the keys we give them the King James bible key
and explain that the data is purely dummy data used to provide
a base to fool a snooper.

In order to provide an origin for the true data we need to
incorporate an additional source of noise, this comes from a
non computational random generator (eg a Gieger Mueller tube)

So how do the FBI know if they are being told the truth or not?

--
Phill Hallam-Baker,
Europe, land of freedom.
Newsgroups: comp.security.misc
Subject: Re: Two hackers caught tapping into Boeing, federal computers
From: nick+@pitt.edu (Nick C De Mello)
Date: 21 Nov 92 16:20:43 GMT
Organization: Turing Toy Factory

>>>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. 
>
>>>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.

  Oh, come on... what do you think is more likely: these two kids
broke the DES encryption scheme, or the newspaper confused decrypting
with running the encryption on a /usr/dict/words file and greping
it with the /passwd file.
  I'll grant you they cracked the root, and thus system, but unless
I see some more details I'm going to be really skeptical of claims
they came up with the inverse DES function.

                                      -- Nick


-- 
   _/   _/  _/  _/_/_/   _/   _/  Sea Shells to C shells,  Waikiki to
  _/_/ _/  _/  _/   _/  _/_/_/     the Internet, a wave, is a wave...
 _/ _/_/  _/  _/       _/ _/                     
_/   _/  _/   _/_/_/  _/   _/  CompSrv: 71232,766 * I-Net: Nick+@pitt.edu
From: dittrich@carson.u.washington.edu (Dave Dittrich)
Newsgroups: comp.security.misc
Subject: Re: gnumake SGID: potential security hole?
Date: 18 Nov 92 21:07:43 GMT
Article-I.D.: u.1992Nov18.210743.26908
Organization: University of Washington

smb@ulysses.att.com (Steven Bellovin) writes:

>In article <MELLAN.92Nov17131950@syst06.acri.fr>, mellan@syst06.acri.fr (Alain Mellan) writes:
>> 
>> 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?

>Someone who can read /dev/kmem can also read interesting things like
>typed passwords in tty input buffers, and disk blocks from read-protected
>files.  I have no idea whether or not it's possible to trick gnumake
>into doing those things -- for example, if it doesn't properly reset
>its setgidness and close the file descriptor before execing a user program.
>There's a definite risk here, if things weren't done properly.

I guess if you are worried you should simply RTFC (after all, gnumake *is*
public domain -- but because of this fact I would doubt any security holes
would go unnoticed this long).  You could also try one of the gnu groups.
From: matthews@oberon.umd.edu (Mike Matthews)
Newsgroups: comp.security.misc
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Date: 22 Nov 92 16:31:15 GMT
Organization: /etc/organization

There seems to be some massively different trains of thought going on here.
The statement from before:

	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

could mean he cracked the root password by the password being a dictionary
word, or it could mean he cracked someone else's password, got into the
system, and used an unmentioned hole in the system.

What is unclear is whether or not the root password was determined directly
by the cracking (which would mean the systems allowed root logins over the
network, UNLESS...) *OR* the root password was begotten by breaking in to
someone else's account, becoming root and giving 'root' a new one.

To *me* it seems the root password was determined because it was guessed by
the cracking software.  To *me* it means they allowed root logins over the
network.

I didn't see any claims or mention anywhere about someone figuring out a way
to decrypt DES encryption -- and I too don't believe it anyway.
------
Mike Matthews, matthews@oberon.umd.edu (NeXTmail accepted)
------
How doth the little crocodile
    Improve his shining tail,
And pour the waters of the Nile
    On every golden scale!

How cheerfully he seems to grin,
    How neatly spreads his claws,
And welcomes little fishes in,
    With gently smiling jaws!
From: smd@sl0091.srl.ford.com (Steve Dahmen)
Newsgroups: comp.security.misc
Subject: Ftp'ing out of a chroot()ed environment
Date: 16 Nov 1992 18:13:58 GMT
Organization: Scientific Research Lab, Ford Motor Company
Distribution: world
NNTP-Posting-Host: sl0091.srl.ford.com
Originator: smd@sl0091.srl.ford.com


Does anybody understand chroot and ftp/telnet enough to tell me why
I can't get ftp nor telnet to run in my chrooted account??  I'd like
to set up a user zone to allow simple ftp/telnet through without opening
my whole system.

I did a dump -n on the binaries and ensured the requested libraries are
available in the chrooted environment.  Do I need anything special in
/etc (I have resolv.conf) or /dev???

Help.

-- 
Steve Dahmen ** Graphics Application Programmer
Ford Motor Company
smd@sl0091.srl.ford.com
313-594-3229 (work)
From: mcb@net.bio.net (Michael C. Berch)
Newsgroups: comp.security.misc
Subject: Re: your government in action (was Re: CIAC bulletin D-04)
Date: 18 Nov 92 22:35:21 GMT
Organization: IntelliGenetics, Inc., Mountain View, California, USA

In the referenced article, fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
> :-)
> 
> >From: mcb@presto.ig.com (Michael C. Berch)
> >Organization: IntelliGenetics, Inc., Mountain View, California, USA
> writes:
> ...
> >
> >        _____________________________________________________
> >             The Computer Incident Advisory Capability
> >                         ___  __ __    _     ___
> >                        /       |     / \   /
> >                        \___  __|__  /___\  \___
> >        _____________________________________________________
> >                           INFORMATION BULLETIN
> >
> >       18 New and Upgraded Security Patches Available For SunOS
> ...
> [ Ken Pon's announcement to Sun Customers, renumbered and reformatted ]
> ...
> >This document was prepared as an account of work sponsored by an agency
> >of the United States Government.  Neither the United States Government
> 
> ... man, I'm in the wrong line of work. :-)
> 
> Brian
> (future consultant :-))

My understanding is that both the CIAC Bulletin and the Sun Security
list announcement were worked on jointly by Sun and DOE CIAC staff and
the result was disseminated separately to both communities of
interest.  It is not a case of CIAC claiming credit for Sun's work, nor
of Sun claiming credit for CIAC's.  In fact, the Sun bulletin
acknowledges the efforts of a member of the CIAC staff, and
correspondingly this CIAC bulletin cites Ken Pon's work and
assistance.

I receive the CIAC bulletins by e-mail and have begun posting them here
since there seems to be some difficulty in getting them into
comp.security.announce (where they belong).  Hopefully this will be
solved in the future.

--
Michael C. Berch
mcb@presto.ig.com / mcb@net.bio.net / mcb@postmodern.com
From: nick+@pitt.edu (Nick C De Mello)
Newsgroups: comp.security.misc
Subject: Re: BAFFELED ??#@# !! CONFUSED !!#@@!!!!!
Date: 17 Nov 92 15:50:57 GMT

In article <1992Nov14.012959.13319@netcom.com> aclark@netcom.com (Al Clark) writes:
>In article <1992Nov13.091926.29460@unix.brighton.ac.uk> ddv@unix.brighton.ac.uk (Domenico De Vitto) writes:
>>What does FTFRFC mean ??????
>>
>>Semi-seasoned unix guru is puzzled ?
>>
>>Dom
>
>It was "RTFRFC".  Hint; consider RTFM.

  Could it be FTP RFC ?

                      -- Nick


-- 
   _/   _/  _/  _/_/_/   _/   _/  Sea Shells to C shls,  Waikiki to
  _/_/ _/  _/  _/   _/  _/_/_/     the Internet, a wave, is a wave...
 _/ _/_/  _/  _/       _/ _/                   
_/   _/  _/   _/_/_/  _/   _/                       Nick+@pitt.edu
Newsgroups: comp.security.misc
From: jbotz@mtholyoke.edu (Jurgen Botz)
Subject: Mail forging
Organization: Mount Holyoke College
Date: Sun, 15 Nov 1992 15:07:32 GMT

In article <4225@bcstec.ca.boeing.com> vanzwol@bcstec.ca.boeing.com (Ted Van Zwol) writes:
>OK, so if you won't say how to do it (possibly reasonable enough...)
>Can you say how to prevent it?

With the current set of Internet standard protocols, there is no way of
preventing forged mail.  The technology to do that exists with public-key
crytography and electronic signatures, but since there are not yet any
widely implemented standards for using this technology on the net, it is
not practical for an individual to do so.

>Can you say how to detect it?

Detection is trick... if the message was a forgery of a "local" message on
a Unix system, you can probably detect it from the sendmail logs; if they
message were authentic it would not have passed through SMTP.  If the
forgery was one where a user spoofed a user on a remote system, you might
need cooperation of the sysops of other systems along the route for 
reliable detection, making it practically very difficult if the forger
was clever.

Note that the former covers the case Mr. caps-and-exclamation-marks was
asking about; it is quite easy to detect the case where a user of a multi-
user Unix system tries to spoof a message from "root" (however, detection
will be from the logs, not the message itself.)

>Is it truly that trivial and foolproof?  Or does it just make the
>header *look* like it came from someone else (read root) to the
>non-attentive eye?

If done correctly, the header of a forged message will be *exactly* identical
to the header of the message had it been authentic.  If there's any way of
identifying the forgery in such a case it's via logs of network activity,
not the message itself.  And yes, if you have a resonably good understanding
of what a correct message header /should/ look like, it's quite trivial to
execute such a forgery.

Note however that in many cases of actual forgeries the headers might
provide a clue to the fact that the message is a forgery because a lot
of the forgers do /not/ really understand what a correct message header
looks like, or conversely, they produce a "correct" looking header but
the real system would have produced different or less correct one.
--
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: carl@montebello.ecom.unimelb.EDU.AU (Carl Brewer)
Subject: Re: Two hackers caught tapping into Boeing, federal computers
Organization: Dept. Engineering Computer Resources, Melbourne Uni.
Date: Tue, 17 Nov 1992 23:24:51 GMT

In article <1992Nov12.142251.9131@hubcap.clemson.edu> stehman%citron.cs.clemson.edu@hubcap.clemson.edu writes:
>From article <1992Nov12.084549.5128@unix.brighton.ac.uk>, by ddv@unix.brighton.ac.uk (Domenico De Vitto):
>> Any org. that has a _root_ password in _a_ dictionary gets all it deserves.
>
>
>Would you like to require people to read c.s.m for a couple of months before
>they're allowed to purchase a computer?

it would be a good idea for anyone connecting a machine to the internet
to do so, or similar.  But this would seem to be common sense ....


-- 
 Annal  Natrach, Usthvah Spethed,         carl@ecr.mu.oz.au (IRC: Bleve)
 Dochoel Dienve                           carl@munagin.ee.mu.oz.au
					  carl@montebello.ecom.unimelb.EDU.AU
 Merlin, where are you?  Call your dragon, to weave a mist...
Newsgroups: comp.security.misc
From: kinyon@next3.corp.mot.com (John J. Kinyon)
Subject: Re: What has happened to the comp.security.announce newsgroup
Reply-To: kinyon@next3.corp.mot.com
Organization: MOTOROLA 
Date: Wed, 18 Nov 1992 17:43:31 GMT

In article <4199@datasci.uucp> tgll@datasci.co.uk writes:
>   
>  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.
>  Where should I get CERT advisoiries from now?

The comp.security.announce newsgroups is still alive.  There was an article posted  
in it in the last 24 hours.

	_JJK
--
John Kinyon, Manager, Network Security, Motorola, IL06-S2022
1299 East Algonquin Road, Schaumburg, IL 60196-1077, USA
Internet: kinyon@corp.mot.com (NeXTmail accepted)
Phone: +1 708 576 0669,  Fax: +1 708 576 2259



Subject: CERT Advisory - Revised VMS Monitor Vulnerability
Date: 17 Nov 92 20:18:31 GMT
Distribution: inet
Organization: Computer Emergency Response Team : 412-268-7090


CA-92:18		     CERT Advisory
			   November 17, 1992
		    Revised VMS Monitor Vulnerability 

etc....
Xref: sparky comp.security.misc:1770 alt.security:4825