HDTenEightyP/NetNews huggingface dataset:
From: jhull@mercury.NoSubdomain.NoDomain (   Joseph F. Hull)
Subject: Re: Covert channel
Organization: Martin Marietta Astronautics, Denver
Date: Thu, 20 Aug 1992 17:30:03 GMT

In article <21382@rpp386.lonestar.org>, jfh@rpp386.lonestar.org (John F. Haugh II) writes:
|> Given the example you provided, putting something in the mail headers
|> is not an example of 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 is contradicting himself.  Many systems rely on procedural elements to implement 
portions of the security policy, i.e., there may be many systems which have e-mail software 
that allows the user to change mail headers and also have security policies which prohibit
the transfer outside the organization of specified information.  Any user who uses fields in
the mail header to transfer such information is violating the system security policy.  And,
under the definition given above, such use constitutes a covert channel.

The definition John quotes above is also the one I use and is, I suggest, the most 
appropriate.  Can we agree that, for this thread, this is the one we will use?

-- 
	   _   _
    /_    / ) / ) Jeff Hull          hull@den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir
/_/ \_/ /   /	  Aurora, CO 80012   303-977-1061
Newsgroups: comp.security.misc
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Re: SMTP SECURITY: A new (?) idea
Organization: Lehman Brothers
Date: Thu, 13 Aug 1992 15:30:33 GMT

kanagn@athina.cc.uch.gr (Kostas Anagnostakis) writes:
>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.

Because priviledged ports aren't really priviledged. Besides, anyone
on the net who has root access on a unix box, or a PC they run, or
what have you, could still forge mail.

>  If someone wishes to start working on the idea, I would like to help.

Its not like it would be a lot of work; we are talking about 10 or 20
of lines of code here, even being generous. Its just that this doesn't
actually solve the problem.

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.
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: Fri, 14 Aug 1992 19:50:17 GMT

nelson@reed.edu (Nelson Minar) writes:

>First of all it seems like not many sites are running RFC 931 type
>code. I don't know why this is, but it makes it considerably harder to
>count on it for authentication. 

	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. That is a whole LOT
different from "authentication".

	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.

mjr.
Newsgroups: comp.security.misc
From: pen@lysator.liu.se (Peter Eriksson)
Subject: Re: Fake headers on Internet mail
Organization: Lysator Academic Computer Club, Linkoping University, Sweden
Date: Fri, 14 Aug 1992 17:52:33 GMT

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

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

The point is that it is the Sendmail daemon that adds this stamp. Of course
a forger can add his own addition "Received: " line, or he can use a PC (or
a Unix machine where he has root access) to run his own IDENT daemon, but then
all odds are off anyway. And there will still be the Sendmail-added stamp
in the mail...

Something like this:

Received: from glenlivet.ohm.york.ac.uk ([144.32.128.21]) by lysator.liu.se  with SMTP
          (5.65c8/1.34/Lysator-3.1) id AA16950; Tue, 21 Jul 1992 19:48:09 +0200          (rfc931-sender: root@[144.32.128.21])
Received: from efd.lth.se (oddput.efd.lth.se) by glenlivet.ohm.york.ac.uk  with SMTP
          (5.65c8/1.34) id AA02312; Wed, 6 May 1992 19:03:56 +0200
	  (rfc931-sender: forger@realhostid)
Received: from faked.host.xy (realhostid) by efd.lth.se  with SMTP
          (5.65c8/1.99) id AA02313; Tue, 5 May 1992 19:00:56 +0200
	  (rfc931-sender: root@realhostid)

Then one can check the Received: lines to see at which point someone
did fake the message... And of course the Sendmail daemon also logs the
"rfc931-sender" user identifier in it's log file.

Of course there are a number of ways to circumstance this, but it will
atleast make it harder for forgers. And they can atleast not Telnet
into *your* Sendmail daemon and use that as the entry point of a forged
letter. (If the machine the forger is using has a running IDENT server and
it has not been compromised.)

To get real authentication one has to go the Kerberos way I'm afraid
(or use PEM or things like that).

/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.
Newsgroups: comp.security.misc
From: franco@fx.com (Frank Minjarez)
Subject: Re: Covert channel
Organization: FXD/Telerate, Mountain View, CA
Date: Thu, 20 Aug 1992 18:15:54 GMT

mark@hpcvxmsr.cv.hp.com (Mark Rowe) writes:

>I agree, it is not always clear cut, but I think the wrong questions are being
>asked.  It is not, "Is the use of XXX a covert channel?", but rather, "Was XXX
>intended to transmit information about YYY?".  It is (as you said) this intent
>that is often not clear cut.  That in itself is not a fault in the definition.
>It is often much easier to define what something is than it is to accurately
>identify one when it is encountered.

Okay we're now talking about several different issues.  First, there may
be parts of a system that handle multi-level data.  These parts are the
TRUSTED parts (Trusted Computing Base TCB) -- these are the only parts that 
can do things like transmit XXX about YYY.  I assume that you mean mean YYY 
is at a different classification level than XXX.  This may be an overt 
channel (intentional and part of the design) or a covert channel.

Overt channels should only occur in the TCB.  These are normal in any system
design...

There are other parts of a system that are UNTRUSTED.  These parts are
not intended to handle multi-level data.  Any time these parts
do something like transmit XXX about YYY it's a covert channel.  That is,
the designers didn't intend for this part of the system to do that. 

The original definition of a covert channel from the Nutshell book 
is a good one.  Adding fuzzy cases, and talk about MAC, DAC, etc only
confuse the issue here.  A COVERT CHANNEL is a just a communication
channel that VIOLATES the SECURITY POLICY.  If it is overt it will be part
of the security policy of the system.  That is, it will be part of the
functions defined for the TCB.


--f
Newsgroups: comp.security.misc
From: imp@solbourne.com (Warner Losh)
Subject: Re: Security Policy
Organization: Solbourne, User Interface Group
Date: Fri, 21 Aug 1992 00:19:05 GMT

In article <3748@wzv.win.tue.nl> rob@wzv.win.tue.nl (Rob J. Nauta) writes:
>Right now, you must think I'm crazy, that nobody has this system.

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.

Oh, you forgot to add "hacking sendmail.cf so that root gets a copy of
all off site mail" to the list of things that they do :-(

Warner
-- 
Warner Losh		imp@Solbourne.COM
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.security.misc
From: styri@hal.nta.no (Haakon Styri)
Subject: Re: Security Policy
Reply-To: styri@nta.no
Organization: Norwegian Telecom Research
Date: Fri, 21 Aug 92 08:24:46 GMT

In article <66496@hydra.gatech.EDU>, Danny McGurl writes:
>
> This brings up an interesting question.  Where does a sysadmin's
> action become unethical and/or illegal.  Is it wrong for a sysadmin
> to log the mail and not look at it unless they are presented with
> a reasonable suspicion (or evidence of a crime)? 

This shouldn't be too difficult to answer. One way is to treat it as an
ordinary telephone tap. Different countries will have different laws for
doing this. Another way, probably better, is to treat it as a backup.
If you tell the users, probably by including this in a policy statement
that should be signed by each user, it's ok. (Reading the log, however,
is not. The log is there "in case something should happen".)

If the computer system in question is a public facility you may have
other regulations limiting your actions.

---
Haakon Styri		*** std. disclaimer applies	***
Newsgroups: comp.security.misc
From: karger@osf.org (Paul A. Karger)
Subject: Re: Big Dictionary Searches (Was: Re: Problem with npasswd??)
Organization: Open Software Foundation
Date: Wed, 12 Aug 1992 20:46:49 GMT

In article <61350002@otter.hpl.hp.com>, sjmz@otter.hpl.hp.com (Stefek Zaba) writes:

|> 
|> Maybe yes, maybe not; but I'm reminded of a classic password attack I heard
|> about on (oneof (multics tops20)) a while back...
|>

This was an attack on TOPS-20.  The file system associated passwords with directories, and your program could gain additional access rights to a directory, if it could quote the proper password.  These passwords happened to be the same as the login passwords.
 
|> The nice authenticate-passwd routine on this system was internally coded
|> to do a letter-by-letter compare of the submitted password against the
|> hidden registered password; it returned with failure on detecting the
|> first mismatch.  Thus-and-therefore, by repeated probes with your submitted
|> password guess broken across a page boundary, arranging for the "far" page to
|> be swapped out, and timing the return (remember, page faults cost *lots* of
|> time in them thar days) you could reduce the number of probes from
|> [alphabet_size ** passwd_length] to [alphabet_size * passwd_length].
|> 
|> (For the numberically impaired: with an 8-character password drawn from a
|> 64-letter alphabet, that's the difference between 281,474,976,710,656 and
|> 512).
|> 
|> Unsurprisingly, the internal routine was changed to access all chars of the
|> probe password before returning.
|> 
|> A nice example of "covert channels"!

This really is not an example of a covert channel.  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.

The page fault count revealing the password is an example of an operating system argument validation problem.  One of the basic tenets of proper argument validation is that the operating system must usually make a copy of the supplied arguments to avoid asynchronous attacks or revealing information improperly.  (Argument validation for large I/O buffers must be done differently to avoid the performance problems of having to copy too much data.)

	Paul
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 14 Aug 92 16:30:15 GMT
Article-I.D.: rpp386.21376
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

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.

>I think the key points here are "communication channel" and "violates
>security policy."  Some process has to communicate (eg write to disk, send
>over phone line, etc.) data to another process, and that communication 
>has to violate the security poilicy of the system (eg not to write out
>classified data to processes that are not trusted to read it).

Except that disk files and phone lines aren't "covert."
-- 
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: sherer@lub001.lamar.edu
Newsgroups: comp.security.misc
Subject: Fake headers on Internet mail
Date: 12 Aug 92 15:14:04 +1700
Organization: Lamar University - Beaumont

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.

My question is, is there a way to masquerade as someone else in e-mail? If so,
is there anything I can do to prevent this from happening? It seems like they
are changing the header to look exactly like a real mail message from someone
else, and it is very dangerous if someone figures out how to do this. I was
wondering if anyone out there had heard of such a thing.

Please send mail to me personally at the following addresses. I would greatly
appreciate any light you can shed on this.

Thanks.

Kirk Sherer
Lamar University
Beaumont, TX

Internet address:  SHERER@LUB001.LAMAR.EDU
Phone:             (409) 880-2374
Newsgroups: comp.security.misc
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: Fake headers on Internet mail
Organization: Northern Illinois University
Date: Fri, 14 Aug 1992 15:02:04 GMT

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.

Newsgroups: comp.security.misc
From: mark@hpcvxmsr.cv.hp.com (Mark Rowe)
Subject: Re: Covert channel
Reply-To: mark@hpcvlx.cv.hp.com
Organization: UDT-CV (ITO)
Date: Mon, 17 Aug 1992 17:51:23 GMT

In article <21378@rpp386.lonestar.org>, John F. Haugh II writes:
>In article <1992Aug14.190446.11355@hpcvusn.cv.hp.com> Mark Rowe writes:
>> ... {example of covert channel using the system mail system ending with
>> the statement that what makes the channel covert} ...
>> 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).
> 
> ...
> {discussion pointing out how MAC would prevent the use of my example}
> ...
> 
> What you are describing sounds more like busted MAC than a covert
> channel.

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.

Mark Rowe             email: mark@hpcvlx.cv.hp.com
Hewlett Packard       voice: (503) 750-3246
Corvallis, OR         FAX:   (503) 750-3788
From: henk@cs.vu.nl (Henk Smit)
Newsgroups: comp.security.misc
Subject: Re: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Date: 16 Aug 92 20:19:56 GMT

horde@reed.edu (Mr. Heiji Horde) writes:

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

  It's very easy to ridicule somebody who wants to learn something. I
 think its better (and maybe more difficult) to give useful information
 than post some cliche....

  There are lots of places where you can find information about security.

 -- See Alex's monthly FAQ posting in this newsgroup.
 -- Another good place to look is cert.org. There are lots of interesting
    things you can ftp from there, e.g. old CERT advisories.
 -- There are some PD papers about security eg. the excellent security-doc
    by David Curry. Available from ftp.uu.net in the /doc/security directory.
    You can find more interesting things there.
 -- Books. See the FAQ. A good one is "Practical Unix Security" by Garfinkel
    andd Spafford.
 -- Contact your vendor for bugfixes. Some vendors make them available
    through anonymous ftp. If you have Suns, look at ftp.uu.net in the
    sun-fixes or sun-dist directory (/vendor/sun/...).

  Another tip I can give you is ...., read the (friendly) manual pages :-)
 Look what deamons are running on your system (using ps(1)). Also look at
 the ones that are started by inetd. Take a day to just read the manual
 pages that describe these daemons. Also read the ones in the SEE ALSO
 section. Now you should know all configuration files associated  with
 these daemons. Check them all. There are lots of them, and they are all
 important :-)  /etc/exports, /var/yp/securenets, /etc/shells, /etc/ftpusers
 /etc/netgroup, /etc/hosts.equiv to just name a few. Also look at all the
 possible flags of those daemons. Lots of them are important. -s flag of
 in.tftpd, -s flag of ypbind, the -n flag of rpc.mountd (do not use it !), 
 etc.
  Reading all those manual pages may take some time, but it will pay off.

  If you have Sun's, this might be another tip. Look at /etc/rc.local.
 A couple of times there are choices in starting up daemons (rpc.mountd,
 nfsd, etc..), depending on the existence of /etc/security. If you don't
 have the C2 security package installed, this directory does not exist.
  In this case those daemons are started up in a less secure mode.
 Change the checks in /etc/rc.local so the more secure mode is chosen.

    Hope this helps,

                 Henk.

--
Henk Smit                               Vrije Universiteit     Amsterdam
Internet: henk@cs.vu.nl                 Phone:    +31 20 548 6218
From: u9048979@cc.uow.edu.au (glen eastment)
Newsgroups: comp.security.misc
Subject: CRYPTOGRAPHY INFO WANTED...PLEASE!
Keywords: CRYPTOGRAPHY DES RSA
Date: 19 Aug 92 05:01:31 GMT
Organization: University Of Wollongong

If anyone has some files on cryptography, mainly DES, RSA (but any others
too), could they please e-mail them to me.

Thanks in adcvance!

<GE> a.k.a. u9048979@wampyr.cc.uow.edu.au
Newsgroups: comp.security.misc
From: nagle@netcom.com (John Nagle)
Subject: Re: WAISified PostScript would constitute a security hole
Date: Tue, 18 Aug 92 18:45:52 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

sethb@fid.morgan.com (Seth Breidbart) writes:

>What I need is the ability to run a subprocess as a slave; whenever it
>tries to do any kind of system call, the call is handed to me (the
>master process) instead.  That way, I can allow only "safe" actions; I
>can also pretend to have done "unsafe" actions so the subprocess will
>run without causing trouble.

        A good idea.  It's suprising that UNIX doesn't have something
like this, as a debugging tool.  It wasn't there in original UNIX
because the system had to work without enough memory for more than one
active process at a time.  But that's not an issue today.

        Of course, there's now a risk that this mechanism could be used
to spoof set-UID programs.  So that issue has to be dealt with.

        The ability to restrict a process to a strict subset of its
parent's privileges is promising.  The ability to run a subprocess which
could open no files and sockets other than those inheirited from the parent 
would be a good first step in running software of unknown origin.

        Now, if attempts to open files/sockets notify the parent, we've
got something.  We could have a shell which forks off child processes
with the capability to open any file named on the command line, and nothing
else.  Anything else pops up an alert box, with something like 
"'ghostscript' wants to open '/etc/passwd' for writing?  Permit this?"
Some programs (those considered not to contain Trojan horses) might be
launched with stronger privileges.  But you could run software of
dubious origin with some hope of containing its effects.  Some way to do
that is needed badly if programmable objects are to be passed around as
documents.   Or we're going to have a whole new class of viruses and worms.

        You really can't add on security as an afterthought.  Many
people have tried and failed.  But I suppose the UNIX community has to
keep trying until something better comes along.

					John Nagle
Newsgroups: comp.security.misc
From: imp@solbourne.com (Warner Losh)
Subject: Re: SMTP SECURITY: A new (?) idea
Organization: Solbourne, User Interface Group
Date: Thu, 13 Aug 1992 16:51:36 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.

This has been done in many places already.  However, they can only do
it for local connections because they would bounce all the mail from
the rest of the world.

Besides, there is no such thing as a priviledged port in the RFC's.
It is something that Berkeley designed to help out security on a
network of BSD machines.  It has no meaning on a PC for example.  The
port numnbers are < 1024.

It would be better to run some sort of identity server (for a very
weak protection) or PEM (for a much stronger protection).

Warner
-- 
Warner Losh		imp@Solbourne.COM
imp@Solbourne.COM: "I should be OK, I'm basically doing the speed limit"
dworkin@rootgroup.com: "That's why BASIC is so slow.  It has a speed limit"
Newsgroups: comp.security.misc