HDTenEightyP/NetNews huggingface dataset:
From: dwb@IMD.Sterling.COM (David Boyd)
Subject: Re: X server security (was Re: rsh)
Reply-To: dwb@IMD.Sterling.COM
Organization: Sterling Software
Date: Wed, 15 Apr 1992 22:40:26 GMT
X-Md4-Signature: ac0e376bb967a1f9f98e6627384a4597

In article <1992Apr15.160349.19287@bronze.ucs.indiana.edu>, Marc VanHeyningen <mvanheyn@copper.ucs.indiana.edu> writes:
|> In article <15433@gandalf.UMCS.Maine.EDU> who@gandalf.UMCS.Maine.EDU writes:
|> >
|> >	People are able to rsh commands to other peoples consoles and
|> >I was wondering how permissions could be set to prevent this. It can
|> >get anoying when people rsh the screen melt to my console. We run SunOS
|> >4.1 and use SUN 4/110 machines. Also, someone got hold of xlock.c and
|> >has modified it as a nasty trojan horse by using rsh to lock people's
|> >screens. The modifications were simple, but with a little effort could
|> >be made far more evil. So, for your safety and mine, please prevent
|> >rsh to other people's sessions.
|> 
|> rsh isn't the real problem; with just rsh, about the worst I could do is
|> slow your machine down or dump output or something.
|> 
|> The real problem is using xhost as "security" for your X server
|> process.  If your X server will accept connections from any process
|> running on your workstation, then anybody can do anything in your session,
|> including lock your screen, terminate your session, spy on the conents
|> of any/all of your windows, watch what you type... anything.  If your
|> network is relatively secure against casual snooping, MIT-MAGIC-COOKIE-1
|> is probably adequate for security.  "man Xsecurity" explains it better
|> than I can.

	Securing the X Server is only part of the answer,  I have
several littly programs which interact directly with the frame buffer.
Securing the X server will not stop these programs.  Sounds like what
is needed is a more mature set of users.  These little games are
funny once or twice but soon become annoying. I suggest that if you can
find out who is doing this (especially the guy who hacked xlock)
to your system administrator.

-- 
David W. Boyd	             UUCP:     uunet!sparky!dwb
Sterling Software IMD        INTERNET: dwb@IMD.Sterling.COM
1404 Ft. Crook Rd. South     Phone:    (402) 291-8300 
Bellevue, NE. 68005-2969     FAX:      (402) 291-4362
From: owsl_ltd@uhura.cc.rochester.edu (--<<[...]>>--)
Newsgroups: alt.security
Subject: Re: AVALON NARC ANNOUNCEMENT
Date: 14 Apr 92 03:24:20 GMT
Article-I.D.: galileo.1992Apr14.032420.20131
Organization: University of Rochester - Rochester, New York

In <867@cert.sei.cmu.edu> ecd@cert.sei.cmu.edu (Edward DeHart) writes:

>An interesting CERTish Advisory.  It should have been sent out on April 1st.

>On a different subject, the CERT will be changing its e-mail address from
>cert.sei.cmu.edu to cert.org.  Fewer letters to type. :-)  Our new e-mail
>address is functioning at this time but not officially announced.

>Thank you,
>Ed DeHart
>Computer Emergency Response Team
>Internet E-mail: cert@cert.org
>Telephone: 412-268-7090 24-hour hotline:
>       CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
>       and are on call for emergencies during other hours.

CERT.org...yikes!  The narrowing down of the word "CERT" in your domain name,
though, in reality, almost definitely done for practical reasons, it seems to
denote an increased aura for CERT, a domain over a host on a sub-domain of
CMU.EDU.  This made me pause for reflection...I wonder how much "security
by obscurity" CERT has to inspire fear among those they respond to
emergencily.  "Emergency Response Team", "CERT/CC [CC - some kind of subteam
of CERT probably] personnel", "on call for emergency".  Just the .sig evokes
the image of sometime gargantuaness to the standard viewer.  However, as I
often stir up images that there are some dark, ominous forces about, I shall
as well dispel them.

CERT is basically a bunch of grad students in one room in the SEI building
at Carnegie-Mellon.  They are not vicious monsters with fanged teeth and
X-ray vision, most of them are just Carnegie-Mellon grad student programmers
who are getting a little bit of experience before they head off into the
job market.  I don't have an employee roster before me, but what I have seen
of the CERT room in the SEI building, there are about 20 or so people who
work there, on shifts akin to somewhat less of students working at the school
pizza place.  Almost all of their time is spent writing files on computer
security.  In many ways, they are like the NCSC, i.e. a joke, as one would
think that Bob Morris and the power of the NSA could clean up the MIL domain,
which we know Dutch hackers got in with with "cwd ~"...come on!  cwd ~ ?
Basically, NCSC sits around writing Orange Books and stuff like that.  i.e.
they are pretty passive, mellow types.  Just wanted to clear up a few
misconceptions.  "CERT.org" sounds ominous, when in fact, they are pretty
clueless.  Now you know.  And knowing is half the battle.

Owsla Editor
--
Owsla Editor                        |             Elitesville, USA
The Owsla                           | Tune into KRAD radio for dude'n tunes
From: sterling@netcom.com
Newsgroups: alt.security
Subject: Re: rsh
Date: 15 Apr 92 21:41:04 GMT
Article-I.D.: netcom.4bzjs=+.sterling
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <15433@gandalf.UMCS.Maine.EDU> who@gandalf.UMCS.Maine.EDU writes:
>[A lot of stuff about rsh deleted; his real problem is xwindows permissions]

Try 'xhost -'.

Bruce

-- 
--- sterling@netcom.com - sirbruce@gnu.ai.mit.edu - bwoodcoc@isis.cs.du.edu ---
Yes.  We fuck.  Often, and with great enjoyment of the act.  We aren't married,
we use birth control, we use interesting little toys on occasion.  We moan like
beasts in heat.  Life is *great*.  -- Bryant, ref. to Erin, on alt.brother-jed.
Newsgroups: alt.security
From: adykes@jpradley.jpr.com (Al Dykes)
Subject: Archive request:  Use of encryption for software distribution
Organization: Unix in NYC
Date: Tue, 07 Apr 1992 17:06:46 GMT




I think I recall seeing a thread of conversation relating to 
encryption applied to software licensing and distribution in this
newsgroup.   Did anyone archive the discussion ?  If so,  I'd like 
to get a copy via e-mail.


Thanks.

Al Dykes
----------
adykes@ad.com
From: ecd@cert.sei.cmu.edu (Edward DeHart)
Newsgroups: alt.security
Subject: Re: AVALON NARC ANNOUNCEMENT
Summary: bogus CERT Advisory
Date: 13 Apr 92 19:14:59 GMT
Article-I.D.: cert.867
Organization: Computer Emergency Response Team, Pittsburgh, PA

In article <1992Apr10.120037.3645@rucs2.sunlab.cs.runet.edu>, sgardner@rucs2.sunlab.cs.runet.edu (Steve Gardner) writes:
> ===========================================================================
> CA-66:66                      CERT Advisory
>                                June 6, 666
>                          Avalon Nark Vulnerability
> ---------------------------------------------------------------------------
> ...
> 
> Past advisories, information about FIRST representatives, and other
> information related to computer security are available for anonymous ftp
> from cert.sei.cmu.edu (192.88.209.5).

An interesting CERTish Advisory.  It should have been sent out on April 1st.

On a different subject, the CERT will be changing its e-mail address from
cert.sei.cmu.edu to cert.org.  Fewer letters to type. :-)  Our new e-mail
address is functioning at this time but not officially announced.

Thank you,
Ed DeHart
Computer Emergency Response Team
Internet E-mail: cert@cert.org
Telephone: 412-268-7090 24-hour hotline:
       CERT/CC personnel answer 7:30a.m. to 6:00p.m. EST(GMT-5)/EDT(GMT-4),
       and are on call for emergencies during other hours.
Newsgroups: alt.security
From: subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
Subject: Re: obnoxious sounds (was Re: rsh)
Organization: putchar('I'); for (i = 0; i < 3; i++) putchar('E');
Date: Fri, 17 Apr 1992 00:32:46 GMT

In article <1992Apr16.211658.14886@Princeton.EDU> spencer@burst.Princeton.EDU (S. Spencer Sun) writes:
>In article <1992Apr16.013856.23454@informix.com> proberts@informix.com (Paul Roberts) writes:
>>Me too! Please let me know what you find out. I think putting speakers
>>into computers was about the worst thing ever done. Certain people who
>>shall remain nameless now spend most of their day sending noises of one
>>sort or another to each other's workstations.
>
>Well, I developed a pretty ugly hack to lock off /dev/audio involving
>named pipes... I don't use it though, because we don't really have
>problems with sounds here... just an occasional one or two that isn't
>very serious and it doesn't get to a really annoying level so it's not
>worth using it.  There's always the danger that you'll forget to unlock
>it and/or something else will go wrong and then /dev/audio will be
>inaccessible until you realize what you did (if you realize it)...
>
>In short, the solution I came up with is a kludge and you probably
>wouldn't want to run it.  But it can be done.

Remember, the reason you used a named pipe is because you wanted to be
able to play sounds to the audio device yourself. If you simply want to
lock out access to /dev/audio, just do this:

% cat > /dev/audio &

/dev/audio is an exclusive write device -- only one process can have it
open for writing at any given time.

Of course, you do have to rmember to kill the cat process when you
logout...

	-Kartik
From: who@gandalf.UMCS.Maine.EDU
Newsgroups: alt.security
Subject: rsh
Date: 15 Apr 92 17:43:08 GMT
Organization: University of Maine Department of Computer Science


	People are able to rsh commands to other peoples consoles and
I was wondering how permissions could be set to prevent this. It can
get anoying when people rsh the screen melt to my console. We run SunOS
4.1 and use SUN 4/110 machines. Also, someone got hold of xlock.c and
has modified it as a nasty trojan horse by using rsh to lock people's
screens. The modifications were simple, but with a little effort could
be made far more evil. So, for your safety and mine, please prevent
rsh to other people's sessions.

Newsgroups: alt.security
From: Marc VanHeyningen <mvanheyn@copper.ucs.indiana.edu>
Subject: X server security (was Re: rsh)
Organization: Indiana University
Date: Wed, 15 Apr 1992 16:03:43 -0500

In article <15433@gandalf.UMCS.Maine.EDU> who@gandalf.UMCS.Maine.EDU writes:
>
>	People are able to rsh commands to other peoples consoles and
>I was wondering how permissions could be set to prevent this. It can
>get anoying when people rsh the screen melt to my console. We run SunOS
>4.1 and use SUN 4/110 machines. Also, someone got hold of xlock.c and
>has modified it as a nasty trojan horse by using rsh to lock people's
>screens. The modifications were simple, but with a little effort could
>be made far more evil. So, for your safety and mine, please prevent
>rsh to other people's sessions.

rsh isn't the real problem; with just rsh, about the worst I could do is
slow your machine down or dump output or something.

The real problem is using xhost as "security" for your X server
process.  If your X server will accept connections from any process
running on your workstation, then anybody can do anything in your session,
including lock your screen, terminate your session, spy on the conents
of any/all of your windows, watch what you type... anything.  If your
network is relatively secure against casual snooping, MIT-MAGIC-COOKIE-1
is probably adequate for security.  "man Xsecurity" explains it better
than I can.
-- 
  _  _  Marc VanHeyningen  mvanheyn@indiana.edu  mvanheyn@iubacs.BITNET
 /  / \ mputer-\      Your health care choices:
|  |   | oky Science     immediate access, limited costs, high-tech medicine
 \_ \_/ gnitive/            Pick any two.
From: murphy@symcom.math.uiuc.edu (Michael L. Murphy)
Subject: Re: rsh
Summary: use "xauth" to make X11 secure.
Followup-To: who@gandalf.UMCS.Maine.EDU
Organization: Math Dept., University of Illinois at Urbana/Champaign
Date: Wed, 15 Apr 1992 20:36:49 GMT

In article <15433@gandalf.UMCS.Maine.EDU> who@gandalf.UMCS.Maine.EDU writes:
>
>	People are able to rsh commands to other peoples consoles and
>I was wondering how permissions could be set to prevent this. It can
>get anoying when people rsh the screen melt to my console. We run SunOS
>4.1 and use SUN 4/110 machines. Also, someone got hold of xlock.c and
>has modified it as a nasty trojan horse by using rsh to lock people's
>screens. The modifications were simple, but with a little effort could
>be made far more evil. So, for your safety and mine, please prevent
>rsh to other people's sessions.
>

Your letter is a little confusing, but it sounds like you are running
Xwindows.  It also sounds like you are not using the .Xauthority file.
First of all, create a file .xsession in the user's home directory
that says:

exec X -auth $HOME/.Xauthority

Now, use the "xauth" command to add entries for any hosts you might use:

example% xauth
xauth: Creating new file ~/.Xauthority......
xauth> add host1:0 . 5c701355
xauth> add host1/unix:0 . 5c701355
xauth> add host2:0 . 5c701355
xauth> add host2/unix:0 . 5c701355
etc......
xauth> quit

(It doesn't matter what hexadecimal number you use, as long as it has an
even number of digits.)  "." is an abbreviation for MIT-MAGIC-COOKIE-1
protocol, which is not completely secure, but will certainly ward off
ameteur attempts to connect unauthorized clients to an Xserver.

You will notice that after you run xauth, a file ".Xauthority" will be
created in your home directory.  It will also only be user-readable.
(If the file could be read, it could be copied and used by any other
user on your system.)

Now, the Xserver when starting up will read this file and only accept
clients who use that certain hexadecimal "cookie" specified in your
.Xauthority file.  Also, all clients will read that file and use
that cookie to connect to your server.  See the man pages of "X" and
"xauth" for more information.
-- 
+=And=the=Master=said=unto=the=silence,="In=the=path=of=our=happiness=shall=+
\ we find the learning for which we have chosen this lifetime." - R. Bach   /
/ Michael Murphy, senior (Math/C.S.), U of Ill.  |   Address: URH 10 Carr   \
+=send=e-mail=to=<murphy@symcom.math.uiuc.edu>==/^\==Urbana,=IL=61801=======+
Newsgroups: alt.security,news.admin
Organization: large
Date: 30 Mar 1992 16:32:48 EST
Expires: 1 Apr 93 12:34
Distribution: na
Subject: News Group Readership Monitoring
From: hobbit@babyoil.ftp.com (*Hobbit*)
From: ckd@eff.org (Christopher Davis)
Newsgroups: alt.security
Subject: Re: X server security (was Re: rsh)
Date: 15 Apr 92 23:15:13 GMT
	<1992Apr15.224026.19808@sparky.imd.sterling.com>
Organization: Electronic Frontier Foundation Tech Central


 David> == David Boyd <dwb@IMD.Sterling.COM> 

 David> 	Securing the X Server is only part of the answer, I have
 David> several littly programs which interact directly with the frame
 David> buffer.  Securing the X server will not stop these programs.

Which is why you should ask your sysadmin(s) to set up /etc/fbtab properly.

Of course, *Sun* can't be bothered to ship it in anything resembling a
secure configuration, but then these are the people who have been
shipping /etc/hosts.equiv with a "+" in it for years, who have a true
"Network Information Service" -- that allows anyone on the Internet to
score your password file for later cracking, and who then go on at great
length about their "C2" mode (which hasn't actually been evaluated).
--
Christopher Davis <ckd@eff.org> |    ECONOMIC OBSERVATIONS DEPARTMENT
System Manager & Postmaster     |  "There's always something going out of
Electronic Frontier Foundation  |      business in Central Square."
+1 617 864 0665  NIC: [CKD1]    |   -Rita Marie Rouvalis <rita@eff.org>
Newsgroups: alt.security
From: spencer@phoenix.Princeton.EDU (S. Spencer Sun)
Subject: Re: rsh
Originator: news@ernie.Princeton.EDU
Organization: Princeton Univ. Class of '94
Date: Thu, 16 Apr 1992 02:47:35 GMT

In article <4bzjs=+.sterling@netcom.com> sterling@netcom.com writes:
>In article <15433@gandalf.UMCS.Maine.EDU> who@gandalf.UMCS.Maine.EDU writes:
>>[A lot of stuff about rsh deleted; his real problem is xwindows permissions]
>
>Try 'xhost -'.

OK, so the other person does 'rsh foo "xhost +"'.  Now what?
----------
Spencer Sun - Princeton Univ. Class of '94 - Dept. of Computer Science
Clockwork Orange (Princeton Ultimate) (when I bother to show up for practice)
"Your mother puts license plates in your underwear?  How do you sit?"
Newsgroups: alt.security
From: cfm2h@fulton.seas.Virginia.EDU (Christopher Mullins)
Subject: Re: obnoxious sounds (was Re: rsh)
Organization: University of Virginia
Date: Fri, 17 Apr 1992 04:17:45 GMT

In article <1992Apr16.211658.14886@Princeton.EDU> spencer@burst.Princeton.EDU (S. Spencer Sun) writes:
>In article <1992Apr16.013856.23454@informix.com> proberts@informix.com (Paul Roberts) writes:
>>Me too! Please let me know what you find out. I think putting speakers
>>into computers was about the worst thing ever done. Certain people who
>>shall remain nameless now spend most of their day sending noises of one
>>sort or another to each other's workstations.
>
>Well, I developed a pretty ugly hack to lock off /dev/audio involving
>named pipes... I don't use it though, because we don't really have
>problems with sounds here... just an occasional one or two that isn't
>very serious and it doesn't get to a really annoying level so it's not
>worth using it.  There's always the danger that you'll forget to unlock
>it and/or something else will go wrong and then /dev/audio will be
>inaccessible until you realize what you did (if you realize it)...
>
>In short, the solution I came up with is a kludge and you probably
>wouldn't want to run it.  But it can be done.

   Here at UVA, /dev/audio on the Sparcs is chowned to the owner of
/dev/console whenever someone logs in at the console.  When they log out,
it is chowned back to root.  Thus the person sitting at the console can
use /dev/audio, but no one can remotely log in and play with it, whether
there is someone logged in at the console or not.  
   /dev/fb is also treated this way, to prevent people from writing or
reading the frame buffer.

Chris Mullins
cfm2h@virginia.edu
From: subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
Newsgroups: alt.security
Subject: Re: AVALON NARC ANNOUNCEMENT
Date: 14 Apr 92 12:46:07 GMT
Organization: putchar('I'); for (i = 0; i < 3; i++) putchar('E');

In article <1992Apr14.032420.20131@galileo.cc.rochester.edu> owsl_ltd@uhura.cc.rochester.edu (--<<[...]>>--) writes:
>CERT is basically a bunch of grad students in one room in the SEI building
>at Carnegie-Mellon.  

>I don't have an employee roster before me, but what I have seen
>of the CERT room in the SEI building, there are about 20 or so people who
>work there, on shifts akin to somewhat less of students working at the school
>pizza place.  Almost all of their time is spent writing files on computer

The Wizard of Oz is umasked! :-)

>Now you know.  And knowing is half the battle.

All RIGHT!! Another GI JOE FAN! 


	-Kartik
Newsgroups: alt.security
From: vince@ghost.dsi.unimi.it (David Vincenzetti)
Subject: Re: Source for Crypt() ???
Organization: Computer Science Dep. - Milan University
Date: Fri, 10 Apr 1992 10:10:21 GMT

davis@shasta.bu.edu ("John E. Davis") writes:

>Here is a data encryption program that I wrote.  I suspect it can be cracked
>pretty easily but I do not know this for sure.  It is short and fast.  To use
>it, do:

>     crypt keyname filein > fileout

>The key should be 8 chars or less.  To decrypt the file, repeat the process.

>I am also posting this because I would like to know the dangers of this
>simplistic algorithm.

The algorithm is incredibily weak, it could be cracked in *seconds*
by an amateour cryptographer. For an examble find out CBW, the program which
attacks and decodes the Unix crypt(1) Enigma's cipher.
I suggest you do not use your cipher for any applications.

Ciao,	David
-- 
David Vincenzetti          EMAIL: vince@ghost.dsi.unimi.it
                           SNAIL: 8th street 39, 20090 Segrate, ITALY
                             ORG: DSI, Universita` degli Studi di Milano
       "Love, Kisses, and a Neutron Bomb." -Eric the Finn
From: rjq@phys.ksu.edu (Rob Quinn)
Newsgroups: alt.security
Subject: Re: rsh
Date: 16 Apr 1992 21:33:23 GMT
Organization: Kansas State University
NNTP-Posting-Host: bohr.phys.ksu.edu

From: murphy@symcom.math.uiuc.edu (Michael L. Murphy)
Subject: Re: rsh
Followup-To: who@gandalf.UMCS.Maine.EDU

 Nice. I assume you meant 'Reply-To:'?


In <1992Apr15.203649.3936@news.cso.uiuc.edu> murphy@symcom.math.uiuc.edu (Michael L. Murphy) writes:
]Your letter is a little confusing, but it sounds like you are running
]Xwindows.  It also sounds like you are not using the .Xauthority file.
]First of all, create a file .xsession in the user's home directory
]that says:
]exec X -auth $HOME/.Xauthority

 That should be .xserverrc.


](It doesn't matter what hexadecimal number you use, as long as it has an
]even number of digits.)  "." is an abbreviation for MIT-MAGIC-COOKIE-1
]protocol, which is not completely secure, but will certainly ward off
]ameteur attempts to connect unauthorized clients to an Xserver.

 Besides watching the network, how would you go about breaking
it? With 32 hex digits, exhaustive searching seems impossible.


]You will notice that after you run xauth, a file ".Xauthority" will be
]created in your home directory.  It will also only be user-readable.
](If the file could be read, it could be copied and used by any other
]user on your system.)

 I might add that you will need to copy this to any remote machines
where you might have accounts that need to connect to your X server.


--
Rob Quinn
rjq@phys.ksu.edu
QuinnBob@KSUVM.BITNET