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 6 Issue 15

Tuesday, 26 January 1988


o RISKS in Cable TV?
o Re: U.S. Fears Satellites Damaged
Henry Spencer
o My country's misguided technology transfer policy
Geoff Goodfellow
o Calendar bomb in the Ada language
Douglas Jones
o Re: PCs die of New Year Cerebration
Larry Rosenstein
o GAO report on the Oct 19th crash...
Barry Shein
o Re: null loops
Mike Linnig
o Bloody SSNs again
Hank Roberts
o Re: Non-ionizing radiation
Henry Spencer
o Info on RISKS (comp.risks)

RISKS in Cable TV?

26 Jan 88 11:09:02 GMT
On Sunday evening, Jan. 25, something very unusual happened at my house.
My wife and I often watch the CNN (Turner's Cable News Network) World News
Report.  This is a weekly compendium of stories from various local news
agencies around the world.  On this occasion we noted with interest a report
from the USSR.  It started off with some "noncontroversial" coverage, but
then things got exciting!

First, the Soviet-based agency began covering a story on the approx.  500,000
Soviet children who are now separated from their parents.  ("Hooray for
glasnost," I thought.  "Maybe they'll correct this now that they've admitted
it.")  Then, a few minutes into the story, wham!  There was a loud click at
the cable remote box, which turned itself OFF!  Not only that, a fluorescent
light on the same circuit ALSO went off.  The effect was very dramatic.  My
wife and I both looked at each other.  After just a few seconds fumbling with
the remote control, we discovered that a different story was being broadcast.

I wondered if we were the only ones to experince this, and sure enough,
when I tried to call the off-hours repair number, the line was busy.  About
5 minutes later, the box turned itself off again.  By then we were suspicious.
The cable company's service has been extremely reliable, and the box has never
winked off for no reason before.  I still don't know if the entire net or just
the boxes tuned to CNN.  My questions to RISKS are:

1) Could someone with specs to a standard cable remote box commandeer the
   satellite uplink and broadcast a "remove from service" signal to boxes
   tuned to a certain channel?  Or, if that wouldn't work, could someone 
   induce a power surge and trip circuit-breakers in the boxes themselves?

2) What exactly is in these boxes.  Could a cable company monitor which
   channel you're tuned to?  Can they eavesdrop on your house?

3) What other means might be possible to force a remote box to disconnect,
   and which methods might account for the failure of the fluorescent light?

Re: U.S. Fears Satellites Damaged

Mon, 25 Jan 88 23:07:42 EST
> ..."There is no way you can protect the optical sensors on satellites" from
> laser attacks, an Air Force official said. ...

Hmm, I can think of ways of doing it, and evidently so can the USAF:  the new
generation of early-warning satellites are claimed to have sensors that are
protected against laser damage.  Not the same satellites, admittedly (the
news story is clearly talking about the low-altitude spy satellites rather
than the high-altitude warning satellites), but I would suspect that the
technical people are not quite as helpless as the quote would indicate.
Certainly they have been aware of this potential problem for quite a while;
it is NOT new.

In fact... I seriously wonder whether the USAF's evidence is as good as the
story would suggest.  My recollection is that several of the recent major
arms treaties (not just the semi-defunct SALT II) explicitly specify that
no attempt will be made to interfere with "national technical means of
verification", which is treatyspeak for spy satellites.  Given the Reagan
administration's tendency to claim treaty violations at the slightest excuse,
one is compelled to wonder just how real and solid this problem is — I don't
recall hearing of any treaty-violation complaints along these lines.

> [However, the risks of laser interference or accidental triggering are worth
> noting.  Adding to the risks of computing in SDI, might such a concerted
> attack of simultaneous laser bursts on many satellite sensors be mistakenly
> detected as the launch of a nuclear attack!?  PGN]

I'd be surprised if the sensors and the (computerized or human) interpreters
behind them were that stupid, especially when the problem is well-known.

Consider, too, that such a concerted attack on satellite sensors is precisely
analogous to, say, saboteurs simultaneously blowing up all the BMEWS missile-
warning radars:  it is itself an act of war, and an extremely ominous one,
pointless except as a prelude to a nuclear attack.  It in fact IS a strong
warning of imminent attack, although not quite an actual launch warning.

                Henry Spencer @ U of Toronto Zoology

My country's misguided technology transfer policy

the terminal of Geoff Goodfellow <>
26 Jan 1988 17:02-PST
Paul Smee elucidates some of the questionable sensibilities of the US's
technology policy with respect to country blackballing.  I agree with all
points and would like to add how truly senseless this seemly misguided
policy is in today's (and tomorrow's) direction of technology development:
ubiquity, omnipresence, miniaturization.

PC's and friends used to be deskside/top fixtures.  Today, manufacturers the
likes of GRiD offer full blown 386 portables with 40MB disk and 8MB RAM,
etc., laptops that easily fit in half a brief case (and i suppose fairly
well in diplomatic pouches).  Not everyone's briefcase/bags are examined by
customs.  But to carry the picture into tomorrow when we'll have Dynabooks,
Dynacards (smart cards) and Dynawatches, will we be removing our wallets and
watches at custom's?  How long will it be before the standard functionality
of a smart credit-card-size computer or watch surpasses (or at least roughly
equals) the capabilities of today's desk/laptop's?

Halting technology transfer given the current trends to this US Citizen
and Resident of The North American Numbering Plan is likened to holding back
the flow of the ocean with an ever increasing number of brooms.

   [I fixed a spelling error and happened to ask Geoff about it.  He said
   his speller had barfed on that word, so — assuming the word was absent
   from the dictionary — he added the (accidentally, identically incorrectly
   spelled) word.  An interesting risk of using spellers.  PGN]

Calendar bomb in the Ada language

Douglas Jones <>
Mon, 25 Jan 88 08:53:41 CST
The recent discussions of leap-year bombs lead to some speculation about
the likelyhood that a multitude of calendar bombs will show up around the
new-years day in the year 2000.  I would like to bring up an even larger
calendar bomb which is designed into the Ada language and will go off new-
years day in the year 2100.  This bomb is implied by the discussion in
section 9.6 of the Ada Reference Manual, MIL-STD-1815 (10 Dec 1980).  I don't
think it has been changed in any more recent revisions of the standard.

The type TIME is defined as a record of YEAR, MONTH, DAY, and SECOND, with
YEAR being an integer subrange from 1901 to 2099.  I would expect that an
implementation of Ada that fully conforms to the language specification
would be required to raise a CONSTRAINT_ERROR exception whenever an attempt
was made to compute a TIME value in a year after 2099.

In many real-time process control applications, the software must periodically
poll the state of the process under control.  The standard way of writing
such a polling loop is given in the example at the end of section 9.6 of the
manual, and it involves performing arithmetic on the current time-of-day,
represented as a variable of type TIME.  Thus, real-time process control
software written in Ada as it is defined today is required by the definition
of the language to stop functioning on new-years day, 2100.

I am unlikely to be around in 2100, but how likely is it that some Ada
applications will survive, burned into ROM, controlling what will, by then,
be outdated industrial process control equipment or old military hardware
(probably long-since sold as surplus to some fourth-rate army).  Furthermore,
I can imagine that, by 2100, huge piles of musty ADA code will keep the
books for many companies and nations, in just the way that reams of out-dated
COBOL code run many companies today.  The potential financial consequences of
a calendar bomb in this context are mind boggling.

I want to emphasize that this bomb is built into the language specification.
The language designers gave the implementors no latitude to perform time
arithmetic on some convenient representation and then make an expensive
conversion to YEAR, MONTH, DAY and SECOND.  Thus, common (and forgiving)
internal representations, such as milliseconds Anno Babbage, are explicitly
                   Douglas W. Jones

Re: PCs die of New Year Cerebration (RISKS-6.7)

Larry Rosenstein <>
Mon, 18 Jan 88 15:33:53 pst
I was helping teach a Pascal class during one of MIT's January sessions.  We
were getting ready for the class and discovered that some of the Pascal
compiler were broken — they wouldn't compile correct programs.  The problem
was very strange because some machines would work but others wouldn't and
the problem would be intermittent.

It turns out that the compiler had some kind of date checking in it (perhaps
for licensing reasons), and that sometimes when booting a machine people
would type in the previous year (a common mistake).  This would make the
system date "too early" and the compiler wouldn't work.

           [This is a common phenomenon, and has been mentioned here 
           occasionally.  SCRIBE was the case previously mentioned.  PGN]

GAO report on the Oct 19th crash...

Barry Shein <>
Tue, 26 Jan 88 11:34:06 EST
From an FNN item on the Ed Markey House report this AM:

Of the 12 computers used at the NYSE to transact trades 9 went down on
October 19th. They considered this to be a major contributor to the
chaos. There was no indication in the item (I haven't seen the report)
as to whether this was hardware or software tho they indicated the
crashes were caused by the "sheer volume" of the trades being
executed, not much of a clue really.

    -Barry Shein, Boston University

Re: null loops

Mike Linnig <>
Tue, 26 Jan 88 01:49 CDT
On a recent project that had two processors sharing memory, we discovered
(much to our regret) that a portion of the runtime (operating system)
executed a very tight loop during periods of no work to be done.

Unfortunately, the null loop, consisting of a branch to itself consumed
about 99.95 % of the available instruction bus bandwidth (a branch had no
internal operations to speak of) effectively locking out the other processor
on the bus.  Too bad, the other processor was to have interrupted the "idle"
processor when it completed its work.

We solved the problem by changing the null loop to do some floating point
operations inside the loop.  We didn't need the floating point calculations,
but we sure needed that bus bandwidth.

Mike Linnig, Texas Instruments

Bloody SSNs again (RISKS-6.13)

Hank Roberts as MoFo fw <well!>
26 Jan 88 04:20:50 GMT
I went in today to give blood for the replacement account of a friend who is
dying of lymphoma.  The blood bank has revised their form.  They had to have
my Social Security Number before they would accept my blood.


Re: Non-ionizing radiation

Mon, 25 Jan 88 23:08:34 EST
Unfortunately the QST article does not resolve the issue as completely as one
would like.  It reports on a Motorola investigation that made the usual
assumption that thermal effects are the only significant mechanism for harm
from non-ionizing radiation.  The trouble is that this is only an assumption,
although a widespread and fairly credible one; much of the fuss over long-term
biological effects centers on the possibility of non-thermal mechanisms.

Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Please report problems with the web pages to the maintainer