HDTenEightyP/NetNews huggingface dataset:
From: ignatz@wam.umd.edu (Mark J. Sienkiewicz)
Subject: Re: Secure setuid mount program: A model!
Organization: University of Maryland, College Park
Distribution: comp
Date: Thu, 20 Aug 1992 14:53:40 GMT

In article <BUZZ.92Aug19163601@toxicavenger.bear.com> buzz@fsrg.bear.com writes:
>In article <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@toxicavenger.bear.com (Buzz Moschetti) writes:
>
>   I believe this (mmount) to be secure.  Can someone claim otherwise?
>
>I should have more fully qualified who and what the "non-root" users were
>doing.  They happen to be operators who know the root password anyway.  We just
>want to provide them with a facility that they can use with their regular IDs
>in order to avoid having to become root.

By doing this, you implicitly assume that they don't log in and leave
their terminals unattended.  Because you have this program available,
each of their accounts has most of the same risks as the root account.

>In any case, the objective is to see if someone other than the trusted users
>can (ab)use the mmount facility to acquire a root privilege command interface
>of some sort.

Much of the program you posted is defending against attacks that a trusted
user probably won't use.  But it doesn't defend against attacks that
are about _what_ you are mounting/unmounting.  So it looks to me like
an su that doesn't need a password for certain users would be just as useful
and just as risky.

>The binary should be stripped and chmod-ed to 4711 to prevent strings(1)
>from being run on it.  It works just fine on SunOS 4.1.1 using the plain
>ol' /bin/cc C compiler.

If you have BSD-like groups, you might make a group of trusted users
and make this program 4710 belonging to that group.

>      uid_ent = getpwuid(uid);
>
>      if(strcmp(uid_ent->pw_name, trusted_user)) {
>	    (void) fprintf(stderr, "Only %s may run this program.\n",
>			   trusted_user);

I think it is unwise to hard code the name of the trusted user into
this program.  The trusted user may leave, being replaced by somebody
of the same name.  Or the program may be ported to another machine
where that name was used by someone else.  (Some software you get off
the net has this bug in it. :)

Mark S.
Organization: Queen's University at Kingston
Date: Thursday, 13 Aug 1992 20:13:36 EDT
From: Bob Burge <BURGER@QUCDN.QueensU.CA>
Newsgroups: comp.security.misc
Subject: Info

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.

Newsgroups: comp.security.misc
From: bianco@aelle.cs.odu.edu (Dave)
Subject: Re: SMTP SECURITY: A new (?) idea
Organization: Old Dominion University, Norfolk, VA, USA
Date: Thu, 13 Aug 1992 14:22:56 GMT

In article <1992Aug13.121416.7078@csd.uch.gr> kanagn@athina.cc.uch.gr (Kostas Anagnostakis) writes:

     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.

Well, pretty much anyone nowdays can become "root" by buying
their own machine.  It all boils down to the question of "Can
you trust the remote machine to tell you the correct mail header?"
You can't...

--
===============================================================================
David J. Bianco 			Systems Dude & Part time Illusionist
Old Dominion University    			<bianco@cs.odu.edu>
Dept of Computer Science,		"BORGer King:  We do it our way.
Norfolk, VA 23529			 Your way is irrelevant..."
===============================================================================
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.security.misc
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Date: 17 Aug 92 12:50:04 GMT
Organization: Northern Illinois University

In article <13914.Aug1500.33.5192@virtualnews.nyu.edu> brnstnd@nyu.edu (D. J. Bernstein) writes:
>Look, RFC 931 isn't perfect, but it's trivial to get running and it
>takes the edge off of annoyance attacks like ``telnet yourhost 25''.

  Now if I could only find something to take the edge of the pro-RFC931
propaganda nuisance attacks, which are far more common than the telnet
to port 25 nuisance attacks.
From: mark@hpcvxmsr.cv.hp.com (Mark Rowe)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 14 Aug 92 19:04:46 GMT
Article-I.D.: hpcvusn.1992Aug14.190446.11355
Reply-To: mark@hpcvlx.cv.hp.com
Organization: UDT-CV (ITO)

In a prior article John F. Haugh II writes:
> In article <1992Aug13.214823.19173@fx.com> franco@fx.com (Frank Minjarez) writes:
>>The definition in "Computer Security Basics" [published by O'Reilly & 
>>Associates] is a good one:
>>
>>	"A communication channel that allows a process to transfer information
>>	in a way that violates a system's security policy."
> 
> That definition is missing the "covert" aspect.  A "covert" channel is
> one which is not a commonly thought of communications mechanism.  A
> traditional communications channel, such as disk or serial device, would
> have some policy associated with it.  If that policy is violated, it is
> either a human error (that is, you hook up a serial port with a top secret
> label to the laptop computer you smuggled in) or a bug (the secret label
> on that port wasn't checked when a top secret document was output.)
> 
> A "covert" channel is some mechanism whose usual purpose is not the
> communication of data.  For example, sending data by modulating the system
> load.

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

Mark Rowe             email: mark@hpcvlx.cv.hp.com
Hewlett Packard       voice: (503) 750-3246
Corvallis, OR         FAX:   (503) 750-3788
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: comp.security.misc
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Date: 15 Aug 92 00:48:03 GMT
Organization: IR

In article <1992Aug14.195017.7009@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
> 	You can't count on RFC931 type stuff for "authentication". You
> can count on it for "information"; possibly useful, and possibly
> correct, but you really have no way of being sure.

Forget this concept of ``my RFC 931 server is there to provide
information/authentication/whatever to the other guy''.

Any administrator of a multi-user machine: If you run an RFC 931 server
then it helps *you*. *You* can find out---when the cops come calling---
which of your users was responsible for a connection. *You* get the
benefit if one of your users abuses a popular FTP server---and instead
of chopping off service to your entire host, the FTP administrator chops
off service to just that one user.

If you don't support the protocol then all your users remain anonymous
on the network. If someone receives a ``bad'' connection from your host,
the only person he can blame is you; you won't be able to ``point the
finger'' at the user who was responsible. It's your choice.

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

[snicker] I guess Kerberos isn't authentication, then.

The protocol actually used on port 113 is now called ``TAP'' (that's an
indecomposable acronym, like TELNET); it's a somewhat simplified variant
of the ``Authentication Server'' defined by RFC 931. So there's no more
``authentication'' in the name. Hasn't been for months, in fact.

---Dan
Newsgroups: comp.security.misc
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Re: Fake headers on Internet mail
Organization: Lehman Brothers
Date: Thu, 13 Aug 1992 14:55:19 GMT

sherer@lub001.lamar.edu writes:
>My question is, is there a way to masquerade as someone else in
>e-mail?

Its trivial; see the RFC for SMTP; all you have to do is pretend to be
another SMTP daemon; there is no authentication mechanism. Its all
ASCII; you can even do it yourself without writing any software by
connecting to the mailer daemon's port ant typing away.

>If so, is there anything I can do to prevent this from happening?

Not really, no. Eventually, everyone will be using public key
cryptography to sign their mail, but for the moment, there is no way
to really authenticate SMTP.

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.
From: buzz@toxicavenger.bear.com (Buzz Moschetti)
Newsgroups: comp.security.misc
Subject: Secure setuid mount program - possible?
Date: 19 Aug 92 13:26:22 GMT
Reply-To: buzz@fsrg.bear.com
Distribution: comp
Organization: Bear, Stearns & Co. Inc.

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?
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: comp.security.misc
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Date: 15 Aug 92 00:32:45 GMT
Organization: IR

In article <1992Aug14.191748.11505@reed.edu> nelson@reed.edu (Nelson Minar) writes:
> First of all it seems like not many sites are running RFC 931 type
> code.

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.

Not bad for a protocol which was barely used before last year.

Look, RFC 931 isn't perfect, but it's trivial to get running and it
takes the edge off of annoyance attacks like ``telnet yourhost 25''.
If you run a multiuser machine and you don't want your users to be
anonymous, try RFC 931. Suppose someone from dockmaster.ncsc.mil calls
you and tells you that one of your users was attacking that machine;
wouldn't you like to find out which user it was?

Contact rfc931-users-request@kramden.acf.nyu.edu to subscribe to the
rfc931-users list. Or poke around in ftp.lysator.liu.se:pub/tap.

---Dan
Newsgroups: comp.security.misc
From: dsiebert@icaen.uiowa.edu (Doug Siebert)
Subject: Re: SMTP SECURITY: A new (?) idea
Date: Thu, 13 Aug 1992 18:25:51 GMT
Organization: ISCA

In article <BIANCO.92Aug13092256@aelle.cs.odu.edu> bianco@aelle.cs.odu.edu (Dave) writes:
>In article <1992Aug13.121416.7078@csd.uch.gr> kanagn@athina.cc.uch.gr (Kostas Anagnostakis) writes:
>
>     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.
>
>Well, pretty much anyone nowdays can become "root" by buying
>their own machine.  It all boils down to the question of "Can
>you trust the remote machine to tell you the correct mail header?"
>You can't...

The ONLY possible benefit I could see to this idea would that it would stop
the forging of mail by telnetting to the SMTP port.  While people with root
access or Macs and PCs connected to the network could get around this, it does
take a bit more knowledge than simply telnetting to port 25 and forging mail
headers does.  This would at least slightly raise the difficulty factor for
wanna-bes on the Internet.

I can hardly see it being worth replacing all the software out there to
implement this, though.

-- 
/-----------------------------------------------------------------------------\
| Doug Siebert                             | "I don't have to take this abuse |
| Internet:  dsiebert@icaen.uiowa.edu      |  from you - I've got hundreds of |
| NeXTMail:  dsiebert@chop.isca.uiowa.edu  |  people waiting in line to abuse |
|     ICBM:  41d 39m 55s N, 91d 30m 43s W  |  me!"  Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Hi, I'm a .signature worm.  I've already copied myself into your .signature.
Newsgroups: comp.security.misc
From: meyers@leonardo.rtp.dg.com (Bill Meyers)
Subject: Re: Covert channel
Date: Wed, 19 Aug 92 22:34:15 GMT
Organization: Data General Corporation, RTP, NC.

In article <21382@rpp386.lonestar.org> jfh@rpp386.cactus.org (John F. Haugh II) writes:
[ ... ]
>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.

I believe this definition intends -- although I see it doesn't state --
that all system access controls and other security checks are functioning
correctly.  In other words, process A and process B _are_ obeying all of
the individual security rules imposed by the system, but somehow process
A manages to send, and process B to receive, information that the overall
system security policy would not permit to be sent directly.  (That's why
its "surprising to the authorities" <1992Aug15.162611.24659@sctc.com> :-)
From: brnstnd@nyu.edu (D. J. Bernstein)
Newsgroups: comp.security.misc
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Date: 15 Aug 92 00:33:51 GMT
Organization: IR

In article <1992Aug14.191748.11505@reed.edu> nelson@reed.edu (Nelson Minar) writes:
> First of all it seems like not many sites are running RFC 931 type
> code.

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.

Not bad for a protocol which was barely used before last year.

Look, RFC 931 isn't perfect, but it's trivial to get running and it
takes the edge off of annoyance attacks like ``telnet yourhost 25''.
If you run a multiuser machine and you don't want your users to be
anonymous, try RFC 931. Suppose someone from dockmaster.ncsc.mil calls
you and tells you that one of your users was attacking that machine;
wouldn't you like to find out which user it was?

Contact rfc931-users-request@kramden.acf.nyu.edu to subscribe to the
rfc931-users list. Or poke around in ftp.lysator.liu.se:pub/tap.

---Dan
Newsgroups: comp.security.misc
From: faigin@aero.org (Daniel P. Faigin)
Subject: Re: Covert channel
Organization: The Aerospace Corporation, El Segundo, CA
	<1992Aug14.190446.11355@hpcvusn.cv.hp.com> <21378@rpp386.lonestar.org>
	<1992Aug17.175123.3793@hpcvusn.cv.hp.com>
Date: Mon, 17 Aug 1992 19:50:56 GMT

On Mon, 17 Aug 1992 17:51:23 GMT, mark@hpcvxmsr.cv.hp.com (Mark Rowe) said:
> 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.  

Wrong, bucko! If properly implemented access controls would close the channel,
then the channel is a *flaw*, not a covert channel.

> MAC does not define a covert channel.  

I'd agree with you on this; however, covert channels other than MAC-type ones
aren't interesting. Why would I care about a DAC covert channel, when I just
just exploit the weaknesses inherent in DAC.

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

Judging intent, however, is quite difficult. Let's take some examples here.
Suppose I have a system where I can observe contention for a system resource,
say memory. I exploit this to transmit information. That's a clear channel.
Other cases aren't so clear. Look at Unix. There are many ways I can
communicate with processes. Are signals a covert channel? Is the use of ptrace
a covert channel? Is the use of the process number address space a covert
channel? 

It's not always so clear cut (alas).

Daniel
--
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
   "You can't be a rationalist in an irrational world. It isn't rational!"
	       Dr. Rance, in Joe Orton's "What the Butler Saw"
From: kjb@calmasd.prime.com (Ken Brucker)
Newsgroups: comp.security.misc
Subject: Re: Limiting reading of passwd to slow logins
Date: 12 Aug 92 18:07:48 GMT
Organization: Computervision - A Division of Prime Computer

In article <1992Aug12.050417.3340@qiclab.scn.rain.com>, leonard@qiclab.scn.rain.com (Leonard Erickson) writes:
> daniel@vcp1.vcp.monash.edu.au writes:
> 
>>I remember seeing sometime ago, a reference to limiting the frequency
>>with which someone could repeatedly login and test a password.

[ misc deleted about limiting access to passwd file ]
> 
>>Comments?
> 
> It's *much* simpler to just keep a record of invalid password attempts.
> If a login gets too many in a set period, the account is locked out
> for a period of time.
> 
> For example, on Novell Netware, if there are more than 7(?) invalid login
> attempts in 15 minutes, the account is locked out for another 15 minutes.
> (these are what I recall the defaults being). You can configure all of
> these parameters. 
> 
> Since all of these lockouts are both logged *and* sent to the console,
> this not only slows the attacks to a crawl, but leaves a trail a mile
> wide!

VMS uses a similar mechanism.  After a predetermined number of unsuccessful
logins, the account is temporarily unavailable for logins.  As the unsuccessful
login attempts continue, the length of time the account is unavailable
increases.  And the user attempting to login has no clue that this evasion is
taking place as the error reported to the user is the same one that is used
under normal circumstances.

Ken

-- 
-------------------------------------------------------------------------------
**  Ken Brucker -- VMS/Ultrix Systems Programmer/Mangler -- Computer Vision
 **  kjb@calmasd.Prime.COM  
  **  Practice Random Kindness and Senseless Acts of Beauty
Newsgroups: comp.security.misc
From: marc@watson.ibm.com (Marc Auslander)
Subject: Re: Secure setuid mount program: A model!
Date: Thu, 20 Aug 1992 18:53:59 GMT
Distribution: comp
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
	<BUZZ.92Aug19163601@toxicavenger.bear.com>
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

Your approach increases the vulnerability of the system to Trojan horse
attacks.  In theory, a user running as root should be extra careful
about what programs he runs, what's in his path, etc.

But now any program run by your authorized users in their normal use
of the system can execute the mount command.

--


Marc Auslander       (IBM)<marc@marc.watson.ibm.com>      914 784-6699
                     (Internet)<marc@watson.ibm.com>
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Fake headers on Internet mail
Date: 13 Aug 92 14:14:43 GMT

sherer@lub001.lamar.edu writes:
>My question is, is there a way to masquerade as someone else in e-mail?

It's easy.  If your machine is going to believe my machine when it says that
it's forwarding mail from x@y, then anyone who controls my machine can forge
mail to you from x@y.  This is an intrinsic problem which can only be solved by
cryptographic techniques.

However, it's worse than it might be because your system may very well make it
easy for users to forge mail to each other on the same machine.  I know mine
does; I can telnet to the smtp port and tell it I'm whoever I want.
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 21 Aug 92 18:42:27 GMT

>>>Why not implement SMTP allowing only connections from PRIVILEGED ports.
>
>A better solution can be to accept SMTP connections only from trusted
>hosts (and maybe limiting to a specified port too). Mail should be
>bubbled like name server queries are bubbled through the net.

Um, how does this help?  If you allow only connections from trusted hosts, but
you allow them to feed you mail that they got from hosts you don't trust, why
don't you just let those untrusted hosts feed you mail directly?  Or if you
assume that those hosts will be trusted by that machine you trust, how do you
go about setting up a sufficiently large network of these hosts that you can
talk to more than a few sites out there?  Why is this any easier of a task than
changing the sendmail protocol?
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Newsgroups: comp.security.misc
Subject: Re: Secure setuid mount program - possible?
Date: 19 Aug 92 14:25:42 GMT
Distribution: comp
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)

buzz@toxicavenger.bear.com (Buzz Moschetti) 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?
Additionally, you should make some provisions, that the filesystems
which could be mounted by the users could be only mounted with option "nosuid".
(This forbids setuid execution on those mountpoints).

If your system doesn't support that option, you are in trouble.
Its really no problem for an advanced user, to put a sh onto a
floppy, and make it setuid root. You could forbid access to the raw
floppy, so that nobody could fiddle around with an unmounted filesystem,
but that's no real security, as you could fiddle with the bits on any dump PC.

Sincerely,
Klaus Steinberger

--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
Newsgroups: comp.security.misc