The RISKS Digest
Volume 9 Issue 18

Monday, 28th August 1989

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Proposal for SDI software center
Gary Chapman
Computerworld article on high-tech weapons
George Entenman
CHAOSNet used in `SNUFF' snuff
PGN
DMV records, and individual privacy and safety
PGN
Another vehicle guidance system
Pete Lucas
Medics touch computers?!?
Sam Bassett
Unfounded fault-probability claims
Dieter Muller
Lowest-bidder or weak specs?
David A Honig
Automated roads, drive-by-wire, bicycles, and the elderly
PGN
The Guardian vs computer passwords
Brian Foster
Info on RISKS (comp.risks)

Proposal for SDI software center

Gary Chapman <chapman@csli.Stanford.EDU>
Mon, 28 Aug 89 17:58:15 PDT
This is an item from the newsletter Advanced Military Computing, 8/28/89, p.6:

Strategic Defense Initiative managers wrestling with the computer aspects of
nuclear war plan to develop a Strategic Defense System software center to meet
their application needs.

"If there is an Achilles heel to SDI, it is the critique that we can't make all
the software work; if we do get it to work, it may not work right; it won't be
reliable; and it will cost millions of dollars and comprise millions of lines
of code," said Lloyd Acker, associate department head National Testbed Systems
for the MITRE Corporation.

Acker expects the center to be fully operational by 1991.  He said
identification of the center's software engineering environment requirements
should be completed this year with early prototypes identified and in
development.

He said the software center, which get off the ground soon, can help reduce SDI
software development risks as well as improve software productivity, integrity,
integration, security, practices, standards, and training.

Acker said the software center would:

*       Be a training center for software managers and engineers.  "A
        significant turnover in experienced software managerial and
        engineering personnel can be expected in the next decade, while
        software engineering practices will undergo rapid change."

*       Exhibit software engineering environments to include tools
        supporting methods and standards, and serve as a testbed for
        SDS software quality.

*       Be a research center for software technologies suited to the SDS
        mission.  Acker said some of the areas of research include
        parallel processing, neural networks, object-oriented program-
        ming, and expert systems.

*       Track the technology development in other programs that could
        have an effect on SDI including those of DARPA, NASA, Software
        Engineering Institute, industry, and academia.

*       Be a trusted repository for SDS software as it is validated and
        certified.  An early focus will be how to prevent the injection
        of computer viruses into the system.

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

Jeez, where have I heard all this before?  I thought this was what the National
Test Facility in Colorado Springs was supposed to be doing.  Now we're going to
build something with an identical mission, a facility which will do world-class
research on parallel processing, neural networks, object-oriented programming,
and expert systems to boot.  Sounds like yet another SDI boondoggle to me.

The center will "Be a trusted repository for SDS software as it is validated
and certified."  How do they expect to do this?

"An early focus will be how to prevent the injection of computer viruses into
the system."  If this center has to be built, it would seem to me that a more
reasonable place to start would be to figure out whether the SDI makes any
sense at all, or whether it's just a screwball idea designed to "bucket
brigade" taxpayer money to defense contractors and think tanks like MITRE.  Who
cares if there are viruses in something that's not designed to actually
"work"?

Gary Chapman, Executive Director, Computer Professionals for Social Responsibility


Computerworld article on high-tech weapons

George Entenman <ge@mcnc.org>
Fri, 25 Aug 89 10:07:11 EDT
Risks readers should be interested in an article in COMPUTERWORLD (August 21,
1989, Vol. XXIII, No. 34, page 1) by James Daly of the CW staff entitled
"High-tech weapons, low-tech GIs".  The article contains few surprises for
readers of this newsgroup, but it neatly summarizes many of the risks
associated with computerized weaponry.

The article's main thesis:

  Despite the investment of huge amounts of training time, effort and money,
  some critics argue that today's super-sophisticated armaments have become so
  complicated that they have outgrown the ability of sailors and soldiers to
  use them effectively.

It also explains why we may be irrevocably stuck with high-tech weapons:

  Reports ranging from a B-1 bomber crashing when it hit a pelican to the
  embarrassing Divad project — a computer-operated anti-aircraft gun that once
  identified a rotating latrine fan as the closest threatening target — have
  initiated brass-filled investigative hearings....  The trouble is, the
  military culture may already be too infatuated with leading-edge devices to
  ever turn back....  [The] Pentagon's electronics procurements have more than
  tripled since the beginning of the decade and now account for more than 40%
  of the military's production costs.

The Pentagon's "solution":

  Because the list of the Pentagon's high-tech goof-ups is long, the Defense
  Department has begun to seriously investigate the use of artificial
  intelligence.


CHAOSNet used in `SNUFF' snuff

Peter Neumann <neumann@csl.sri.com>
Thu, 24 Aug 1989 10:44:34 PDT
Undercover police in San Jose, California, have been tracking BBOARDS for
several years, looking for computer users who boasted about their criminal
exploits.  It was such activity that led them to Virginians Dean Ashley Lambey,
34, and Daniel T. Depew, 28, who have been accused of conspiring to kidnap a
young boy to be filmed as they molested him and then killed him.  [Source: San
Francisco Chronicle, 24 August 1989, article by Tracie L. Thompson]


DMV records, and individual privacy and safety

Peter Neumann <neumann@csl.sri.com>
Sun, 27 Aug 1989 11:30:04 PDT
In previous installments in RISKS, we have discussed the relatively open
availability of the database of the California Division of Motor Vehicles.  In
response to the July 18 murder of actress Rebecca Schaeffer by someone who
tracked her down through DMV records (via an Arizona private investigator),
Gov. George Deukmejian has directed the DMV to restrict release of information,
to protect individual privacy and safety.  (The DMV had 41 million requests in
1988, mostly seemingly business related.)  New rules take place 1 Oct.  They
require bulk users to register and sign restrictive agreements, and impose a
10-day delay on the response in certain cases.  The current practice of
notifying the driver when an individual request is made will thus give the
driver a little warning before the record is mailed out.  (DMV information is
all public record info, but the home addresses of certain drivers — judges,
law-enforcement officers, etc. — are supposedly not released.  Whether they
are actually on-line but suppressed by the system is another matter.)


Another vehicle guidance system (Pete Lucas)

"Pete Lucas - NERC Computer Services U.K." <PJML@ibma.nerc-wallingford.ac.uk>
Fri, 25 Aug 89 16:16:22 BST
More on vehicle guidance: The following is summarised from an article
in 'Personal Computer World' september 1989.

A description is given of a system called AUTOGUIDE, being developed by the
Transport and Road Research Laboratory (TRRL) near Reading, England.
The pilot system uses a digitised map of the area concerned, and a set of
'beacons' (which use an infra-red digital link to inform passing vehicles of
their position, and local traffic conditions).
Passing vehicles presumably 'poll' the beacons which respond by sending data.
Information ('Take the next left', 'Road closed at intersection') is displayed
on an alphanumeric LCD display on the vehicle instrument panel.
Information from the beacons is relayed back to a central computer which
is able to compute vehicle speed by the time taken for individual cars to
pass between the beacons.  In this way, the central computer can identify
congested areas as the congestion develops, and be able to determine
alternate routes.

Siemens, Logica, GEC and Plessey are all involved in the development of
the system, the RAC and AA (both British motoring organisations)
are also part of the various consortia doing the development. The
British government are currently deciding on which consortium to
choose to award the pilot study project to.  Initially, around 300
beacons are likely to be needed in an area the size of London, at
an estimated cost of 5 to 10 million UK pounds.

Possible things to consider as potential risks with such a system::

1) Such a system COULD be made to identify individual vehicles, hence allowing
   the authorities to 'track' individuals as they drive around cities.
   Civil liberties people will no doubt have some comments on this indirect
   'electronic tagging'.

2) Since the system can 'divert' traffic, there is a risk that residents who
   suddenly find a high-speed stream of vehicles diverted down their normally
   quiet streets and may get somewhat uptight about it.

3) I dont know about the details, but it sounds like such a system could
   be easily tampered with.  Criminals who wished to could, for example,
   operate a very powerful beacon and create either congestion or open
   roads to foil police chases. Anyone remember the film 'The Italian
   Job' in which the robbers crashed a trafficlight computer to cover
   their escape by creating traffic chaos?

4) Governments/city authorities could 'fiddle' the system to give an
   unfair advantage to public transport by unethical means - make the
   roads *APPEAR* more congested whilst creating congestion-free zones
   for buses.
                                        Pete L.


Medics touch computers?!?

Sam Bassett RCD <samlb@pioneer.arc.nasa.gov>
Thu, 24 Aug 89 00:35:11 PDT
    I was a bit astounded by Brint Cooper's story of medical personnel in
the hospital he was consulting for being willing to learn the basics of
booting and caring for the computers that held their medical database.
    In my experience, this shows an uncommon amount of good sense on
the part of the medical personnel, and a sharp departure from the normal
behavior of (non-computer-literate) professionals who use computers.  One
wonders how many gripes there would have been in the Toronto stock
exchange if the stockbrokers had been willing to take a similar interest
in the machines on which their living depends.


Unfounded fault-probability claims

Dieter Muller <dworkin@Solbourne.COM>
Thu, 24 Aug 89 12:48:52 MDT
In RISKS 9.17, mentat@walt.cc.utexas.edu (Robert Dorsett) has a gripe
with flight automation:

* Unfounded fault-probability claims by manufacturer (both in program ver-
  ification and hardware reliability).

This is not necessarily true.  Many aircraft manufacturers believe
they have a very firm foundation for the reliability of their
hardware.  One of my former employers leases programs for this very
purpose.  However, these programs are known to have bugs in sections
that ``no one uses'' [read: no one's complained about it being wrong].
Also, in the theoretically working sections, they are using data for
components that was out of date 10 years ago.  By the way, the
justification for all this was that ``the numbers are only used for
advertising anyway.  No one believes them.''

So, the manufacturers are reporting in good faith what the reliability software
tells them, but the software lies.  I was amazed to find out this software
producer has never been sued as a result of the software's claiming a product
would last X amount of time, when the product actually failed much more often.
Maybe no one *does* believe the numbers, but it isn't noised about much....

Dieter Muller


Lowest-bidder or weak specs?

David A Honig <honig@BONNIE.ICS.UCI.EDU>
Wed, 23 Aug 89 19:37:47 -0700
I have seen at least two incidences of RISKS contributors decrying the fact
that they had to deal with systems provided by a "lowest bidder".  It seems to
me that if the specifications are complete and correct then there should be no
problem.  And I cannot think of another decent way to buy systems (the
next-to-lowest bidder?  the highest bidder?)  that will solve the problems.

I realize that formal software techniques are considered
pie-in-the-sky, and the "iterative design techniques" are what really
happens, but isn't the process of analysing and writing specs, and
checking that a purchase meets them, a sufficiently important thing?

I know it takes more effort to specify what you *really* want and
it'll cost more when suppliers give you bids, but at least you're not
trusting something you don't want to.

    [It was of course John Glenn who commented on how he felt knowing that
    he was astronauting around in something that was built by the lowest
    bidder.  The real problem is the extent to which corners have been
    cut so that the contractor does not lose money, or indeed tries to
    maximize profits.  If the "ethic" is that anything goes if you can get
    away with it, then THAT is a problem.  If systems are really built to
    spec, then you should certainly worry whether the spec was adequate.  PGN]


Automated roads, drive-by-wire, bicycles, and the elderly

Peter Neumann <neumann@csl.sri.com>
Mon, 28 Aug 1989 18:29:24 PDT
RISKS received a huge flurry of stuff as follow-ups on this topic [singular],
with considerable overlap, as well as second-order and third-order discussion.
I'll try to cull out the highlights.  Sorry to you contributors who might have
thought there was a big black hole out here where RISKS is supposed to be.

By the way, the cutover to the new system and its mailer has improved my life,
and has resulted in only a few dropped subscribers.  Thanks for your patience.

Your underautomated moderator


The Guardian vs computer passwords

<blf@scol.UUCP>
Fri Aug 25 11:15:15 1989
The Guardian newspaper (London, U.K.), Thursday 24th August
(reprinted without permission).  My comments follow.
Any errors in the transcription are entirely mine (but the
Guardian's reputation for poor proofreading is of no help).

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

    A daily changing password is a simple but ridiculously
    under-used anti-hacker device, argues P. Nath

            GIVE US THIS DAY ...

  There is a growing acceptance of the view that little can be done
to deter hackers, since they have successfully penetrated so-called
secure systems including those of the US and Nato commands.

  But computer users could take some measures which are ridiculously
simple and will only need a couple of minutes each week, to stop
more hackers than armies of policeman ever could.  These measures
could be put into operation immediately and do not involve any new
hardware of software.

  All computer systems allow information to be protected with passwords,
but this facility is not properly exploited.  To be effective a password
should be unguessable and temporary, and yet most passwords are based on
names or addresses familiar to the users, and very seldom, if ever changed.
It's like hiding the keys of the house under the doormat in the belief that
no burglar will be clever enough to discover them.

  The fact that hackers arrange meetings where they exchange, sell and
circulate interresting passwords proves that those passwords are not
changed often enough.  If passwords are selected carefully and changed
every two or three days, even the most experienced hackers will find
it impossible to discover them.

  Although every protection system should be different, some general
rules for coining and deploying the passwords can be easily laid down.
Perhaps the users may even learn to derive as much thrill in coining
un-hackable passwords as hackers noe get in breaking them.

  Ideally a password should be based on things which are in no way
related to the user or his organisation, and the word should be new,
pronounceable and easy to remember.

  The easiest method is to start with common names like Mexico, Dublin,
France, Durham, London, Moscow, Cyprus etc, and form new words like
Icomex, Lindub, and Cowmos by interchanging their first and second halves.
A better group of new words can be made by combining halves of different
words; for example Lonlin, Frarus, Mexrus and Mosham.  Such words become
very easy to remember if a large item is paired with a smaller one, and
the two are linked in some way.

  A better idea is to use two passwords.  Easily remember pairs of words
may be made up by linking an item with one of its features.  For example,
the onion domes of Moscow being to mind words like Onimos and Onicow.
A pair of words like this can be used interchangeably as passwords,
by an individual or a group.

  Other members of the group will not be inconvenienced, since even
the strictest computer system allows two or three attempts to key-in
the password correctly.  By just typing Onicow as a guess, a user will
happen to be right about half the time.  If the computer rejects this
word, he is sure to gain access by typing Onimos.  This tolerant nature
of computers is well exploited by hackers, and there is no reason why
users should not take advantage of it as well.  Computer users suffer
from an irrational fear of forgetting their passwords, so they adopt
unforgettable names like those of their wives or children, and sometimes
their own names.  The idea of a password which changes frequently,
say once or twice a week, seems like mental torture, but it is not.
The underlying rules for such passwords are so simple the once learnt
they become very easy to recall.

  Consider a hypothetical international company and imagine that all its
salesmen are enjoying a new year party.  All the data concerning products
and prices are kepy only in the central computer, the password for which
is to be changed every day.  The salesmen do not wish to spend more than
five minutes to learn the password rules and they insist that no written
record of the rules should exist, and that no member should ask or divulge
the rules to another member or anyone else.  Is it possible for them to
invent a totally reliable but unwritten set of rules which will churn
out a new password every day?

  Yes, and the procedure is quite simple and easy to remember.

  To be chanageable daily the password must be linked in some way to the
calendar, but the information has to be coded in such a way that hackers
will not be able to crack it in 24 hours.  As a starting point take an
uncommon three-letter base word, for example, ULM.  This leaves room for
three letters or digits to codify the date, for example, Sunday, April 30.
This day is in the 17th week of the year, is the 120th day of the year,
and is 245 days from the end of the year.  The password can be any of
the following:
    ULM30S (30th, Sunday)
    ULM30A (30th, April)
    ULM304 (30th, April)
    ULM430 (April, 30th)
    ULM17S (17th week, April)
    ULM301 (30th, Sunday) (1=Sun, 2=Mon, 3=Tue etc)
    ULM125 (difference between 245 and 120)
and so on.

  These passwords may be modified by taking the code letters for days
and months from another language (for example, German) or by adding a
fixed number to the digits relating to dates and months; or by multiplying
these digits by a 2 or 3; or by writing them differently, for example in
an octal base.

  Other combinations can be obtained by putting the calendar information
inside the word.  ULM30S can be written as UL30SM or U30LMS or U30LSM.
Reversing this order provides another set of words.

  The attraction of such a system is that although the users have to agree
on only one of these simple rules and remember it for a year (assuming the
system is renewed annually), the hacker will need, if he is very lucky,
hundreds of trials to find out how the daily information has been encoded
and 24 hours will not be long enough to do this.

  If by some miracle a hacker breaks the daily code, he still has to
discover the fixed letters U L M in their correct order, and this task
will need thousands of additional trials.  By that time he may decide
to give up hacking as a bad job.

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

Whilst this column gives some good advise (e.g., "a password should be
unguessable and temporary"), reasonable suggestions for chosing decent
passwords (e.g., invention of "Onicow"), and implies other sensible
precautions (e.g., no written records or disclosure), it is flawed.

Ignoring the factual errors (passwords exist only on MS-DOS via add-on
products; ergo, new software and/or hardware may be required), it omits
several key points.  The most obvious omission, perhaps, is that with
the ULM scheme the rules must be changed everytime a salesman leaves
the company.  (If the information is so valuable to require daily passwords,
then it would be unacceptable for any former employee to still efectively
know the password.)  For the type of company described, this could be rather
frequent, presenting the problem of how to distribute the new scheme
(which is, quite sensibly, neither written down nor ever divulged).

The column also supposes that unauthorised agents (called "hackers",
but I refrain from that debate) gain access only by guessing passwords.
I suspect that such (random) guessing is the among the rarest attacks.
(But the problems with short passwords and restricted alphabets are
hinted at.)

Assuming that the passwords control the ability to log onto the system
(i.e., authenticate system access) then the implication that passwords
should be shared (amongst all the salespeople, in the ULM example) is a
disaster.  Shared passwords imply shared accounts, which frustrates any
concept of accountability — since no one is individually responsible
(for a shared account), a breach cannot be traced back (assuming some
auditing facilities exist) to an individual person actions or inactions.

It is good to see passwords discussed in the mainstream press, and even
better when the discussion includes sound instruction.  But it unfortunate
that the discussion is so flawed that the good points are overlooked.

Brian Foster, SCO Trusted UNIX Project, The Santa Cruz Operation, Ltd., London

   [We have also mentioned in past isseus the risks that the passwords may
   be stored unencrypted in accessible places, may be transmitted unencrypted
   via easily readable transmission media, and that passwords are intrinsically
   vulnerable.  But you should not be surprised to see a technical topic mauled
   in the press...  PGN]

Please report problems with the web pages to the maintainer

x
Top