The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 2 Issue 43

Thursday, 17 Apr 1986

Contents

o Re: Review of *Softwar*
Marvin Schaefer
o GREAT BREAKTHROUGHS
Herb Lin
o Star Wars software advance
AP
o Smart bombs in Libya
Washington Post
o Pacific Bell Bills
SF Chronicle
o BU joins the InterNet...
Barry Shein
o Info on RISKS (comp.risks)

Re: Review of *Softwar*

Marvin Schaefer <Schaefer@USC-ISI>
15 Apr 1986 09:37-EST
        I have read <<Softwar<> only in the French version, and it is
interesting to see from Gary Chapman's review that several differences
appear to have been worked into the details of the plot to make it more
suitable for American [re]viewing audiences.
        Of particular note is the agency with which the American hero
is associated -- a Langley, Va. organization called NSA (the National
*Software* Agency) has been chartered with two primary missions:
software debugging and -- software bugging!  With only modest
chauvinism the authors point out that the French-derived programming
language Ada has been chosen as the primary tool for achieving the
software debugging mission since it makes it so much easier to locate
programming errors.  [There are lots of justified paeans to French
superiority in software engineering.]  Interestingly, the book's NSA
does not seem to have any interest in the use of methodological system
development techniques in which the intention is to produce correct
code in the first place.  One is forced to wonder how they intend to
produce correctly working softbombs to start with.  Perhaps the
two directorates do not talk with each other.
        The first softbomb is discovered by the soviet computing
scientist by analysing a trace of program execution.  He correctly
finds that the softbomb code executes less frequently than the other
instruction sequences in the massive meteorological program, and is
thus able to identify its trigger.
        Not so the more elaborate examples of hardware subversion that
follow in the book's development.
        The amount of blind trust that is placed in hardware
correctness over that of the software is a realistic assessment of
the fairly commonly misplaced faith that one sees today.  The
attribution to the 'NSA' of the view that using the new high-tech Ada
will lead to lower costs and higher reliability  (because of cheaper
debugging) is an opinion one frequently hears in government.
        The book, albeit oversimplified, was fun to read.  I found the
social implications of the book to be far more interesting than the
description of sophisticated computer virus attacks that was mentioned
in the Scientific American review a couple of years ago.
                            Marv Schaefer


GREAT BREAKTHROUGHS [Red Herrings swimming upstream?]

Herb Lin <LIN@MC.LCS.MIT.EDU>
Wed, 16 Apr 86 18:07:03 EST
       From Dave Parnas:

       The Fletcher panel...  They even rejected a military-like hierarchical
       command structure for the computers so that there would be no "Achilles
       Heel" in the system.

And then the Eastport panel went ahead to propose just that!!

               Fossedal's reference to "a single error" is part of another red
       herring in which SDIO supporters claim that the critics want perfection.
       The only reference to "error free software" came from SDI supporters,
       none of the critics have assumed that perfection was needed.

The person who said this was Fletcher himself!


Star Wars software advance

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 17 Apr 86 17:36:15-PST
  Defense Secretary Caspar Weinberger disclosed new scientific advances
yesterday that he said provide ``solid reasons'' that a Star Wars
anti-missile defense system can be made to work...
  Scitech [Princeton NJ, not to be confused with Sytek, of Sunnyvale CA]
developed a means for identifying ``rocket plume signatures''...  LTV
[Dallas] then modified that system to create a special computer program, or
algorithym [sic], that can be loaded in the sensors aboard a missile
interceptor.
  The sensors lock on the plume of fire from an enemy rocket, but the new
program makes the necessary corrections to ensure that the intercepting
missile hits the enemy rocket and not the plume.
  This advance is important because it suggests that enemy missiles can be
attacked during their earliest, or boost, stages of flight and are gliding
on a trajectory toward earth...  [Associated Press, 17 April 86]

                                [It all reduces to a SMOP
                                (Small Matter of Programming)!
                                (See the Hacker's Dictionary.)]


Smart bombs in Libya

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 17 Apr 86 17:34:28-PST
The U.S. Military now believes that damage to the French Embassy and a
residential neighborhood in Tripoli during Monday night's raid on Libya was
caused by a Air Force ``smart bomb'' that went astray either because it was
dropped by a damaged F-111 jet or because its guiding laser beam was blocked
by clouds, Defense Department officials said yesterday...

[The] second explanation is also consistent with the likely trajectory of
the bomb, however.  The 2000-pound GBU10 bombs ae designed to home in on a
beam of light which the ``Pave Tack'' system on the plane's underbelly
focuses on the target.  After the bomb was dropped, the F-111 probably
swerved and climbed to evade anti-aircraft fire, while the laser designator
on the undercarriage automatically swiveled to keep the target illuminated.
As the plane moved, however, the laser beam may have been broken by smoke or
clouds that were drifting over Tripoli Monday night, causing the bomb to
fall unguided into the residential neighborhood.  (Washington Post, 17 April
86)


Pacific Bell Bills

Peter G. Neumann <Neumann@SRI-CSL.ARPA>
Thu 17 Apr 86 17:36:47-PST
The San Francisco Chronicle of 3 April 86 had this story that I meant to
include earlier.

  More than a million California telephone customers will be getting an
  unpleasant surprise in their April bills because of an equipment
  malfunction...  Because of the goof, these customers were not billed for
  millions of medium- and long-distance calls since November, said company
  spokesman Roger Orr.  The calls not billed in January and February will show
  up on the April bill, Orr said.  The California Public Utilities Commission
  will not allow the phone company to charge for calls missed by the billing
  equipment in November and December.  Switching machines logged each call but
  did not put some of them on customers' bills...  [No estimate given of how
  much revenue was lost.]


BU joins the InterNet...

Barry Shein <bzs@bu-cs>
Thu, 17 Apr 86 13:27:24 EST
I may as well tell this anecdote before others do...

Boston University this past week submitted their host table for inclusion in
the NIC table. Unfortunately, there were a few entries in the table that
should never had made it. The most interesting was a one character nickname
("A") for host BU-CS (local convenience.)

Apparently a bug in the 4.2bsd program htable program which converts from
standard NIC format to the format UNIX uses proceeded to fill your disk when
it hit this entry. I suspect from the notes that some hosts must pick up the
table automatically in the wee hours and do the conversion with a command
script so they came in the next morning with a disk full of the string
"BUCSA". I was assured by one site that he no longer needs any mnemonics to
remember our name. I have no way of knowing numbers, but apparently some
number of machines went down or were crippled.

In addition, there was an entry for a machine type "3B2", htable broke on
that also although not so dramatically, because the string started with a
digit. It seems the next night or so htables were breaking again because
someone managed to put a lower case letter into the table.  (I have heard
this only second hand.)

I then fixed our host table to avoid the troubles and ran it through htable
myself just to be sure and it promptly deleted the first entry in my table.
Apparently it had to have at least one blank line before the first entry,
again, without warning.

This is after almost three years of the program being in production at
probably thousands of sites. Don't trust any program over 30 (lines of code)?

    -Barry Shein, Boston University

Please report problems with the web pages to the maintainer

Top