[1461] in RISKS Forum

home help back first fref pref prev next nref lref last post

Risks Digest 20.30

daemon@ATHENA.MIT.EDU (RISKS List Owner)
Fri Apr 16 15:25:54 1999

From: RISKS List Owner <risko@csl.sri.com>
Date: Fri, 16 Apr 99 12:22:27 PDT
To: risks@MIT.EDU

RISKS-LIST: Risks-Forum Digest  Friday 16 April 1999  Volume 20 : Issue 30

   FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/20.30.html>
and at ftp.sri.com/risks/ .

  Contents:
Fake web page cause 20% stock surge and then retreat (Avi Rubin)
Glitch causes 4 billion euro overdraft (Monty Solomon)
Raytheon probes e-mail moles (Keith A Rhodes)
Security is still a human problem (Jeremy Epstein)
Y10K: not just for April Fools (Tom Swiss)
The Risk of 1 Apr  (David Frank)
RISKS April Foolery, Melissa, security, and frequencies of RISKS (PGN)
GPS setup error affects dredging in California (W.T. Shymanski)
Potential RADHAZ (Paul Walczak)
Space character in number causes silent Excel miscalculation (Ben Bederson)
Security Hole in Java 2 (Gary McGraw)
Re: Vancouver Hospital (Doneel Edelson)
Microsoft reschedules Memorial Day (Benjamin B. Bederson)
Risk of not backing up PGP Key Ring files (Herman D. Knoble)
Responses to Melissa (Chuck Karish)
Risks of "Melissa passed this way" (Charles Arthur)
Melissa and poor security model of Word Macros (Scott M Keir)
Mainframe virus (Henry Schaffer)
Millennialism in the Western Hemisphere (Richard Landes)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Thu, 8 Apr 1999 19:38:42 GMT
From: rubin@research.att.com (Avi Rubin)
Subject: Fake web page cause 20% stock surge and then retreat

There is a story in *The New York Times* 8 Apr 1999 about a web spoof that
cost people serious money.  Apparently, somebody set up a Web page that
looked exactly like a commercial financial Web site.  The claim was made
that PairGain Technologies (PAIR) was set for a takeover.  On this
speculation, the price shot up 20% the same day.  Once the hoax was proven,
the stock came back down, but presumably not all the people who bought high
got out on time.

While such an event is unfortunate, there is a taste of "I told you so" to 
see that one of the dangers we've been preaching about for so long actually 
caused loss of revenue.  I believe this is the first of many such swindles
to come.

Avi Rubin

  [Also noted by Jim Reisert.  A PairGain employee, Gary Dale Hoke was
  subsequently arrested at home in Raleigh NC, despite ``an effort to
  access the Internet anonymously'', according to the *San Francisco
  Chronicle, B1, 16 Apr 1999.  PGN]

------------------------------

Date: Tue, 13 Apr 1999 01:16:57 -0400
From: Monty Solomon <monty@roscom.com>
Subject: Glitch causes 4 billion euro overdraft

Glitch causes 4 billion euro overdraft (IDG, 12 Apr 1999)
by Mary Lisbeth D'Amico

Although the January switch to the single European currency was smooth at
most European banks, a prominent German discount bank and its customers this
week were acutely aware that not all possible euro-caused glitches have been
found.  Customers of Bank 24, a discount bank owned by Deutsche Bank AG,
were astonished [on 6 Apr 1999?] to find that their securities accounts
appeared to be overdrawn to the tune of 4 billion euro ($4.32 billion). An
oversight connected to the change to the euro was responsible for the error,
affecting 55,000 customers.

http://www.cnn.com/TECH/computing/9904/12/overdraft.idg/

------------------------------

Date: Mon, 05 Apr 1999 15:35:31 -0500
From: "Keith A Rhodes"<rhodesk.aimd@gao.gov>
Subject: Raytheon probes e-mail moles

Yahoo! subpoenaed to identify messagers; Raytheon execs resign

At least two Raytheon employees have resigned in the wake of proprietary
messages appearing on Yahoo message boards.  Raytheon is accusing 21
employees, and has subpoenaed Yahoo! to the identify the senders of
anonymous e-mail.  [Source: CNNfn, 5 Apr 1999, PGN-ed]

------------------------------

Date: Mon, 12 Apr 1999 14:32:47 -0700
From: "Epstein, Jeremy" <Jeremy_Epstein@NAI.com>
Subject: Security is still a human problem

Just in case you thought that security problems were solved by computers,
we're reminded yet again that it all comes down to trusted people doing the
right thing.  I wonder if John Deutch got a copy of the Melissa virus,
potentially sending classified files to his closest friends?

  A routine check of former CIA Director John Deutch's home turned up
  31 files classified secret on his personal computer after he had
  stepped down and was retained as a consultant.  No prosecution is
  planned, because the violations were not deemed criminal.  [PGN-ed
  from various sources, mostly Associated Press, 11 Apr 1999]
  
------------------------------

Date: Sat, 3 Apr 1999 21:09:06 -0500
From: Tom Swiss <tms@infamous.net>
Subject: Y10K: not just for April Fools

So maybe I'm an April Fool, but it seems to me that the Y10K issue is worth
a little serious thought.

There are areas of human endeavor in which 8000 years is not an extreme time
span. At present, we deal with these long time spans only in modeling things
like geological and cosmological events. But it is not unreasonable that
within the next century, we may begin to build very high technology systems
with mission durations of thousands of years - for example, a system to
contain radioactive wastes, or a probe to another star system.

Y2K issues have raised our consciousness about timer overflows, but it's
quite possible that this may fade in succeeding generations. There's no
reason not to start setting standards now.

     Perhaps all time counters should be bignums?

== Tom Swiss/tms@infamous.net == http://www.infamous.net

------------------------------

Date: Wed, 07 Apr 1999 23:12:00 +0200
From: "David Frank" <David.Frank@access.unizh.ch>
Subject: The Risk of 1 Apr (Re: Computer crash creates nonpersons in Zurich)

I'm hardly the first to point this out, but there is a certain risk in 
a) abstracting too much and
b) doing this on 2. April and
c) doing it with articles on such risk-worthy topics   ;-)

Why? This story makes perfect sense to any Risk-Reader but it's an April
Fool's joke. (I myself expected them, but this one is hardly detectable.)
The *Tages-Anzeiger* story goes on telling people to go to the townhall and
register themselves to avoid losing their citizenship.

Anyway: you should have backup tapes!

David Frank, Dietlikonerstr. 14, CH-8304 Wallisellen, Switzerland
+41 (0)1 830 6506, David.Frank@access.unizh.ch

  [Unfortunately, not all of the 1 Apr material is on hand in time.]

------------------------------

Date: Fri, 16 Apr 1999 10:16:08 PST
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: RISKS April Foolery, Melissa, security, and frequencies of RISKS 

Regarding the plethora of foolacious items in RISKS-20.26-29, RISKS has a
general policy of NOT explicitly identifying foolish material around 1 Apr
each year.  You are all on your own, and expected to read discriminatingly.
Besides, sometimes the most ridiculous sounding risks are quite real.

I received a few pieces of e-mail questioning the validity of one particular
item or another, which suggests to me that some of you must have taken many
of the other items as genuine!  This is somewhat surprising, but will not
alter our policy in future years.  An unexpected exception to this policy
was Lauren Weinstein's Inside Risks column on the risks of teleportation in
the April 1999 issue of the Communications of the ACM.  Although neither he
nor I wanted any explicit April Foolish disclaimers on the column, our CACM
editor decided to add an explicit warning -- perhaps fearing that some of
you were ready to try this technology anyway.  For those of you who are not
CACM subscribers, Lauren's column is on my Web site, Start with
http://www.csl.sri.com/neumann and click on "Inside Risks".  

Also on my Web site (http://www.csl.sri.com/neumann/house99.html) is my
testimony for yesterday's hearing of the House Science Committee
subcommittee on technology, in which I consider Melissa as the tip of a very
large iceberg -- the abysmal state of computer and communication security.
My testimony, plus that of Keith Rhodes and others, will also be at
http://www.house.gov/science/welcome.htm -- click on committee hearings,
then subcommittees, and find the 15 Apr hearing, supposedly by the end of
the House working day EDT.

Incidentally, newer readers sometimes ask why RISKS comes out so
irregularly.  The answer of course is that I run it in odd moments, whenever
I can.  If you ever think you missed an issue or think that your
subscription might have been dropped, please check the various RISKS Web
sites and mirrors for the latest issue.  (Even when I prune the list
militantly from previous invalid addresses, I sometimes receive as many as
300 bounces on the next issue.  I gather that USENET loses an issue now and
then as well.)

------------------------------

Date: Sat, 03 Apr 1999 17:04:39 -0500
From: "W.T. Shymanski" <wtshyman@mb.sympatico.ca>
Subject: GPS setup error affects dredging in California
                                                                            
The 22 Feb 1999 "Engineering News Record" in an item titled "Dredge
spoil misplaced due to alleged GPS programming error" reports that 600,000
cubic yards of dredged spoil were dumped almost half a mile from an approved
site, off the coast of Orange County, California, due to an error in keying
in co-ordinates into a GPS receiver.
                                                                            
A new GPS unit had been installed on a tug, and apparently the operator
keyed in the co-ordinates in base 60 ( degrees, minutes, seconds) instead of
in base 100 ( degrees, minutes, decimal fraction of a minute) that the new
GPS used.  The error was detected when the crew of the tug noticed another
tug and barge dumping spoil in the approved site.
                                                                            
Misinterpretation of the display units of measurement is a fairly common
problem in user interface design and is probably responsible for no end of
wasted paper, misprogrammed VCRs, and in at least one case ( the 767 "Gimli
Glider" incident) a serious threat to air safety.
                                                                            
W. T. Shymanski <wts@ieee.org>

------------------------------

Date: Thu, 8 Apr 1999 13:42:06 -0400
From: Paul_Walczak@mail.arl.mil
Subject: Potential RADHAZ

[From an anonymous source]

I worked with the PRC-138 for over 5 years now.  I was teaching some Korean
soldiers how to operate it with a wire antenna hanging out the window.  Well
this is not the most optimum antenna and it provide not to be by being able
to watch smoke start curling off my finger tips while operating the radio.
The manual on this radio states that the radio must be grounded and the 20
watt manpack set comes with a strap and small ground rod.  The PRC-104 has
this same problem if you build a poor antenna that the radio cannot match
to.  It probably stand the same that 125 watt systems in vehicles need to be
grounded also.

 Subject:      [SIGNET] AN/PRC-138 Potential RADHAZ
 
1. Testing of the AN/PRC-138 HF radio by the Canadian Military has revealed
a non-ionizing radiation hazard.
 
2. This message is posted to inform you and to find out if any similar
incidents have occurred with radios with US forces.  Also, if this condition
is known, what are we doing about it to prevent this hazard?
 
3. The Canadian PM for the 138's received reports from users in Bosnia that
electrical shocks were received from the AN/PRC-138 in a man-pack
configuration and when used as a temporary communications system in a
vehicle.  It had also been reported that electrical shocks were being
experienced by users of the 138 when installed in a vehicle mounted 125 Watt
Power amplifier system in the Canadian ILTIS (jeep-type) vehicle.
 
4. The investigation revealed the AN/PRC-138 radio produced electrical
shock/RF burn hazards when configured as a man-pack or installed as in the
ILTIS in the 125 Watt configuration.  A man-pack operator would feel
electrical sensations from any conductive part on the radio front-panel and
uninsulated screw on the handset during transmission.  The investigation
also revealed that the sensations were worst when humidity conditions were
dry.  In the ILTIS, the RF burn sensation was not limited to the radio
equipment but also any other uninsulated and ungrounded conductors such as a
watch bracelet.  The electrical sensations created by the contact current
could also cause a knee-jerk reaction which in itself could cause an
accident.
 
5. The man-pack tests utilized the radio at 20 Watts over several
frequencies with both the whip antenna, model number AT271A/PRC (NSN
5985014248333) and the dipole antenna, model 1903AD (NSN 5985013567620).  A
safe distance of 0.75 metres from the whip and 1.5 metres from the dipole
transmitting antennae was measured.  In order to eliminate any potential
confusion when antennae are exchanged, a safe distance of 1.5 metres should
be observed for both antennae.
 
6. Personnel requiring more information or a copy of the complete test
results should send their requests to the undersigned.
 
 Major RK (Kevin) Ferguson
 Canadian Forces Liaison Officer - Signals
 714 Signal Towers
 Fort Gordon, GA  30905-5680
 
 Phone:        Comm    (706) 791-4163
       DSN     780-4163
 Fax:  Comm    (706) 791-7829
       DSN     780-7829
 E-Mail:       fergie@emh.gordon.army.mil

------------------------------

Date: Thu, 15 Apr 1999 17:50:14 -0400
From: "Ben Bederson" <bederson@cs.umd.edu>
Subject: Space character in number causes silent Excel miscalculation

Error of US$19,130 !

I have found Microsoft Excel to be very good at mixing different data types
without having the user to specify those types.  However, the fact that the
types are not specified explicitly pose a risk. I recently had a budget
submitted and approved that turned out to add up to US$19,130 over what the
grand total said it did.  The problem was that the $19,130 item was actually
listed as "19, 130" The space character was barely distinguishable on the
screen (partially because of the use of a proportionally-spaced font and the
fact that the space was directly after a comma).  It was only when I printed
the spreadsheet later on that I noticed it (after the budget was approved).

Normally, this error stands out because Excel by default left-justifies text
and right-justifies numbers.  However, I had specifically right-justified
the column in question earlier. The issue here is that the "19, 130" was
interpreted by Excel as text rather than as a number.  Since Excel doesn't
generate warnings when adding text, but rather interprets it as 0, I had no
notification of the problem.

This is an instance of a general risk in the trade-off that often comes with
making interactive systems usable in that many mundane tasks are automated
(such as type specification), and warnings are eliminated resulting in the
user not knowing how things are interpreted.

Prof. Ben Bederson, Computer Science Department, HCIL, University of Maryland
College Park, MD 20742 1-301-405-2764 www.cs.umd.edu/~bederson

------------------------------

Date: Mon, 5 Apr 1999 08:57:43 -0400 (EDT)
From: Gary McGraw <gem@rstcorp.com>
Subject: Security Hole in Java 2

Karsten Sohr <sohr@mathematik.uni-marburg.de> at the University of Marburg
in Germany has discovered a very serious security flaw in several current
versions of the Java Virtual Machine, including Sun's JDK 1.1 and Java 2
(a.k.a. JDK 1.2), and Netscape's Navigator 4.x.  (Microsoft's latest JVM is
not vulnerable to this attack.)  The flaw allows an attacker to create a
booby-trapped Web page, so that when a victim views the page, the attacker
seizes control of the victim's machine and can do whatever he wants,
including reading and deleting files, and snooping on any data and
activities on the victim's machine.

The flaw is in the "byte code verifier" component of the JVM.  Under some
circumstances the verifier fails to check all of the code that is loaded
into the JVM.  Exploiting the flaw allows the attacker to run code that has
not been verified.  This code can set up a type confusion attack (see our
book "Securing Java" for details http://www.securingjava.com) which leads to
a full-blown security breach.

We have verified that the flaw exists and is serious.  Attack code (in both
applet and application form) has been developed in the lab to exploit the
flaw.  Sun and Netscape have been notified about the flaw and they are
working on a fix.

What?! RISKS in mobile code?  We're happy to alert you to yet another lesson
regarding the classic tradeoff between security and functionality.

Dr. Gary McGraw                      Prof. Edward W. Felten
Reliable Software Technologies       Secure Internet Programming Lab
gem@rstcorp.com                      Dept. of Computer Science
                                     Princeton University
http://www.securingjava.com          felten@cs.princeton.edu

  [Reportedly fixed in 1.2.1.  PGN]

------------------------------

Date: Thu, 18 Mar 1999 12:07:39 -0500
From: "Edelson, Doneel" <doneeledelson@aciins.com>
Subject: Vancouver Hospital (Re: RISKS-20.23)

I spoke with Mr. Lee on the phone and he said that he stands by his story.
He also said that some of the specific wording in the Risks Digest summary
of the story was significantly different from his actual story.
He also requested that the Risks Digest not carry any more material from his
column.  To that end I plan to no longer forward his column to you.

Here is my statement on the matter. I am CC:ing the hospital, and plan to
send them a copy of the actual posting from Risks when it is published.
   [Sorry for the delay.  I've been away too much.  PGN]

In RISKS-20.23, I noted a report from Leonard Lee's Glitches of the week,
Newsbytes News Network<<http://www.newsbytes.com/>>, 24 Feb 1999, concerning
problems in the Vancouver Hospital computer system that resulted in errors
in patient medical records. In response, I received the following
communication from Murray T. Martin, President & CEO of Vancouver Hospital:
"As you are in error, we write to ask you to remove the postings, to
apologize to VHHSC, and to initiate steps to advise those who may have
accessed the information.  Vancouver Hospital and Health Sciences Centre
takes very seriously these defamatory statements, and has advised the
software vendor of our concerns.  We reserve the right to take legal action
on the alarming and libelous statements.

In particular, your statement as fact that the software and process errors
had the effect of "significantly delaying treatments and discharges, and
increasing costs" is incorrect and defamatory.  There is no evidence to our
knowledge of any of these effects, and ask that if you have such evidence,
you provide it to us."

I apologize to Vancouver hospital for any harm that this has caused.

------------------------------

Date: Thu, 8 Apr 1999 09:59:10 -0400
From: "Benjamin B. Bederson" <bederson@cs.umd.edu>
Subject: Microsoft reschedules Memorial Day

Microsoft Outlook 98 has scheduled Memorial Day for May 24, 1999 instead of
May 31, 1999.  I thought this kind of power was reserved for the Federal
Government!  According to my Microsoft contact, this feature is included in
Office 2000 as well - and so apparently there is not much quality assurance
in the data that Outlook comes with.

This is actually a fairly serious problem for those of us that rely on
Outlook.  I managed to schedule a visitor coming from another Country to
give a talk on what turns out to be Memorial Day.  If the plane tickets the
visitor bought are non-refundable, we could have some trouble.  I'm sure
that the Microsoft licensing agreement absolves them from responsibility for
this kind of error.  So, the risk is, make sure you trust your data
sources...

Prof. Ben Bederson, Computer Science Department, University of Maryland, 
College Park, MD 20742 www.cs.umd.edu/~bederson  1-301-405-2764

------------------------------

Date: Wed, 07 Apr 1999 14:04:35 -0400
From: hdk@psu.edu (Herman D. Knoble)
Subject: Risk of not backing up PGP Key Ring files

A professor and psychologist at Penn State kept state mandated records for
each client in a separate Word file. He obtained PGP 5.0 for Windows 95 and
set up a Username and Passphrase. He then used PGP to encrypt each client
file. He backed up the encrypted client files and after reassuring himself
that he could recover any encrypted file, he erased the plain text files.

Then his fixed disk crashed. He installed a new fixed disk and installed PGP
5.0 again, and attempted to re-establish what he called "the key" by using
the same Username and Passphrase.  He had never backed up the key ring file
(secring.skr) thinking that he could re-create what he thought was "the PGP
key". Needless to say his 150 or so encrypted client records are not
decipherable. Thus, for all practical purposes, that data is lost and the
encrypted files may as well be erased.

Moral: When encrypting any data, find out how to and what to back up for 
BOTH the data and key(s) . Then secure each of these backed up media,
probably under lock and key, with a copy not in the same building as the
computer. At least periodically verify that backed up data can be decrypted
successfully on an independent computer.

Herman D. Knoble, Penn State Center for Academic Computing, University Park,
PA  16802-2101  +1 (814) 865-0818 hdk@psu.edu http://www.personal.psu.edu/hdk

------------------------------

Date: Mon, 05 Apr 1999 01:24:07 -0700
From: Chuck Karish <karish@well.com>
Subject: Responses to Melissa

This evening I watched an item on the Melissa virus on a cable TV technology
newsmagazine show.  The reporters talked to someone at a company that
monitors Internet performance, who attributed two days during which
performance was degraded by 20% to 23% to many downloads of virus checking
tools and information about the virus.

Then they asked people from a virus-checking software company how to defend
against such viruses.  They said "Always run a virus checker, and update
your database frequently".

This struck me as being incomplete.  Why does virus defense have to be
reactive?  I'd heard that Microsoft has a free downloadable Word viewer that
wouldn't have the macro security hole.  So, off to the Microsoft Web site.

The prominently-displayed short note there on Melissa wasn't much different
from what the virus-checker guys said on TV.  "Turn off macros, use a virus
checker, update it frequently."  No mention of what to do if your machine
has already been infected (so that turning off macros might not be
possible), no mention of a macro- ignorant doc viewer.

I found the download index that showed the Word document viewer.
Unfortunately I couldn't download it, because my browser (IE4.0) reported a
programming error in the download page.

So, I settled for downloading a white paper on security features in Office
2000.  This was a Word document packaged in a self-extracting executable
program.  Not the ideal format to inspire confidence in this reader!  The
paper (o2ksec.exe) does contain useful information, including the registry
settings to disable VBA macros or add-ins, and suggestions for locking
critical sections of the registry without interfering unduly with user
activities.  Any guesses as to how many sysadmins and self-admins will
follow those instructions?

Doesn't anybody get it?

    Chuck Karish      karish@well.com    (650) 329-8655

------------------------------

Date: Thu, 8 Apr 1999 15:36:57 +0100
From: "Charles Arthur, The Independent" <carthur@independent.co.uk>
Subject: Risks of "Melissa passed this way"

Big financial institutions were quick to put in place automated safeguards
against the Melissa virus. Which didn't explain why one coworker received an
e-mail on Tuesday, eight days after the affair hit most UK sites, headed
"Important message from GWUser". It came from GWUser, who (the address
showed) was based at a UK "Big Four" high street bank. In fact, it was
Melissa-generated.

The mail itself though did not contain the dreaded document, nor any
document; instead there was a message from the Bank's virus-checking
software saying it had removed the document. The address list, meanwhile,
showed 25 addresses - some inside, some outside the Bank (such as
ourselves).

However, almost simultaneous with this message came another one, by
automaton, from the Bank's security systems. "You have been infected by the
Melissa virus", it said (I'm busking a little - the colleague has since
deleted them). This message had been sent out to all the recipients on the
same list. The implication of the message was that it couldn't identify the
source of the message it was complaining about as being inside its walls,
and was blaming us for sending it, rather than warning us.

Even so, two clear risks:
1) doubling the load on mail systems by having two messages, even though
   the virus-checker did do its work and killed it (thus saving further
   propagation);
2) confusing the hell out of recipients who aren't savvy enough to follow
   what had happened - which included the original colleague here.

We however have reason not to worry about this. We run Macs, use an old
version of Word without macros but with forward compatibility, and use Lotus
Notes rather than Exchange or OExpress. Virus writers have not expanded to
fill that particular niche, if they ever can/will.

Charles

------------------------------

Date: Tue, 6 Apr 1999 18:46:50 +0100 (BST)
From: Scott M Keir <scott@tardis.ed.ac.uk>
Subject: Melissa and poor security model of Word Macros (Waide, RISKS-20.26)

> 4 Microsoft praised for having GUIDs in documents.

I certainly hope that 4) is followed by:

5 Microsoft is condemned for developing a language with a poor security
  model.  

That Melissa can disable security-related menu commands and alter the
'security' features of the macro language interpreter shows what a poor
security model the language has.  Perhaps this was acceptable when the macro
language was used for simple templates in documents, but with the emergence
of macro virii and the expansion of the language to fairly effectively
control the machine, this is not acceptable any more.

Cross-platform languages such as Tcl and JavaScript have some security model
which attempts to reduce the ability of code to damage your system in some
way (e.g. Tcls Safe-Tcl security model is now fairly advanced, and allows
users to run scripts in 'Safe Mode' preventing scripts from accessing
sensitive parts of the machine).

That any 'security' in Word macros can appear to be overridden by macros is
poor show on Microsoft part.  They need to fix this, and soon.

Scott Keir   scott@tardis.ed.ac.uk   www.tardis.ed.ac.uk/home/scott/ |

  [Incidentally, there is confusion among the various news reports of
  Melissa as to exactly when and how the GUID entered into the
  identification of the perpetrator.  Can anyone who really knows
  enlighten us?  PGN]

------------------------------

Date: Fri, 9 Apr 1999 21:27:19 -0400 (EDT)
From: hes@unity.ncsu.edu
Subject: Mainframe virus (Kabay, re: RISKS-20.29)

The Christmas Tree "virus" affected VM systems some 10+ years ago.  (IIRC
it really affected PROFS.)  I think it is  reasonably comparable to Melissa.  

>  Microsoft engineers decided to dispense with a security kernel ...

If a computer has an integrated word processor in its mail software, then it
very well might not take supervisor privileges for a word processor macro to
send mail.  I think this was the source of the PROFS vulnerability.

--henry schaffer

------------------------------

Date: Wed, 7 Apr 1999 13:09:48 -0400
From: Richard Landes <cms@mille.org>
Subject: Millennialism in the Western Hemisphere 

CALL FOR PAPERS

The Center for Millennial Studies at Boston University in conjunction 
with the American Studies Department at Brandeis University announce the 
upcoming conference sponsored by the Lilly Endowment Foundation, Boston 
University, and Brandeis University.

NEW WORLD ORDERS: MILLENNIALISM IN THE WESTERN HEMISPHERE
November 7-9. 1999

An interdisciplinary inquiry examining the wide range of millennial
movements in the Americas: their origins, traditions, interpretations and
consequences, both religious and secular from the perspective of elite,
popular, or counter-culture.  Papers on the historiography of millennialism
in the Americas will also be considered for presentation.

DEADLINE For Abstracts Is JULY 1, 1999 [presentations 20 minutes in length]

Contact:
Beth Forrest, Center for Millennial Studies at Boston University
704 Commonwealth Ave., Suite 205, Boston, MA 02215
 1-617.358.0226  cms@mille.org  http://www.mille.org

  [Richard and his CMS colleagues at Boston University are looking at the
  BIGGER PICTURE of Millennialism!  PGN]

------------------------------

Date: 23 Sep 1998 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
Subject: Abridged info on RISKS (comp.risks)

 The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) 
 if possible and convenient for you.  Alternatively, via majordomo, 
 SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, 
   SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
   INFO     [for unabridged version of RISKS information]
 .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears).
 .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>.
=> The INFO file (submissions, default disclaimers, archive sites, 
 copyright policy, PRIVACY digests, etc.) is also obtainable from
 http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
 The full info file will appear now and then in future issues.  *** All 
 contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
 ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
   [volume-summary issues are in risks-*.00]
   [back volumes have their own subdirectories, e.g., "cd 19" for volume 19]
 or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
 PostScript copy of PGN's comprehensive historical summary of one liners:
   illustrative.PS at ftp.sri.com/risks .

------------------------------

End of RISKS-FORUM Digest 20.30 
************************

home help back first fref pref prev next nref lref last post