HDTenEightyP/NetNews huggingface dataset:
From: pen@lysator.liu.se (Peter Eriksson)
Subject: Re: Fake headers on Internet mail
Organization: Lysator Academic Computer Club, Linkoping University, Sweden
Date: Thu, 13 Aug 1992 23:06:28 GMT

nickel@cs.tu-berlin.de (Juergen Nickelsen) writes:

>In article <1992Aug13.164814.11389@aio.jsc.nasa.gov>
>Barrett_Jim@ial3.jsc.nasa.gov (Jim Barrett) writes:

>> I have observed that some mailer daemons are able to detect certain fraudulent
>> transcations, and while accepting the "From:" information in the incoming
>> message, will also include an "Apparently-From:" line in the message header. 
>> Most mailers that I have played with believe the "From:" information fed to
>> them without a murmur of doubt.  

If one applies the Sendmail patch in pub/ident/patches at ftp.lysator.liu.se
or pub/networking/ident/patches at ftp.uu.net, then all mail that are received
via the SMTP TCP/IP port will, if the sending host is running an IDENT server,
have a line "(rfc931-sender: realuserid@realhostid)" added to the "Received: "
line in the message header. (Where "realuserid" is the user name of the luser
at "realhostid" who initiated the connection to the SMTP port).

Servers that implement the IDENT (the successor to RFC931) protocol can also
be FTP'd from ftp.lysator.liu.se (in pub/ident/servers) or from ftp.uu.net
(in pub/networking/ident/servers). There are servers for various Unixes and
even a server for DEC TOPS-20. The latest version of the stuff is always
at ftp.lysator.liu.se.

/Peter
--
Peter Eriksson                                              pen@lysator.liu.se
Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                           I'm bored. Flame me.
From: kanagn@athina.cc.uch.gr (Kostas Anagnostakis)
Newsgroups: comp.security.misc
Subject: SMTP SECURITY: A new (?) idea
Date: 13 Aug 92 12:14:16 GMT
Organization: Computer Science Department, University of Crete HELLAS
X-Newsreader: Tin 1.1 PL3

Hello security freaks,

  I had an idea I would like to share with you. Why not implement SMTP
  allowing only connections from PRIVILEGED ports. As far as I have gone
  into the matter, this would be a solution because a normal user is
  not able to use a socket port < 1000 so his attempt to connect to
  a SMTP server will fail.
 
  If someone wishes to start working on the idea, I would like to help.
 
  Best regards,
  Kostas Anagnostakis
 
Newsgroups: comp.security.misc
From: dhesi@cirrus.com (Rahul Dhesi)
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Organization: Cirrus Logic Inc.
Date: Sat, 15 Aug 1992 17:28:02 GMT

In <1992Aug14.195017.7009@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus
J. Ranum) writes:

>	A good metric to use to determine if you have "authentication"
>is to ask yourself if a bank would let you make withdrawals based on
>it.

By this reasoning neither fingerprints nor digital signatures are
authentication -- unless you know of a bank that allows withdrawals based
on these.  The only authentication method accepted by banks today is a
signature on paper.  All other mechanisms are used for provisional
authentication, with the signature on paper being the final authority in
case of a dispute.

Let's be realistic.  Banks don't do email withdrawals.  But one can
hypothesize a bank on the Internet.  Suppose it has name service set
up such that host names can't be forged.  (This may actually turn out
to be a bigger problem than username authentication.)  Then the bank
might well allow withdrawals based on email messages, provided the
message came from (a) a host that made a direct connection with the bank,
(b) was running rfc931, and (c) whose sysadmin had a contract with the
bank that in the case of rfc931-authenticated email from any of a
specific list of users, the sysadmin would guarantee the validity of the
rfc931-authenticated username.

Between any two hosts both on the Internet, a message transfer generates
only a single Received: header.  You get multiple headers only when (a) a
site is not directly on the Internet, or (b) when mail routing is done by
a host other than the originating host.  And you have one initial
Received: header generated on the originating host.  In the case of (b),
if mail routing remains within the same organization, the Received:
headers can be made reliable if the organization properly controls all
machines involved.  The only possible doubt arises when somebody is not
on the Internet.

So with appropriate controls, the information in the Received: headers
*can* be made reliable.  I see no reason why we won't have email banking
in the future, quite possibly using username authentication with rfc931,
the only condition being that message transfer be done by a chain of
hosts each of which is under proper administrative control.

Host name authentication may prove to be more difficult than username
authentication.
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 13 Aug 92 14:22:49 GMT

kanagn@athina.cc.uch.gr (Kostas Anagnostakis) writes:
>Why not implement SMTP allowing only connections from PRIVILEGED ports.

Three problems:

1) If you start doing this on your machine, you will stop being able to
exchange mail with people who aren't doing this.  I assume that sendmail
usually connects from unprivileged ports.  On our machine (running zmailer)
it looks like sendmail isn't even setuid.

2) The concept of "privileged port" is not universal to TCP; many machines
don't even have the concept of privileged users, and even some which do don't
have the concept of privileged ports.  So anyone can connect from a "privileged
port" on these machines.

3) Why do you trust privileged users more than other people?  I'm very wary of
systems which appear to increase the authenticity of communications without
necessarily doing so.  If someone forges a mail message in my name which says
something that it's important for me to establish that I did not say, I would
like to be able to say "everyone knows that forging e-mail is easy"; it would
be terrible for others to be able to say "e-mail authenticity is guaranteed
these days since smtp allows only connections from privileged ports".  These
forgers will include system administrators and also people who break in to
privileged accounts.


There are cryptographic techniques only suffering from the first problem.  If
we're going to lose compatibility, we should do it right.
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 13 Aug 92 21:25:31 GMT

>> These forgers will include system administrators and also people who break
>> in to privileged accounts.
>
>As a former sysadm, I take offense at this remark and I think many current
>ones will, too.  I will give you the benefit of the doubt ...

I did not mean this comment the way you are taking it.  I apologize.  Thanks
for the benefit of the doubt.

In fact, I meant somewhat the opposite.  While I was writing that article, it
occurred to me that some people would not take the threat too seriously because
they would assume that sysadmins are trustworthy.  Thus I felt it important to
point out that people breaking in to privileged accounts (e.g. cracking root)
were in a position to forge privileged-port-smtp mail too.
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Security Policy
Followup-To: alt.flame
Date: 21 Aug 92 19:16:06 GMT

>imp@solbourne.com (Warner Losh) writes:
>>You are right.  I've seen this at many places.  My brother never tires
>>of telling me the latest stupid behaviour by the system admins at his
>>school.  It is completely revolting.

dsm@prism.gatech.EDU (Danny McGurl) writes:
>Well, on the other side of the coin, students at a school tend to have
>a one sided view of what's going on.  It's sometimes just a lack of
>communication.  Sometimes of course it's justifiable.  If you start looking
>for evil in every action of someone, you will find it.

By this last sentence I presume you are referring to improper discipline
against students arising from sysadmins' overactive snooping?
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: comp.security.misc
Subject: Re: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Date: 17 Aug 92 10:50:20 GMT
Organization: Sex, UNIX & Rock 'n Roll

In article <1939@kluge.fiu.edu> sumargoh@fiu.edu writes:
>
>The subject said it all.  I believe that there is some publish guide line that I can
>download from some ftp sites.  Could someone give the pointer and send to 
>            sumargoh@serss0.fiu.edu
>
>Thanks a lot for the response.

I can give you some hints myself:
- Don't connect it to a network, don't connect modems or Ethernet
- Don't let anyone use it. If this is not desirable, let only those
  people use it who need to use it. Also enforce a policy for physical
  access control.
- Have a good passwd policy, force users to choose good passwords.
- Install all patches available, be sure you know what is fixed and
  what is unfixable.
- Put a good sysadmin in charge, not some tape-changing drone, but an
  interested hacker-like programmer-type user.

Rob
-- 
/-----------------------------------------------\			   ,==.
| Rob J. Nauta, UNIX computer security expert.	| 			  /@  |
| rob@wzv.win.tue.nl, Phone: +31-40-837549	| 			 /_  <
| Feel free to email me for free advice		|			=" `g'
Newsgroups: comp.security.misc
From: adb@geac.com (Anthony DeBoer)
Subject: Re: Secure setuid mount program - possible?
Date: Wed, 19 Aug 1992 17:45:04 GMT
Distribution: comp
Organization: Geac Computer Corporation

In <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@fsrg.bear.com writes:
>We wish to make mount and umount available to two or three non-root accounts.
>The plan is create a C code fork/exec wrapper that does the following:
>
>	1.  Verifies that the euid is root.
>	2.  Verifies that the uid is one of the "privileged" users.
>	3.  Forces argv[0] to be /usr/etc/(u)mount.
>	4.  Does an execv(3) -- NOT execvp(3) -- to run the argv.
>
>The program itself is setuid root, mode 4711, so that the binary image
>cannot be copied and compromised:
>	-rws--x--x  1 root        24576 Aug 17 11:51 mmount
>
>I believe this to be secure.  Can someone claim otherwise?

What happens when your user come happily trotting along with media
containing a setuid-root program of their own devising?  There are a
number of ways they could set up such a disk, and a whole lot of things
they could do after mounting it :-(.

Are you controlling the allowable mount-points, such that they can't
overmount /etc with a disk containing a passwd file with no root password?
Or overmount /usr/etc with a umount of their own devising which your
setuid program will now run for them with euid=0?

Are you verifying that umount requests are not for something that's
supposed to stay mounted?

Note also that one of the basic principles of paranoia is that no list of
possible attacks can ever be exhaustive.  There are quite a number of
general precautions and potential loopholes with any setuid-root program,
in addition to the above few points unique to (u)mount in particular.
-- 
Anthony DeBoer       adb@geac.com | uunet!geac!adb | GEM: ANTHONY.DEBOER
Newsgroups: comp.security.misc
From: rsnyder@atl.ge.com (Bob Snyder)
Subject: Re: trapdoor passwords
Organization: GE Aerospace, Advanced Technology Labs
Date: Mon, 17 Aug 1992 16:50:12 GMT

In article <1259@eplunix.UUCP> raoul@eplunix.UUCP (Nico Garcia) writes:
>In article <BssuF5.G4@ibmpcug.co.uk>, gtoal@ibmpcug.co.uk (Graham Toal) writes:
>> Has anyone heard a rumour circulating that some crackers have found a
>> trapdoor password that lets people on to Next machines with root
>> privs?  I told the person I heard it from that it sounded like total
>
>I heard this one too: I was told that there was a "backdoor". This struck me
>as reasonable, since the NeXT was developed for fun and the NetInfo programs
>that handle passwords are not obviously accessible and do not come with
>source code. I mentioned the rumor to our NeXT owner here at the lab, and
>asked for more details.

I would probably disagree with the statement that NeXT's were developed for
"fun," which implies that you do not consider the NeXT to be a "real" machine.

>Upon checking, my rumor source forwarded a copy of a note from a private bbs
>that complained of security *holes* on NeXT, but made no mention of actual
>backdoors. I then explained to my rumor source the distinction between the
>two, and have heard nothing further.

I would be interested in hearing about these bugs.  I know of the rdist
problem; although that wasn't a NeXT-only problem.  I also fixed the obvious
permission problems with some of the directories as shipped.  What are the
other bugs/security holes?

Bob
-- 
Bob Snyder, Computing Services, GE Aerospace, Advanced Technology Labs
rsnyder@atl.ge.com, (609) 866-6672, FAX: (609) 866-6397, DialComm 8*777-6672
Newsgroups: comp.security.misc
From: newsham@wiliki.eng.hawaii.edu (Timothy Newsham)
Subject: Re: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Organization: University of Engineering, College of Engineering
Date: Tue, 18 Aug 1992 06:51:38 GMT

In article <3731@wzv.win.tue.nl> rob@wzv.win.tue.nl (Rob J. Nauta) writes:
>In article <1939@kluge.fiu.edu> sumargoh@fiu.edu writes:
>>
>>The subject said it all.  I believe that there is some publish guide line that I can
>>download from some ftp sites.  Could someone give the pointer and send to 
>>            sumargoh@serss0.fiu.edu
>>
>>Thanks a lot for the response.
>
>I can give you some hints myself:
[...]
>- Put a good sysadmin in charge, not some tape-changing drone, but an
>  interested hacker-like programmer-type user.
>
>Rob
>-- 
someone like.....   ROB?   ;)

(quick someone get this man off the street)
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.security.misc
Subject: Re: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Date: 18 Aug 92 22:22:44 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <3731@wzv.win.tue.nl> rob@wzv.win.tue.nl (Rob J. Nauta) writes:
>In article <1939@kluge.fiu.edu> sumargoh@fiu.edu writes:
>>
>>The subject said it all.  I believe that there is some publish guide line that I can
>>download from some ftp sites.  Could someone give the pointer and send to 
>>            sumargoh@serss0.fiu.edu
>>
>>Thanks a lot for the response.
>
>I can give you some hints myself:
>- Don't connect it to a network, don't connect modems or Ethernet
   
Or at least use dial-out only connections with uucp (and pos cu) only,
and only allow a very limited range of commands (rmail and rnews making
sure you have set news and mail up well) on the uucp link.

>- Don't let anyone use it. If this is not desirable, let only those
>  people use it who need to use it. Also enforce a policy for physical
>  access control.
>- Have a good passwd policy, force users to choose good passwords.
>- Install all patches available, be sure you know what is fixed and
>  what is unfixable.
>- Put a good sysadmin in charge, not some tape-changing drone, but an
>  interested hacker-like programmer-type user.

All the rest is spot on.

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.22|| ALL MAIL FREE.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || US hotrod motor groups.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Covert channel
Date: 13 Aug 92 14:09:36 GMT

ho@cs.arizona.edu (Hilarie Orman) writes:
>I've always relied on the notion of information flow - if the writer
>of the transmitter program did not specify the information as an
>output, and if a receiver program can detect the information, then you
>have a covert channel,

But the usual covert channel demonstration involves having a transmitter
program which was written just for the purpose of transmitting the data.
This is surely output, even if it's not output to a file.
From: bush@ecs.ox.ac.uk (Mark Bush)
Newsgroups: comp.security.misc
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 13 Aug 92 16:50:30 GMT
Organization: Oxford University Computing Laboratory

In article <1992Aug13.151514.14735@hal.com> ables@hal.com (King Ables) writes:
#From article <1992Aug13.102249.16853@jarvis.csri.toronto.edu>, by flaps@dgp.toronto.edu (Alan J Rosenthal):
#> These
#> forgers will include system administrators and also people who break in to
#> privileged accounts.
#
#As a former sysadm, I take offense at this remark and I think many current
#ones will, too.  I will give you the benefit of the doubt and assume you are
#not trying to say that sysadms are, by nature, underhanded individuals (which
#is what it sounds like) but that you simply chose a poor way of trying to

It didn't sound that way to me.  He said that there will be some sys admins
among the forgers.  This is highly likely.

#say that only privileged users would be able to accomplish such a feat, but
#that many people could get these privileges in different ways.

You don't need any privileges to forge SMTP mail (on most systems).  This is
not because of SMTP itself, but because, for example, any process with any
privilege can connect to an SMTP port (again - most systems) and tell it who
the mail is from, etc.  As has been pointed out, any authentication
mechanism must be shared by the entities which which to communicate and
encryption is likely to be the best method (eg, using Kerberos).

However, if you protect sendmail (or whatever) access on your system,
there's likely to be plenty of places that don't where someone can connect
to and claim to be sending mail from you.

Life is hard.

Mark
Newsgroups: comp.security.misc
From: macphed@dvinci.USask.Ca (Ian MacPhedran)
Subject: Re: Fake headers on Internet mail
Originator: macphed@dvinci
Reply-To: macphed@dvinci.USask.Ca
Organization: University of Saskatchewan
Date: Wed, 19 Aug 1992 01:06:51 GMT

From article <1992Aug12.151404.1424@lub001.lamar.edu>, by sherer@lub001.lamar.edu:
> This is the first time I've posted to News, so please be kind.
> 
> I have been informed of a suspected problem in Internet mail by one of my
> operators. He received some mail from some valid users at our site, and he
> responded to those messages. The people that supposedly sent the messages
> claimed they never sent them. Then he (the operator) received e-mail from
> himself on a VMS node to his account on our ULTRIX node. He did not send the
> mail himself, and he checked the last login time on the account on the VMS
>+ node
> and found that no one had logged in on that account in quite a while, so he
>+ did
> not believe anyone figured out his password.

 Most of the replies have been w.r.t. SMTP mail tricking. Since this is 
 between two DEC machines, the mail could also have been sent by DECnet
 mail (Mail 11) which is also easily tricked by any user with extra time
 to waste. If you have copies of the mail headers, you can track down
 which scheme was used, but not much else.

Ian.
----------------------------------------------------------------------------
Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan.
2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0
macphed@dvinci.USask.CA  macphedran@sask.USask.CA
-- 
----------------------------------------------------------------------------
Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan.
2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0
macphed@dvinci.USask.CA  macphedran@sask.USask.CA
Newsgroups: comp.security.misc
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Mon, 17 Aug 1992 01:38:49 GMT

>In June 1992, about 1 packet out of every 7000 across the NSFNET T1
>backbone was for port 113 (auth). For comparison, about 20 packets out
>of every 7000 were for port 79 (finger). Only thirty named ports had
>higher packet counts than port 113. See nic.merit.edu.

	What kind of conclusion should be drawn from this? It doesn't mean
that because TAP has created a lot of traffic that it is either particularly
useful or widely used. This sounds like a variation of the "eat sh**,
after all, 30 billion flies can't all be wrong" argument used to justify
Microsoft Windows.

mjr.
Newsgroups: comp.security.misc
From: lemson@ux1.cso.uiuc.edu (David Lemson)
Subject: Re: Tracking mail connections ( Was Re: Fake headers on Internet mail )
Organization: University of Illinois at Urbana
Date: Sat, 15 Aug 1992 15:33:42 GMT

rjq@phys.ksu.edu (Rob Quinn) writes:

>   ----- Transcript of session follows -----
><<< vrfy rjj
>550 rjj... User unknown
><<< quit

> I know some of these are innocent checks, I do it all of the time myself,
>but about a month ago I had about a dozen of these in one day, and several
>the next day. How can I tell where they came from? Do any of the public
>sendmails provide better information? Anyway to log the VRFY's that succeed
>too?

I believe that the 'netfind' program does this as well as fingers to
find e-mail addresses.  For more info, you can ftp to
bruno.cs.colorado.edu, or telnet there and login as 'netfind'.

I also believe that the tcp_wrapper package will do logging on smtp
daemon connections to log where they came from (and from whom, if
the remote site is running an authd - RFC931 daemon).  I know it
does this for telnetd and rlogind and so on, I think it said it had
support for sendmail, too.  You can ftp it from
cert.sei.cmu.edu in the /pub/tools directory.
-- 
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: comp.security.misc
From: pgreen@zia.aoc.nrao.edu (Philip Green)
Subject: Security Policy
Organization: National Radio Astronomy Observatory, Socorro NM
Date: Wed, 19 Aug 92 19:51:16 GMT

I am in the process of creating a security policy for our
organization. I am interested in see what others have done 
and what you may or may not have learned from it. If anyone
has a Security Policy I could have a copy please let me 
know.

Thanks
-- 
Phil Green                           	pgreen@aoc.nrao.edu
NRAO					505.835.7294