Text File

RISKS-LIST: RISKS-FORUM Digest Tuesday, 26 January 1988 Volume 6 : Issue 15

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

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

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. > > > > > > > > > PLEASE LIST SUBJECT in SUBJECT: LINE. < < < < < < < < < For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).

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

From: [...] Subject: RISKS in Cable TV? Date: 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?

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

Date: Mon, 25 Jan 88 23:07:42 EST From: mnetor!utzoo!henry@uunet.UU.NET Subject: Re: U.S. Fears Satellites Damaged

> ..."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 {allegra,ihnp4,decvax,pyramid}!utzoo!henry

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

Date: 26 Jan 1988 17:02-PST Subject: My country's misguided technology transfer policy From: the terminal of Geoff Goodfellow <Geoff@csl.sri.com>

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]

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

Date: Mon, 25 Jan 88 08:53:41 CST From: Douglas Jones <jones%cs.uiowa.edu@RELAY.CS.NET> Subject: Calendar bomb in the Ada language

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 forbidden. Douglas W. Jones

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

Date: Mon, 18 Jan 88 15:33:53 pst From: Larry Rosenstein <lsr%apple.apple.com@RELAY.CS.NET> Subject: Re: PCs die of New Year Cerebration (RISKS-6.7) Organization: Advanced Technology Group, Apple Computer

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. Larry

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

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

Date: Tue, 26 Jan 88 11:34:06 EST From: bzs%bu-cs.bu.edu@bu-it.BU.EDU (Barry Shein) Subject: GAO report on the Oct 19th crash...

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

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

Date: Tue, 26 Jan 88 01:49 CDT From: Mike Linnig <LINNIG%eg.ti.com@RELAY.CS.NET> Subject: Re: null loops

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

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

From: well!nightjob@lll-crg.llnl.gov (Hank Roberts as MoFo fw) Subject: Bloody SSNs again (RISKS-6.13) Date: 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.

Sigh.

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

Date: Mon, 25 Jan 88 23:08:34 EST From: mnetor!utzoo!henry@uunet.UU.NET Subject: Re: Non-ionizing radiation

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

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

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