HDTenEightyP/NetNews huggingface dataset:
From: rick@tessi.com (Rick Lindsley)
Subject: Re: SMTP SECURITY: A new (?) idea
Reply-To: rick@eaglet.rain.com
Organization: Test Systems Strategies, Inc., Beaverton, Oregon
Date: Thu, 13 Aug 1992 17:52:50 GMT

kanagn@athina.cc.uch.gr (Kostas Anagnostakis) writes:

    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.

As many others have pointed out, this isn't a universal solution.
However, when I was postmaster of a major company I attempted to
address this in an upward compatible way. I modified our SMTP to use
privileged ports, and note whether a message came in over a privileged
port. If it did not, it added:

Comment: This message was received over an unauthenticated port at <site>.

In this way, you might be able to tell if someone was spoofing a
message.  Of course, anyone who was running a workstation without the
modified SMTP also generated messages like this. It didn't interfere
with delivery, but did note when something "different" had happened. I
would guess about 30-40% of the outbound messages carried this warning,
owing to lazy sysadmins (who didn't upgrade) or machines that couldn't,
or machines morally or politically opposed to "software tampering".

Well, the users universally hated it. Said it made us look
unprofessional and insecure. Jumped all over my management until they
made me make the message go away.

Looks are much more important than security, after all!

Rick
From: sumargoh@serss0.fiu.edu (H. Sumargo)
Newsgroups: comp.security.misc
Subject: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Date: 15 Aug 92 19:20:16 GMT
Reply-To: sumargoh@fiu.edu
Organization: FIU Electrical & Computer Engineering


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.
Newsgroups: comp.security.misc
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: Fake headers on Internet mail
Organization: FWI, University of Amsterdam
Date: Fri, 14 Aug 1992 17:31:13 GMT

rickert@mp.cs.niu.edu (Neil Rickert) writes:

>In article <1513@lysator.liu.se> pen@lysator.liu.se (Peter Eriksson) writes:
>>
>>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).

>  If the mail forger is halfway competent, he will ensure that this
>authentication stamp reads:

>	(rfc931-sender: root@realhostid)

>  It is not at all clear to me why this buys you anything.

I don't understand what all this complaining against RFC 931 is about.
It's as trustworthy as reserved ports, yet people complain bitterly
about RFC 931, which has no impact on security, but hardly
about the use of reserved ports.

RFC 931 enables you to trace accesses to your site to
a <user@host> pair. This information can and has been used to
find compromised accounts at otehr sites.

RFC 931 helps against the most common SMTP fakes. Of course, it
doesn't guard against faking mail. But it is no longer
just ``telnet smoehost smtp'', they must do more than that.
Locally, the number of faked messages has dropped of dramatically.,

Casper

-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
From: horde@reed.edu (Mr. Heiji Horde)
Newsgroups: comp.security.misc
Subject: Re: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Date: 16 Aug 92 16:42:37 GMT
Article-I.D.: reed.1992Aug16.164237.25937
Organization: Twisted Genius Rehabilitation Center, a Division of MHE

Maximum security? That's easy. Don't take it out of the box. :) :) :)

For something slightly less secure, take it out of the box, set it up,
  but don't plug it into the network. :) :) :)

	-Heiji
	 "I've been hacking all night, my brain is toast."


-- 
===========================================================================
 Mr. Heiji Horde    (Non NeXT mail only please)     e-mail: horde@reed.edu
   All insane acts are done in affiliation with Madd Hacker Enterprises
    "Don't explode in front of my parents, it wouldn't look good." - M.H.
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 15 Aug 92 04:32:44 GMT
Organization: River Parishes Programming, Austin TX

In article <1992Aug14.190446.11355@hpcvusn.cv.hp.com>, mark@hpcvxmsr.cv.hp.com (Mark Rowe) writes:
> Disagree, any channel can be a covert channel regardless of whether or
> not it is normally thought of as a communication mechanism.  A trojan
> horse that acquires classified information formulates it into an email
> messages where the information is imbedded in seemingly harmless text
> and then uses the system mail system to send it out, is certainly
> using a standard communication mechanism.  What makes this a "covert"
> channel is that the message is hidden or disguised or masquerading as
> something else as opposed to an overt channel where the information is
> obvious and undisguised (or disguised in some understood manner such
> as encrypting).

I'd argue that if the mechanism is designed to transmit data (for example,
a system mailer) that the mechanism had better know the sensitivity of
all of the data in the message.

A trojan horse that collects classified data will be executing with a
MAC label that dominates the data that has been collected.  The data that
the trojan horse outputs will all have a MAC label that dominates the
trojan horse process which creates the output data.

Suppose for a moment that the trojan horse creates a mail message with
bogus headers.  Either that entire message, or the data in the bogus
headers, must be labeled appropriate.  The mailer would have to be broken
to take a message with a MAC label and give that data to a process
with some other MAC label which does not dominate the MAC label of the
message itself.

I had this discussion back when I was starting to learn about MAC.  My
question was, what is to prevent a user from putting the confidential
data in the filename and then doing an "ls" of the directory?  The answer
was that you can only write a filename into a directory if the directory
has the appropriate label.  I think this applies here as well.  You can
only put that sensitive data into the header if the entire message, or
that field, has the appropriate label.  And you can only read that data
if your process' label dominates the message's label.

What you are describing sounds more like busted MAC than a covert
channel.
-- 
John F. Haugh II                   | Life's Little Instruction Book:
Ma Bell: (512) 251-2151            | "#138.  Learn Spanish.  In a few years,
UUCP: ...!cs.utexas.edu!rpp386!jfh |  more than 35% of all Americans will speak
Domain: jfh@rpp386.cactus.org      |  it as their first language."
Newsgroups: comp.security.misc
From: lemson@ux1.cso.uiuc.edu (David Lemson)
Subject: Re: trapdoor passwords
Organization: University of Illinois at Urbana
Date: Sat, 15 Aug 1992 15:28:26 GMT

a74k110@titan.ucc.umass.edu (Chris Lloyd) writes:

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

>As with any computer, the NeXT has it's share of security holes, you're kidding
>yourself if you think you most computers are secure out of the box.

And there have been CERT advisories that have cleaned up the most
blatant holes, such as the rexd hole (the 'hole' is that NeXT
shipped OS 2.x machines with rexd enabled...their rexd isn't any less
secure than anyone else's), and the rdist hole (that hit 99% of
every BSD 4.2 or 4.3 derived system).  
NeXTs come with a manual (paper and on-line) that describes security
and how to make your machine more secure.  

-- 
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: dbushong@wang.com (Dave Bushong)
Subject: Re: Info
Organization: Wang Labs, Lowell MA, USA
Date: Fri, 14 Aug 92 18:42:18 GMT

Bob Burge <BURGER@QUCDN.QueensU.CA> writes:

>If this is the wrong group, ... well, you know the drill!

>I'm looking for info on securing directories - hiding them, etc.  If there is
>a good book, or program, please let me know.

Did you have a particular O/S or platform in mind?

Dave
-- 
Dave Bushong, KZ1O@K1UGM.MA
Wang Laboratories, Inc.
Internet: dbushong@wang.com
Newsgroups: comp.security.misc
From: stehman%citron.cs.clemson.edu@hubcap.clemson.edu (Jeff Stehman)
Subject: Re: Tracking mail connections ( Was Re: Fake headers on Internet mail )
Reply-To: stehman%citron.cs.clemson.edu@hubcap.clemson.edu
Organization: Clemson University
Date: Mon, 17 Aug 1992 14:57:59 GMT

From article <Bt178K.HL@ux1.cso.uiuc.edu>, by lemson@ux1.cso.uiuc.edu (David Lemson):
> rjq@phys.ksu.edu (Rob Quinn) writes:
> [ query about excessive vrfy's ]
> 
> 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 know netfind uses EXPN, so I doubt it does VRFY's, too.  When I needed a
quick and dirty method for checking smtp connections on SunOS, I saved
time-stamped output from netstats that contained the string smtp.  When the
connections involved someone typing in commands, poling netstat once a minute
caught them.  Otherwise it took intervals of 4-5 seconds.  Really quick,
really dirty, really worked.


--
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: john@iastate.edu (John Hascall)
Subject: Re: How secure is chroot? 
Organization: Iowa State University, Ames, IA
Date: Tue, 18 Aug 1992 16:32:27 GMT

gary@nexnix.demon.co.uk (Gary Howland) writes:
}uaa1006@dircon.co.uk writes:

}>I have a program which is SUID root, which runs chroot and then
}>sets the UID of the process to that of the user, and spawns 
}>/bin/sh (which is present under the chroot path).

}>My question is....how secure is this?

}I haven't tried this myself (maybe I will in the next day or so),
}but if a user gains root privileges, whats to stop them mknod'ing a
}disk device and accessing the rest of the world via that?
}(or have I overlooked something?)

What you do have to worry about is making sure that the permissions on
your new root directory (and other important dirs below it, like "/dev"
mentioned above and "/etc") prevent the user from writing into it.
For example:

	% yournewrootpgm
	% mkdir /etc
	% echo "root::0:1:System PRIVILEGED Account:/:/bin/csh" >/etc/passwd
	% su   (which they may have to copy in too, but you get the idea)

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]
Newsgroups: comp.security.misc
From: jmcarli@srv.PacBell.COM (Jerry M. Carlin)
Subject: Re: Secure setuid mount program - possible?
Organization: Pacific*Bell
Distribution: comp
Date: Wed, 19 Aug 1992 15:28:00 GMT

The following were derived from Matt Bishop's "How to Write a Setuid
Program" paper:

Isolate code which needs to be run setuid or setgid in a separate 
executable or function when possible.

Reset userid and groupid to that of the person running the program as soon 
as possible.

Be as restrictive as possible in selecting the UID and GID.

Reset effective UID and GID and close all unnecessary file
descriptors before calling exec, popen, system and any other command
that invokes another process.

Carefully validate any user supplied arguments to exec, system or popen.

Make no assumptions about environment variables. At a minimum, verify or
override PATH, IFS and SHELL. In some versions of UNIX,
overriding environment variables for shared libraries such as
LD_LIBRARY_PATH and LD_PRELOAD on SUN is also necessary.

It is not safe to use creat or functions that use creat for locking.

Catch ALL signals except SIGKILL and SIGCLD.

Check all function returns for errors and abort if anything is wrong.

Programs interrupted during file creation can leave a file owned by the 
effective user rather than the real user. Do not assume that a creat 
followed by a chown is safe.

Strip the program and install it with other mode "1" so strings
or a similar program cannot be used on it.

Consider logging the real uid, tty, time executed and program name each 
time the setuid program is run.

-- 
Jerry M. Carlin	(510) 823-2441 jmcarli@srv.pacbell.com
Alchemical Engineer and Virtual Realist
Newsgroups: comp.security.misc
From: john@iastate.edu (John Hascall)
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Organization: Iowa State University, Ames, IA
Date: Mon, 17 Aug 1992 04:13:38 GMT

rouilj@dl5000.bc.edu (John P. Rouillard) writes:
}>   Why don't I trust root? I don't know you. And, on the majority of UNIX
}>   machines it is fairly simple for any user to become root.

}Well, how simple it is depends on the system. Currently I have systems
}that can be rebooted into root mode.  However, when that is done, the
}experimental rfc931 server (no, it is not available for public access
}or use yet) that runs on that machine loses its encryption key. Thus
}by getting an rfc931 identifier that says "rouilj" I can tell you
}immediately that it isn't a valid identifier since there was no way
}you should be able to get an unencrypted identifier out of one of my
}properly operating servers.  Thus there is a high degree of
}probability that that letter was forged.

If I were the user who booted into root mode I would also fire up
a simple daemon on the rfc931 port which always answered every
request with "SDdf;sadf344sagfarg" (or whatever identifier I had
seen myself recently in mail to me).

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 18 Aug 92 12:40:38 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Aug17.175123.3793@hpcvusn.cv.hp.com> mark@hpcvlx.cv.hp.com writes:
>It is true that properly implemented MAC would prevent the use of my
>example.  That does not in any way prevent this from being an example
>of a covert channel, it's simply a covert channel that can be eliminated
>by MAC.  MAC does not define a covert channel.  What defines a covert
>channel is how the data is being transmitted.  It is either overt or
>covert.  An overt channel is a channel that transmits data in a known
>manner as intended by the system administrators.  A covert channel is
>anything else.

Given the example you provided, putting something in the mail headers
is not an example of a covert channel.  A mail system which permits the
user to place data anywhere in the mail message (including your
hypothetically concealed header data) must be assumed to be used.  Your
example would make concealing data in nursery rhymes that the system
administrator doesn't understand a "covert channel".

The definition which I have always used for "covert channel" is the one
straight out of the Orange Book - "covert channel - A communications
channel that allows a process to transfer information in a manner that
violates the system's security policy."  If you are permitted to change
the mail headers, doing so cannot violate the system's security policy.
-- 
John F. Haugh II                   | Life's Little Instruction Book:
Ma Bell: (512) 251-2151            | "#138.  Learn Spanish.  In a few years,
UUCP: ...!cs.utexas.edu!rpp386!jfh |  more than 35% of all Americans will speak
Domain: jfh@rpp386.cactus.org      |  it as their first language."
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: comp.security.misc
Subject: Re: Security Policy
Date: 20 Aug 92 21:02:37 GMT
Organization: Sex, UNIX & Rock 'n Roll

Why not just use the good old fascist method ? It's used by 90% of
the sites connected, so it's been proven to be effective (although not
very satisfactory for the users).
In general, start out with no rules. If someone offends or annoys the
operator (detection is based on luck/chance), a punishment is found,
based on a whim, the mood of the operator at the moment, etc.
Don't bother with letting the user explain why he ran the 'crontab'
command, if he knows how it works, he's obviously a hacker, and you'd
better shut them up. Ridiculize the offender in public, eg. if he
uses too many diskspace, or uses ftp too much, remind users in the
/etc/motd to be careful with ftp'ing GIF's, or they will end up
as J. Random User, who lost his account for using the company's system
for collecting pornography.

Right now, you must think I'm crazy, that nobody has this system.
Well, you are wrong, most system admins start out this way, with
no written rules, rules that are hastily created and applied to cover
past actions. The EFF can tell you thousands of stories, collected
from people who lost their account on a whim of the mighty root.

Rob
-- 
/-----------------------------------------------\	Never		   ,==.
| Rob J. Nauta, UNIX computer security expert.	| 	 Apologize,	  /@  |
| rob@wzv.win.tue.nl, Phone: +31-40-837549	| 	  Never		 /_  <
| Feel free to email me for free advice		|	   Explain.	=" `g'
Newsgroups: comp.security.misc
From: boebert@sctc.com (Earl Boebert)
Subject: Re: Covert channel
Organization: SCTC
Date: Sat, 15 Aug 1992 16:26:11 GMT

The definition used by many people is: "transmission of data in a
manner surprising to the authorities."  The background this definition
is part of the esoterica of computer security, and not usually divulged
to outsiders or the faint of heart :-)

Earl
From: raoul@eplunix.UUCP (Nico Garcia)
Newsgroups: comp.security.misc
Subject: Re: trapdoor passwords
Date: 12 Aug 92 13:58:55 GMT
Organization: Eaton-Peabody Lab, Boston, MA

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.

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.
-- 
			Nico Garcia
			CIRL/MEEI
			eddie.mit.edu!eplunix!raoul
From: ho@cs.arizona.edu (Hilarie Orman)
Newsgroups: comp.security.misc
Subject: Covert channel
Date: 12 Aug 92 23:44:17 GMT
Organization: U of Arizona, CS Dept, Tucson

In article <1992Aug12.204649.4110@osf.org>, karger@osf.org (Paul A.
Karger) writes: 
> Covert channels involve illicit communications between two processes,
> a transmitter process that is running a Trojan horse, and a receiver
> process that belongs to a spy.

You seem to imply that it can't be a covert channel without intent.
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, a concept further divided into storage and
timing channels.

If you don't agree, what alternate term would you use to describe the
password inference problem originally described?
Xref: sparky comp.security.misc:1069 alt.security:4194
From: wietse@wzv.win.tue.nl (Wietse Venema)
Newsgroups: comp.security.misc,alt.security
Subject: Re: Secure setuid mount program: A model!
Date: 20 Aug 92 10:19:09 GMT
Organization: Eindhoven University of Technology, The Netherlands

buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

>Here is a "model" safe setuid program -- thanks to all who sent
>me mail with suggestions.  Features include:
>[...]
>Can anyone add anything else?  Are we secure yet?

Besides closing file descriptors > 2, you will want to make sure that
file descriptors 0,1,2 are open.  Strange things can happen otherwise.
The following code fragment should do:

#include <sys/types.h>
#include <sys/stat.h>
 ...

    struct stat st;
    int     i;

    /* Make sure fd 0,1,2 are open. */

    for (i = 0; i < 3; i++) {
	if (fstat(i, &st) == -1 && open("/", 2) != i) {
	    perror("open /");
	    exit(1);
	}
    }
Newsgroups: comp.security.misc
From: jgd@fomalhaut.csd.uwm.edu (John G Dobnick)
Subject: The Perl passwd program
Originator: jgd@csd4.csd.uwm.edu
Organization: U of Wis - Milwaukee, Computing Services
Date: Sat, 22 Aug 1992 04:32:12 GMT


A question and a request.

Does anyone use Larry Wall's Perl passwd replacement?  (Besides Larry,
that is.)

If you do, could you send me copies of your "badpats" and "badwords"
files?  I'm trying to build up a useful exclusion list for our users,
and am not above avoiding wheel-reinvention.

[In case you haven't guessed, we use it here, under ULTRIX 4.2A, with the
 ENHANCED security option.  We've "modified" the original perl passwd
 a bit, _and_ have added a "crypt16" function to perl, due to DEC silliness.
 Yes, we couldn't resist "hacking" perl. :-) ]

Thanks much.
-- 
John G Dobnick                          ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire

Newsgroups: comp.security.misc