Article 1637 (1 more) in misc.news.southasia (moderated):
From: ramani@saathi.ncst.ernet.in (S.Ramani)
Subject: India - Software Glitch Causes PSLV Failure
Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
Organization:  NCST, Bombay
Date: Tue, 4 Jan 94 13:18:57 GMT

   Country - India
   Source  - Times of India, Bombay Edition, 4th Jan 94
   Sent by - S. Ramani

Bangalore: A software error in the pitch-control loop of the onboard guidance
and control processor led to the failure of the Polar Satellite Launch
Vehicle's (PSLV) maiden flight, according to the expert's panel which probed
the setback, reports UNI.

Their findings were released by the Indian Space Research Organization
(ISRO) here on Monday.

The PSLV-DI failed after a smooth lift-off from the Sriharikota range
on September 20, 1993.

Verify your backups

The message below, from managers of wuarchive.wustl.edu, is one with
which readers of RISKS should be familiar.  How many of us are in the
same position?

For those of you who don't know, wuarchive.wustl.edu is one of the
largest and busiest Internet public archive sites, accessible via
anonymous FTP and other means.

----- From /README.NOW in wuarchive.wustl.edu -----
The entire archives were destroyed the afternoon of Thursday, January 13th
due to a bug in the system crash dump routines.  There have been serious
problems restoring backups due to a failed tape drive -- we have gotten a
loaner drive, but there may not be any recent viable backups of the archives.

Translation: everything was lost, the archive maintainers are scrambling
to find copies of all of the missing files -- it's probable that some
files were lost permanently.

Thanks for your patience,

The Management

Safety in Telescript

Phil Agre's message of January 6th ("Wild agents in Telescript?") brings
up some very good points. In this message I would like to describe some
of the safety features of Telescript that are used to prevent both
ill-intentioned scripts (e.g., worms, viruses) and buggy scripts from
damaging a Telescripted network.

1) The Telescript language is interpreted, rather than compiled. Thus,
Telescript programs cannot directly manipulate the memory, file system or
other resources of the computers on which they execute.

2) Every Telescript agent (i.e, Telescript program that can move around a
Telescript network) is uniquely identified by a telename. A telename
consists of two components: an authority which identifies the "owner" of
the agent (e.g., the Personal Communicator from which it originated) and
an identity which distinguishes that agent from any other agent of the
same authority. The authority component is cryptographically generated
and cannot be forged. Thus, when an agent is transferred from one
Telescript engine to another, it is possible to verify (using
cryptographic techniques) that the agent is indeed of the authority it
claims to represent. (N.B.: a Telescript engine is a program capable of
interpreting and executing Telescript programs).

3) Every Telescript agent has a permit which limits its capabilities.
Permits can be used to protect users from misprogrammed agents (e.g., an
agent that would otherwise "run away" and consume resources for which the
user would have to pay) and to protect Telescript service providers from
malicious agents. Two kinds of capabilities are granted an agent by its
permit. The first kind is the right to use a certain Telescript
instruction, e.g., the right to create clones of itself. The second is
the right to use a particular Telescript resource and by which amount.
For example, an agent is granted a maximum lifetime, a maximum size and a
maximum overall expenditure of resources (called the agent's allowance),
measured in teleclicks. An agent's permit is imposed when the agent is
first created and is renegotiated whenever that agent travels to an
engine controlled by a different administrative authority. If the agent
exceeds any of its quantitative limits, it is immediately destroyed by
the Telescript engine where it is executing.

4) Telescript agents move around a Telescript network by going from one
Telescript place to another. Telescript provides an instruction -- go --
that gives agents this travelling capability (if granted by their permit,
of course). Places are Telescript programs in their own right. Before
accepting an incoming agent, a place can examine the agent's telename,
permit and class (N.B.: an agent represents an instance of a Telescript
class; thus, the class of the agent represents the "program" that the
agent executes. Like authority names, class names cannot be forged).
Based on that information, the place can do any the following:

    a) Do not allow the agent to enter.

    b) Allow the agent to enter but only after imposing upon it a permit
more restrictive than the one it currently holds (e.g., the agent is only
allowed to consume 100 teleclicks while in this place).

    c) Allow the agent to enter and execute under its current permit.

5) When a Telescript process (agent or place) interacts with another
Telescript process, the telename and class of the former is available to
the latter. This enables Telescript applications to control who can
interact with them and in what ways.

I hope this (brief) description of some of the more pertinent security
features of Telescript will help Risks readers understand how we've
addressed the issues raised in the NYT article and in Phil's message.

-Luis Valente, General Magic, Inc.

Slippery Folks in the Oil Business

Folks who are interested in the extent of industrial espionage (and thus the
need for secure networks and secure encryption) will want to check out the
lead story in January 6,1994 edition of the Wall Street Journal.

The details are more arcane than even the best spy novels, but the highlights
are:

* Information brokers would contact companies in the oil business and offer to
"help" them win contracts for a percentage. They provided information gained
through shmoozing and buying off insiders as part of their help.

* Illicit payments reported in the story paid to the industrial spies ranged
from $10,000 to $600,000. The contracts were worth $100 million and up.

* The Swiss government refuses to disclose information about the accounts
where the loot is deposited because it says that this sort of behavior is not
against the law in Switzerland.

Risks of Domain Names

At the end of December, after NBC Nightly News announced an address for
Internet email - "nightly@nbc.com" - I wondered if the other US television
networks had also established an Internet presence.  A quick check of the
Domain Name Service revealed the existence of "abc.com", "cbs.com", and
"fox.com".

A search in the InterNIC registration database showed that none of these
represented the organizations I would normally associate with those names.
Instead of TV networks, I found a design firm, a consultant, and an online
service.

The obvious risk is that of mistaken identity.

Less clear is the impact that such "misleading" email addresses may have on
the way people do business.  Increasing numbers of people do much of their
professional interaction via email.  Email addresses are appearing on business
cards and becoming as accepted as postal addresses.  The domain name portion
of an email address is coming to represent an organization.

Domain names are given out on a first-come-first-served basis.  This raises
several questions.  Will large companies consider "misleading" domain names to
violate their trademarks?  Will "misleading" domain names matching those or
large companies be registered with the intent of receiving compensation
for them when the companies eventually come on the Internet?

Not all the networks have been lagging behind, by the way - the Public
Broadcasting Service ("pbs.org") has been on the Internet for over a year.

   [By the way, I chided Matt for having such an amorphous net address.
   The "chron" gets grandfathered because of its early access to the Internet,
   and is actually the Houston Chron.  PGN]

Re: Mail forwarding as easy as Call forwarding

>Has anyone ever tried to have 1600 PENNSYLVANIA AVENUE forwarded?

Yes. In January of last year, much of its mail was forwarded to Houston,
Texas. :-)

Cellular phone security features...NOT!

Last night I purchased a Cellular phone.  While reading through the manual I
found a section labeled "Security features" Neat.  The manual talked about two
security codes, a 3 digit number to unlock the phone and a 6 digit number that
is used to change the unlock number and a number of other security features.
The 6 digit number can also be used to unlock the phone.  The 6 digit number
is not easily reprogrammed.

The 3 digit number was included with the documentation; however, I couldn't
find the 6 digit number.  So I called the technical help line.  Their answer
floored me.  "The 6 digit number is '123456', '654321', or all zeros.  Just
give one of them a try."  So much for security.

The manual did state that a different 6 digit number should be chosen
for each phone.  Sigh.

Matthew Goldman  E-mail: goldman@orac.cray.com Work: (612) 683-3061

Harvard Case of Stolen Fax Messages

This is dated but worthwhile for readers of RISKS.  The Boston Globe of
December 15 published an column by Alex Beam about an academic battle over the
Harvard Semitic Museum.  The Museum has an outstanding collection but was
recently closed down, leading to very public battles involving many
celebrities. What caught my eye in Beam's description of the controversy is
the following quote:


"Stager (the museum's director) instructed his secretary to remove used fax
cartridges from the trash, unravel the carbonized ribbon and reconstruct the
staff's facsimile transmissions, to monitor surreptitious fund-raising> (This
little trick won't work on modern laser-printed fax machines, in case you're
getting any ideas.)"

"Stager 'talked to the (Harvard) general counsel's office, and asked them if
it was against the law," his assistant, Eileen Caves, told the Harvard
Crimson.  They 'classified the carbon as ''abandoned material that was left in
a public place'' and said it was therefore public information."

Risks?  It may have happened at Harvard, it may be possible to reconstruct
messages, and it may be why lawyers should be buried 35 feet underground
since, deep down, they are very nice people.

Sanford Sherizen, Data Security Systems, Natick, MA

Spontaneous recovery from "NOMAIL" setting?

Setting "NOMAIL" to leave a LISTSERV keeps open the option of an easy return,
but it may also lead to an unexpectedly full emailbox.  Early in January, I
began receiving regular messages from a LIST that I had set to NOMAIL in 1991;
the LIST owner told me I was set to NOMAIL, but messages only/stopped when I
sent an UNSUBSCRIBE message.  Earlier this week (JAN. 16), I received my first
update from RISKS in several years, under the same conditions, with my
membership set to NOMAIL.  Today, I received 80 messages from a LIST I had
left (through NOMAIL) about four years ago and quickly sent an UNSUBSCRIBE
message (which was acknowledged).

A student of mine has been doing research on a number of lists and a
substantial fraction of the respondents tell about similar phenomena?  Is the
NOMAIL setting really a time bomb that may flood your mail directory
unexpectedly?  (I was fortunate in TELNETing from Berkeley today just as the
avalanche had begun.)  If you have an explanation of this process, I would
appreciate hearing it.

Ron Ragsdale, Professor Emeritus, Ontario Institute for Studies in Education
252 Bloor Street West, Toronto, Ontario, Canada M5S 1V6  (416) 923-6641 X2252

Re: Hacker nurse makes unauthorised changes to prescriptions

In RISKS-15.37, John Jones quoted The Guardian (21st December, 1993)'s report
on the conviction of a male nurse who hacked into a hospital's computer system
and modified entries, including prescriptions.

Tow or three weeks back, the Guardian Weekly (probably in its Le Monte
section) reported the widely spread practice (in may parts of the
world) of illegally obtaining human organs for reselling to transplant
patients.  Among the many methods (such as kidnapping), one is to
simulate heart failure on the monitoring machines in hospitals.

Li Gong, Computer Science Lab, SRI International, Menlo Park, California

Proposal for new newsgroup on safety-critical systems

Proposal for new newsgroup on safety-critical systems
Comments please, to news.groups.

Proposed name: comp.safety or comp.safety-critical or comp.risks.safety ...

Charter
  A forum for discussion of the engineering and assessment of safety-critical
  systems, with special reference to computing.

Moderated group - Proposed moderator:
  Jonathan Moffett (jdm@minster.york.ac.uk)
  Senior Research Fellow in the High Integrity Systems Engineering Group
  Department of Computer Science, University of York, York YO1 5DD, England
  Tel: +44 (0)904 432788, Fax: +44 (0)904 432767

Discussion

The newsgroup would be a forum for discussions about systems safety which
could afford to be more detailed than comp.risks and more specialised than
comp.software-eng.  It would cover safety requirements and risks, safety
engineering techniques and safety assessment.  Its focus would be on
safety-critical computer systems and computer-supported design and assessment
of general system safety.

There is no newsgroup at present which deals specifically with systems
safety - in a search through the Usenet postings about newsgroups the
string "safe" appears only in rec.pyrotechnics, alt.irc.corruption and
warnings about humor.

There is of course comp.risks, with which the new group would overlap but not
compete; comp.risks is wider in scope than safety, and is not very much used
for technical discussions.  There would also be overlaps with:
comp.software-eng, which is a very high-activity group of which safety issues
are a very low proportion; and comp.specification[.z], because of the indirect
relationship (via high assurance) between formal specification and safety.
Other possible overlaps are comp.realtime and comp.human-factors.

There appear to be a gap in the market which a safety newsgroup could fill.

It should be moderated, because safety is a very sensitive issue, subject
both to flaming :-) and hoaxes.

    [A SAFE bet!  The proposal sounds like a good idea.  Be sure to send
    your comments to jdm and news.groups, but CC: RISKS if you like.  PGN]

Privacy Digests

Periodically I will remind you of TWO useful digests related to privacy, both
of which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in privacy
problems.  RISKS will continue to carry general discussions in which risks to
privacy are a concern.

* The PRIVACY Forum Digest (PFD) is run by Lauren Weinstein.  He manages it as
  a rather selectively moderated digest, somewhat akin to RISKS; it spans the
  full range of both technological and non-technological privacy-related issues
  (with an emphasis on the former).  For information regarding the PRIVACY
  Forum, please send the exact line:

information privacy

  as the BODY of a message to "privacy-request@vortex.com"; you will receive
  a response from an automated listserv system.  To submit contributions,
  send to "privacy@vortex.com".

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
  run by Leonard P. Levine.  It is gatewayed to the USENET newsgroup
  comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
  forum, and was established to provide a forum for discussion on the
  effect of technology on privacy.  All too often technology is way ahead of
  the law and society as it presents us with new devices and applications.
  Technology can enhance and detract from privacy.  Submissions should go to
  comp-privacy@uwm.edu and administrative requests to
  comp-privacy-request@uwm.edu.

There is clearly much potential for overlap between the two digests, although
contributions tend not to appear in both places.  If you are very short of time
and can scan only one, you might want to try the former.  If you are interested
in ongoing detailed discussions, try the latter.  Otherwise, it may well be
appropriate for you to read both, depending on the strength of your interests
and time available.
                                                  PGN

ISSA Conference Announcement

TO THOSE WITH RESPONSIBILITY FOR -- OR AN INTEREST IN -- INFORMATION SECURITY:

The Information Systems Security Association (ISSA) is holding its 11th Annual
Conference and Trade Show, March 13-17, 1994, at the Fairmont Hotel in San
Francisco, Calif.

This info-security conference will feature 72 educational sessions divided
among the following tracks: Network, Distributed and Client/Server,
Management, Technical, Government/Legal, Audit, Awareness, and Business
Continuity. Major security vendors will exhibit at the ISSA trade show. There
will be a tour of Silicon Valley corporations.

The following industry experts will present addresses: Harry Saal (Network
Data General) -- The Super Digital Highway; James Settle (FBI) -- computer
crime investigation; and Gail Warshawsky (Lawrence Livermore) -- computer
security awareness.

For an advance program, registration information, and ISSA membership
information, please contact ISSA Headquarters at 312/644-6610 x3410 (voice),
or 312-321-6869 (fax). Mention where you saw this notice!

EARLY BIRD DISCOUNT IF REGISTRATION POSTMARKED ON OR BEFORE 1/31/94.

Dave Lenef, Marketing/Communications Coordinator
Information Systems Security Association (ISSA)  312/644-6610

Search RISKS using swish-e 

Report problems with the web pages to the maintainer