Text File

Subject: RISKS DIGEST 13.24 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Wednesday 4 March 1992 Volume 13 : Issue 24

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

Contents: Orange County Must Delay Stormwater Tax (Tanner Andrews) Major software problems at TSE (Mark [with note from Bjorn Freeman-Benson]) Garbage In, Gospel Out -- genetic info (Vivek Khera) 1-900 spelling game (Andrew Tannenbaum) AT&T's operatorless collect calls (PGN) Private SS Data Sold to Information Brokers (Chuck Lins) RISKS of international trade negotiations: intellectual property, patents (Jyrki Kuoppala) A320 and significance (Henry Spencer) MAGSAV bug explained (Paul Eggert) Re: Leap year strikes again (Rhys Weatherley) Re: RSAREF license (David L. Black) Re: Viruses (Bob Frankston) Re: Virus news-bite omits crucial information (John Cav..., A. Padgett Peterson, Steve Milunovic)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP domain folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

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

Date: Tue, 3 Mar 92 7:26:02 EST From: Dr. Tanner Andrews <tanner@ki4pv.compu.com> Subject: Orange County Must Delay Stormwater Tax

The _Orlando Sentinel_ [remarkably acerbic comments about the paper have been deleted by your immoderator] cost Orange County a year's delay in passing a stormwater tax. They failed to run two of the required advertisements for a public hearing.

Yeah, ``it's the computer's fault.''

...!{bikini.cis.ufl.edu allegra uunet!cdin-1}!ki4pv!tanner

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

Date: Wed, 4 Mar 92 05:24:05 EST From: mark@orca.cita.utoronto.ca Subject: Major software problems at TSE

TSE computers go berserk, floor closed for four hours Breakdown bolsters opposition to computerized trading BY CAROLYN LEITCH, Toronto Globe and Mail, 4 March 1992, business section, lead item

A software glitch caused computers at the Toronto Stock Exchange to go berserk yesterday, scrambling information, recording wildly inaccurate prices and failing to print tickets to confirm trades. Floor traders quickly used the breakdown to bolster their opposition to the TSE's planned move next year to an entirely computerized trading floor. The malfunction also illustrated the problems many organizations encounter when they try to change the software code that instructs computers.

TSE officials closed down floor trading for nearly four hours between 10 a.m and 2 p.m. after irregularities were detected in the computer system that traders use to buy and sell equities. Carl Christie, a senior professional trader with Nesbitt Thomson Deacon Inc. and chairman of the Professional Traders Association, said he noticed dramatic problems shortly after the market opened at 9:30 a.m. An order to buy 20,000 shares in Teck Corp. at $17.37 a share appeared on the computer as a bid for 3,339 shares at $279.50 a share, he said. As well, some sellers were unaware their sell offers had been accepted because the system was not printing confirmation tickets.

The TSE said it didn't know if it would have to unwind any of the trades. The exchange said disputes over orders that went awry will be decided on a case-by-case basis by floor governors. Mr. Christie said that as as specialized trader with certain stocks, he had no flow of orders coming in during yesterday's shutdown. As many as 150 other traders were also affected, he added. "I know that it cost me money -- we lost two-thirds of our working day."

The TSE has voted to replace floor trading with a fully computerized system early in 1993. That decision is unpopular with floor traders who fear for their jobs.

The bugs appeared after the TSE changed its computer software over the weekend to deal with new trading rules. Olaf Kraulis, vice-president of information systems at the TSE, said the system was restored to its pre-weekend state after flour hours of grappling with the problem. He said the software changes will be reinstated in one or two weeks after programmers figure out why they fouled up the computer system.

But Don Unruh, a former TSE vice-president who helped develop the system eight years ago, said the problems run deeper than yesterday's malfunction. A patchwork of different software and hardware has emerged over the years, he said. "The people who are making the changes eight years later have no idea what was done by the people who went before them. You end up with these bizarre logic problems." Mr. Unruh, now a consultant who recently wrote a report on the TSE's computers for the Professional Traders Association, said the whole system should be scrapped and a new one developed.

But Mr. Kraulis said thousands of changes are made to software every year with few problems. While the 12 Tandem Computer processors that power the system have backup provisions in case of a hardware failure, there is no such contingency for software problems. "If a copy of the software is wrong, every copy will be wrong," he said.

Leonard Petrillo, the TSE's vice-president of corporate affairs, said the impact on members was minimal. "Most of the stocks are inter-listed," Mr. Petrillo said, "and traders were able to instantaneously reroute orders to other exchanges," such as the Montreal Exchange and the New York Stock Exchange. [...]

[Also submitted by bnfb@csr.UVic.CA (Bjorn Freeman-Benson), who added this:]

[The RISKS? Besides the obvious ones, the interlisting could motivate traders to avoid an unreliable Toronto in favor of Montreal, which is a risk to the computer owners rather than the computer users... Bjorn]

[How about the risk of sabotage by dissident floor traders? PGN]

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

Date: Wed, 04 Mar 92 13:39:16 EST From: Vivek Khera <khera@cs.duke.edu> Subject: Garbage In, Gospel Out -- genetic info

Summarized from the March 2, 1992, Newsweek, page 58: "Eve Takes Another Fall"

In 1987, a group at UC Berkeley used a computer to analyze mitochondrial DNA from 147 people and proclaimed that all humankind descended from one woman who lived in Africa 200,000 years ago. Last year the team ran a more rigorous analysis using 189 samples and again concluded the same thing.

The program tries to find the family tree that is most "parsimonious"; that is, a tree based on the fewest genetic mutations. The trouble is that there are multiple equally parsimonious trees, and no algorithm to guarantee the computer has found the best one. The resulting tree depends on the order of the data input. The Berkeley group assumed the order of data was irrelevant. "They weren't using the program in an adequate way," says Alan Templeton of Washington University.

One explanation of why it took so long to discover this error: ``...[they] didn't have the mathematical savvy to understand the statistical traps in the computer.'' v.

[... cloning primordial parsnips in a pearsimonious tree? PGN]

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

Date: Wed, 4 Mar 92 14:38:50 -0500 From: trb@ima.isc.com (Andrew Tannenbaum) Subject: 1-900 spelling game

There is an ad on TV for a 1-900 telephone service spelling game - if you can spell twenty words correctly in two minutes, you win $200. I guess you hear the words and type them in on your touchtone pad. Assuming that the game isn't rigged to make it impossible to win, it would be pretty easy to devise a hack to allow you to type words on your PC, check their spellings, and send out the correct touch-tone signals on the fly.

The parts for this hack are readily available. There are good spell checkers and big dictionaries (word lists). Modems these days have dialers that generate touch-tone, it ought to be possible to program them to talk to the spelling game (sending tones at the proper speed and spacing). I imagine that this computer-aided approach would improve your odds to a significant extent.

Andrew Tannenbaum Interactive Cambridge, MA +1 617 661 7474

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

Date: Wed, 4 Mar 92 18:33:33 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: AT&T's operatorless collect calls

Andrew's message reminds me of this morning's news item that AT&T will need far fewer operators because it is automating voice processing to eliminate some operator assistance. (The scheme is already being tested in various areas.) The collect call initiation permits the caller to pack an arbitrary short message into the time slot for the caller's presumed name. I imagine that will open up all sorts of new games that are currently prevented by operator assistance. On the other hand, it has always been possible to do that now with a little prearranged coding. With the new scheme, you would not even have to resort to Tuesday Weld to anticipate arrival in Maine, Gal Friday to indicate Galveston, etc.) It would seem to be much more flagrant with the new scheme. So, maybe they will try to filter out strange sequences. Blocking short bursts of 2.4Kb data transmissions might be possible, for example! But it would be terrible to restrict it to small dictionaries like telephone book names suitably pronounced without too much of an accent. This sounds like a freebie fraught with fraud, I'm afraid.

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

Date: 4 Mar 92 08:12:32 U From: "Chuck Lins" <chuck_lins2@gateway.qm.apple.com> Subject: Private SS Data Sold to Information Brokers

Private SS Data Sold to Information Brokers San Jose Mercury News, Saturday February 29, 1992.

Private Social Security data sold to 'information brokers' By R.A. Zaldivar, Mercury News Washington Bureau

Washington - The privacy of 200 million Americans with records at the Social Security Administration is threatened by an illegal trade in pilfered computer files. Computerization has dramatically improved our ability to serve the public," Social Security Deputy Commissioner Louis Enoff told a Senate panel Friday. "However, it has also made confidentiality more difficult."

Two executives of Nationwide Electronic Tracking, a Tampa, Fla., company, pleaded guilty to conspiracy charges in January for their part in a national network selling Social Security records. Twenty-three people, including agency employees and police officials, have been indicted in the case - the largest known theft of government computer data. "Information brokers" will pay Social Security employees $25 for a person's earnings history and then sell the data for as much as $300. Their growing list of customers includes lawyers, private investigators, employers, and insurance companies.

Social Security records contain a mother lode of information that includes not only a person's past earnings but names of employers, family history and even bank account numbers of people who receive benefits by direct deposit. The information can be used to find people or to make decisions on hiring, firing, suing or lending, said Larry Morey, deputy inspector general of the Health and Human Services Department.

"Here we have a large-scale invasion of the Social Security system's confidentiality," said Sen. Daniel P. Moynihan, D-N.Y., chairman of the Social Security subcommittee.

Information from other government data bases with records on individuals - such as the FBI's National Criminal Information Center - is also available on the underground market. All a broker needs is the cooperation of a clerk at a computer terminal.

Congress may revise privacy laws to increase penalties for illegally disclosing information in the private files of individuals.

Enoff said Social Security is studying ways to improve computer security, as well as keeping closer tabs on employees with access to files, and stressing to its workers that unauthorized disclosure of information is a federal crime.

Perhaps if release of information was keyed to a digital signature of the [clerk, this could be used to identify those persons (at SSA) selling the information. No mention is made of the buyers of the information from the broker. I guess they just get to keep the illegally obtained information.

Now I wonder what happens when this happens in California at the DMV, and a copy of my digitized signature is sold? Chuck Lins lins@apple.com]

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

Date: Wed, 4 Mar 1992 17:59:38 +0200 From: Jyrki Kuoppala <jkp@cs.hut.fi> Subject: RISKS of international trade negotiations: intellectual property,patents

There has been an attempt in the UN organisation World Intellectual Property Organization, WIPO, to harmonize world's patent laws. It seems to be that USA is just about the only country who is pressing for "patents on all fields of technology" while many countries oppose things like patents on software and biotechnology. The developing countries say that many patents are one of the Western worlds' ways of keeping ahead in the game and keeping the developing countries behind.

In UN, it's one vote per country so USA has not been very successful. However, USA seems to have more success via GATT, as Kurt Jaeger writes on misc.int-property:

"Look e.g. on rusmv1.rus.uni-stuttgart.de [129.69.1.12] in directory info/comp.patents/lpf-de/docs/GATT-draft.txt.Z, its a copy of the TRIPS stuff in the GATT treaty (TRIPS == trade <something> intellectual property <something else>).

TRIPS, the part of GATT dealing with software patents etc IS NOT under discussion any more in the GATT, as I've been told by the german official who's heading the german part of the EC delegation of GATT. If the agricultural problems are solved, we'll HAVE software patents all over Europe. And biotech patents as well, btw. 8("

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

Date: Wed, 4 Mar 92 18:33:23 EST From: henry@zoo.toronto.edu Subject: A320 and significance (Ilieve, RISKS-13.21)

>Unless you assume that the pilots flying A320s are more stupid than >average, then if pilots have more crashes in A320s than other planes, >even if the cause is officially `pilot error', there must be something >about the plane that makes errors more likely.

My statistics friends would laugh at this, or sigh and shake their heads. The proper version is "...if pilots have *significantly* more crashes...".

One must remember that COINCIDENCES DO HAPPEN. Remember the time some years ago when it seemed that whenever you turned on the radio, there was another report of a DC-10 crash? Haven't heard many lately, have you? What changed? Basically, nothing. Oh, some minor changes were made in the aircraft and its operating procedures, but that spate of crashes was mostly sheer bad luck. Modern airliners very seldom crash; the DC-10 just had a couple of bad years, with mechanical flaws, bad maintenance, navigation problems, and (yes) pilot error all striking down the same type of aircraft at around the same time.

It's still actually open to doubt whether the DC-10 is significantly less safe than its competitors. The numbers do suggest so, but they are based on so few incidents -- compared to the enormous number of successful and uneventful flights -- that it is entirely possible that the DC-10 has simply had bad luck. In military flying, with much higher accident rates, it is not at all uncommon for the investigation of a series of accidents to find that the failures were unrelated and the timing just coincidence.

On the whole, I think there is some reason to suspect that the A320 has human-interface problems. But that conclusion is based on the *details* of the cases so far, not on just counting them. It will be quite a while before we have enough data on A320 crash rates to start to draw any valid numeric conclusions about whether it really crashes unusually often.

Henry Spencer at U of Toronto Zoology utzoo!henry

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

Date: Tue, 3 Mar 92 18:27:55 PST From: eggert@twinsun.com (Paul Eggert) Subject: MAGSAV bug explained

G M Lack reports in comp.sys.prime <9203021236.AA01979@uk0x06.ggr.gri.com> that MAGSAV probably failed on 29 Feb 1992 because it tried to increment the year by one to set a tape label expiration date, and the resulting nonexistent date 29 Feb 1993 threw it for a loop. Alas, dates are tricky, and that goes double for date arithmetic.

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

Date: 4 Mar 92 03:23:50 GMT From: rhys@cs.uq.oz.au (Rhys Weatherley) Subject: Re: Leap year strikes again

I too experienced strange behaviour with Feb 29 dates. A Windows 3.0 newsreader I have been prototyping using Borland C++ 2.0 has been happily chugging along for a number of weeks without hassle. Then (of course) it locked up for no apparent reason.

Tracing the program revealed that during the parsing of "Date:" headers, when it called the "mktime" function to convert the dates to the Unix date/time format, it locked up. I haven't delved deeply into disassembling the code for "mktime", so I don't know the exact cause of the problem, but the call was very quickly replaced with an alternative version of "mktime". :-)

So, some of these problems; at least on PC architectures; may be attributable to bugs in the run-time libraries of Borland C++ and possibly Turbo C++ also, rather than to the authors of packages that use the run-time libraries.

Rhys Weatherley, The University of Queensland, Australia rhys@cs.uq.oz.au

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

Date: Wed, 4 Mar 92 14:36:09 GMT-0400 From: dlb@osf.org Subject: Re: RSAREF license

Shortly after this electronic license agreement showed up inside OSF, we received a missive from our attorney asking in no uncertain terms that we not execute the license (and revoke it and dispose of the software if we had). The major problem revolves around the fact that the technology is export controlled. The original posting stated:

> 4. You can't send RSAREF outside the United States, or give it > to anyone who is not a United States citizen and doesn't > have a "green card." (These are U.S. State and Commerce > Department requirements, because RSA and DES are > export-controlled technologies.)

The problem is that the intuitive meaning of this paragraph is misleading. The intuitive meaning is that you must not intentionally do something that explicitly transfers the software to someone who should not have it (for brevity, call this individual a `restricted person'). Unfortunately, the actual restriction includes unintentional acts, and acts of omission (didn't do something you should have). An example could be include putting the source files on a system to which a restricted person has access (unbeknownst to you).

If something goes wrong, the government may come after both you and your employer (by holding your employer responsible for your actions). At the very least, anyone contemplating putting this software on one of their employer's systems should run the license past the appropriate lawyer. There are other more mundane reasons for a lawyer to say no, such as needing to formally verify that RSA really is who they say they are.

The RISK here is that the quasi-public distribution mechanism being set up by RSA may well be inappropriate for export controlled software. This is not like the copyright laws; people go to jail for violating export control laws.

Disclaimer I: This post is a statement about the export control laws; it has nothing to do with my views about how distribution of this software should (or should not be) controlled. If you've ever wondered about the restrictions that export control laws place on information interchange and technology transfer, you now have a concrete example.

Disclaimer II: Nothing in this post should be relied on as legal advice. If you think you might have a problem, go find a real lawyer.

--David L. Black (dlb@osf.org)

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

Date: Tue 3 Mar 1992 21:34 -0500 From: <Bob_Frankston@frankston.std.com> Subject: ... viruses

It is not public, but at least one large software company does put in some integrity checks in its software. While this isn't Virus protection, it is a step in the right direction.

I wonder if a more technical term like "Transportable Boot Sector Modification Programs" would engender the same amount of popular press. Question: How many people are going to start wearing gloves when they use their computers?

It is also interesting that an MSDOS Virus is getting this attention. Macs are actually more vulnerable since the passive insertion of a disk will cause the execution of a procedure whereas you must execute off the disk in order to run program on it. I presume that the larger number of PC users and, perhaps, more of a history of exchanging programs contributes to the spread.

The infection is actually worse in object-oriented systems since objects are active elements (i.e., they come with methods and behaviors. One can argue that any object IS a kind of Virus that comes with its executable code and relies on the local environment to give it life. Dealing with issues like this is what delays seemingly good ideas. In fact, over 25 years ago, there was to be T access in Multics. T stood for "Trap". When you attempted to access a segment with Trap access, a trap routine, provided by the segments owner would be run. Of course, it would have to be run in the owner's access domain with the user protected from bad behavior though the trap procedure would also be executing in some form of the user's environment. No surprise that T access didn't make into the (relatively) secure production system. But the thinking raise issues of mutually suspicious subsystems generating various theses. One indirect result is the ring architecture of the 386. The moderator and other readers can contribute many more details to this history.

By being naive, the Mac was able to implement a very user-friendly feature. A smart disk allows one to insert a disk and let it install itself. Only etiquette demands that it should ask permission before starting. The Mac also naively implemented bitmap fonts on a fixed size screen. Scaleable fonts weren't even imagined by most users.

So which is right -- the Multics approach of implementing a feature after it is somewhat understood or the Mac approach of doing what makes things easy for the user and then fixing it up later. Novell implemented a remote file system by patching into DOS in a way that 3com didn't. As a result, people bought Novell's product and Microsoft has to accommodate them. Cellular phones with their lack of security are another example. Conversely, all electronic devices brought onto airplanes are, for some reason, suspect. Apparently turning them on at a security point exorcises the daemons...

In the case of viruses, we might achieve a balance of terror by hanging a few creators (chosen by lottery) by their typing fingers and hoping the problem abates. Some firewalls will be added to software. The alternative of creating truly secure software is possible -- just prevent naive users from getting near computers.

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

Date: Wed, 04 Mar 92 11:45:17 -0600 From: jcav@midway.uchicago.edu Subject: Re: Virus news-bite omits crucial information

>> AT NO TIME DURING THE PIECE DID ANYONE MENTION THAT THE VIRUS >> AFFECTS MS-DOS CLONE MACHINES ONLY.

I wish to apologize for the extremely poor wording of my original article. The point I was trying to make was that the Michaelangelo virus does NOT attack Macintoshes, Amigas, SUN workstations, UNISYS mainframes, etc. etc., but the radio program made no mention of any such distinctions.

I used the phrase "MS-DOS clone machines" to mean IBM PC-compatible computers. I should have said that instead. Oh well.

JohnC

[There was a slew of messages on this subject, including those from Bennet_Yee@PLAY.TRUST.CS.CMU.EDU, padgett@tccslr.dnet.mmc.com (A. Padgett Peterson), jct%se33@seg01.wg2.waii.com (Jim Thompson), tneff@bfmny0.bfm.com (Tom Neff), dholland@husc.harvard.edu (David Holland), and rslade@sfu.ca (Robert Slade). I could not include them all, but there was lots of overlap. However, I pseudorandomly picked Padgett's, which follows. Read no further if you have had enough. And then wait for Friday. Thanks to all of you for rising to the occasion. PGN]

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

Date: Wed, 4 Mar 92 09:00:54 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Michelangelo & Unix Boxes

>That's a pretty amazing feat, since to do this, ...

Unfortunately, it is no problem at all since Michelangelo is a BIOS virus (no it doesn't infect the BIOS, it uses it) and this is present and essentially standardized (what makes a PC "100%" compatable) in every Intel box that is able to boot DOS.

The virus uses Intel iapx80x86 assembly language but only uses BIOS interrupts not MS-DOS interrupts (my FixMBR does also which is why it can repair "invalid" disks but needs DOS to load the program).

The important fact is that when a PC frst loads absolute sector 1 from a disk, it is already, courtesy of the BIOS, a fully functioning computer with the ability to address all of its peripherals. It is just not yet a MS-DOS (or PC-DOS, or OS/2, or Unix, or...) computer yet. The original Flight Simulator and many DOS 1.0 programs (the ones you had to boot from the floppy but were unreadable by DOS) were examples of BIOS-only programs.

Unfortunately, except for a few of us -and many virus-writers 8*( -this seems to be a "lost art".

The problem that Michelangelo has stems from things it expects that are characteristics of DOS and are not necessarily true:

1) That absolute sector 7 on the fixed disk is unused 2) That memory marked in software as "unavailable" by the BIOS will not be used

Neither assumption is necessarily true under Unix though it is usually (1) that causes Mich (or Stoned or ...) to fail on a Unix platform by making it unbootable.

BTW IMHO any damage that results from Michelangelo may be laid directly at the feet of the OS vendors for Intel based platforms (and this includes UNIX as well as DOS) who do nothing about "rogue programs" at the BIOS level (over 50% of all reported infections last year)

Ten bytes in IO.SYS (or the boot record, or the MBR like my stuff) are all that is necessary to find every MBR infector that I have come across including Brain, Yale, Aircop, Stoned, Evil Empire, Bloody, and many others including the Michelangelo.

The question is: if we do not take steps now to eliminate these viruses, what are we ever going to do about the really nasty and professional (the Michelangelo is very buggy & "crude") viruses that I know could be written ?

Padgett

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

Date: Wed, 4 Mar 92 9:55:36 PST From: "Steve Milunovic" <steve_milunovic@qm.sri.com> Subject: Michelangelo

I wish there was some way to stop the media from spreading such bad advice as resetting the clock to circumvent the Michelangelo and other date virus strains. Don't they know the virus is still there and can become more widespread if it isn't removed? =Steve=

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

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