Text File

RISKS-LIST: RISKS-FORUM Digest Monday 24 April 1989 Volume 8 : Issue 62

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

Contents: Release SkyDome, Release 0.0 (Mark Brader) Risks of plaintext data (II) (Hugh Miller) Computer orders for phone books (Mark Brader) ATM's used to track accused killer (Al Stangenberger) Computer Voting (Chris Davis) Re: Most Accurate Clock (David Schachter) Writing on write-protected disks (Leigh L. Klotz, Kenneth R. van Wyk, Phil Goetz, Dimitri Vulis, Henry Spencer, Dave Kemp, Rich Sims)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. * RISKS MOVES SOON TO csl.sri.com. FTPable ARCHIVES WILL REMAIN ON KL.sri.com. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j / ftp KL.sri.com / login anonymous (ANY NONNULL PASSWORD) / get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ... Volume summaries in (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99).

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

Date: Thu, 20 Apr 89 21:02:09 EDT From: Mark Brader <msb@sq.sq.com> Subject: Release SkyDome, Release 0.0

Today's Toronto Star also has an article about the SkyDome. That's the city's new stadium, the world's first with a retractable roof using rigid segments. According to the article, when the stadium opens this summer, the roof will operate at 1/3 speed, taking an hour to open. And the reason for this is that the computer programs to work it aren't ready and a "smaller" version will be in use.

Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com

[This of course contradicts the myth that smaller programs run faster. PGN]

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

Date: Fri, 21 Apr 89 09:23:48 EDT From: Hugh Miller <MILLER@vm.epas.utoronto.ca> Subject: Risks of plaintext data (II)

The "information break-ins" story posted two days ago has become front-page news in the *Toronto Star* today ("Who stole files in mystery break-ins?" by Tim Harper, Fr 21 April 89. p. A1). Here is a chronology, extracted from the article:

21 Nov 88 - University of Toronto campus offices of Science for Peace: floppy disk containing membership address list, financial records, correspondence, drafts of communiques, and a work in progress by George Ignatieff, former chancellor of the university and Canadian UN ambassador, on the use of chemical weapons. Nothing else touched.

13 Jan 89 - Ontario Environmental Network, 456 Spadina Ave.: In addition to the backup tapes referred to yesterday, there were about 300 floppies and a few PC's removed as well. Curiously, the most valuable PC in the room was untouched; it, however, had no data on its hard disk. The others, which did, were the ones taken.

17-19 Feb 89 - Canadian Environmental Law Association, 243 Queen St. West: A computer and a small amount of cash was stolen.

6 Mar 89 - Office of Hon. Jim Fulton, MP, Houses of Parliament, Ottawa: File on alleged open-air testing of chemical weapons at CFB Suffield in Alberta was rifled, contents possibly photocopied (Fulton keeps a high-speed photocopier in his office). Fulton says on 3 previous occasions he had noticed "evidence of break-ins," but had simply attributed the disorder to cleaning staff or new staff members. Two days after this break-in, Dr. Celso Mendoza, a specialist in biomedical defense employed in monitoring safety standards at CFB Suffield, was grilled for several hours by DND officials in a motel room in Medicine Hat, Alta. According to Mendoza, he was accused of "leaking politically embarrassing information to members of Parliament." In addition, a report has been circulated amongst Mendoza's colleagues accusing him of professional incompetence. Mendoza is preparing to sue the federal government over what he calls "constant harassment" by the DND.

10 April 89 - Green Party of Canada, Vancouver office: Disks holding membership lists were stolen. No other equipment, including a stereo and a photocopier, was touched.

Yesterday Canadian Solicitor-General Pierre Blais, having previously claimed there was no link between the break-ins, said that he would order RCMP Commissioner Norman Inkster (who has also denied a link) to investigate the possibility of one. Blais also said he would speak to the minister for National Defense, Bill McKnight, about the questioning of Dr. Mendoza. "These are serious allegations made by Mr. Fulton," said Blais. "They are already in the press and it's a very serious matter."

Said Fulton: "If five branches of the Toronto-Dominion Bank had been mugged in the last couple of months with the same kind of modus operandi, the same kind of files being rifled, ... there would be a major investigation going on. The names and addresses of tens of thousands of Canadians have been taken in these break-ins."

All of the thefts remain unsolved. According to Sergeant Len Paris of the University of Toronto police force, "Thefts of items under $1000 don't attract a lot of police attention."

Hugh Miller, University of Toronto

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

Date: Thu, 20 Apr 89 20:57:24 EDT From: Mark Brader <msb@sq.sq.com> Subject: Computer orders for phone books (Only 17?)

Today's Toronto Star has an article about a person who's been getting 17 telephone books delivered to his house each year for the past 5 years. The computer's role in this should be obvious. And I suppose it's not for the delivery people to say how many directories should be delivered to a particular place, just because it looks like a residence...

The Star says the victim says Bell Canada says he's actually supposed to be getting *22* phone books.

The directory has 2,084 pages and extra copies cost $20 (Canadian). [each?]

Mark Brader, Toronto

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

Date: Mon, 24 Apr 89 10:03:32 PDT From: forags@violet.berkeley.edu Subject: ATM's used to track accused killer

According to a recent article in the Marin Independent-Journal, authorities were monitoring ATM transactions to trace the movements of accused killer Ramon Salcido. In addition to simply monitoring ATM use, his line of credit was changed to "unlimited" since authorities were afraid that he might become violent if he couldn't get money because he had exceeded his limit.

Al Stangenberger, Dept. of Forestry & Resource Mgt., 145 Mulford Hall, Univ. of Calif., Berkeley, CA 94720 (415) 642-4424

[In times of emergency such as this, we suspect that such requests can be legally by appropriate agencies without too much fuss. The question of course remains as to the extent to which your ATM and credit/debit transactions remain private otherwise. The recent considerations for expanding the National Crime Information Center (discussed here in RISKS-8.27) rejected inclusion of such data from being routinely accessible to law enforcement officers... However, the fact that access is already so widely possible suggests that privacy is not easily enforced. PGN]

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

Date: Fri, 21 Apr 89 3:19:10 EDT From: Chris Davis <smghy6c@buacca.bu.edu> Subject: Computer Voting (RISKS 8.60)

Boston U. has been using computers (Macs) to tally votes both this year and last. Many of the issues you mentioned have been, if not completely dealt with, at least started on:

The vote tally program is written in HyperCard. The keyboard (which is used to enter college and residence information for the non-University wide positions) is kept by the computer's owner (who is an official member of the student election process at that point). The mouse is used to check off votes, and when the user is finished, they leave. With only a mouse (and a limited number of buttons to use) it's hard to do much to the system by way of changing votes or crashing it... and privacy is kept by having the screen turned AWAY from the computer's owner while voting. There are, however, still some RISKS involved.

First is that of disk crashes. This happened this year--a certain number of votes were unreadable. (The student newspaper didn't give details, so I can't report on those.) They were not enough to have affected the Student Union race, though it's possible that they might have changed some college or residence races (no, I don't know for certain). An unscrupulous programmer may very well change votes, or the computer's owner could pull something (if they're technically capable--which isn't much with HyperCard).

The second is the RISK to the Mac user interface standard posed by the untrained (at least in Apple's guidelines) programmer. Not that this is a major RISK on the order of 767 fuel gauges, but it had a tendency to confuse me--precisely BECAUSE I use a Macintosh so often.

Chris "Data" Davis, Student Consultant, Boston University

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

Date: Sat, 22 Apr 89 11:35:21 PST From: David Schachter <david%daisy@sri-unix.UUCP> Subject: Re: Most Accurate Clock

In Risks 8.58, an article noted problems with assuming the correctness of time output by radio controlled clocks. I've a couple of notes on the subject and I speak as a designer of one such clock, Precision Standard Time's "Time Source".

1. The operator at WWV has been known to forget to set or reset the Daylight Savings Time switch on the time code generator in Colorado. We discovered this because we were looking at the transmitted signal the day DST was supposed to start. When we received Hawaii (WWVH), the bit was set and when we received Colorado (WWV), it wasn't. We called WWV and asked what the problem was; they were rather abashed.

To solve this, PSTI is building new time code generators for WWV which will automate almost the entire task. Human intervention will be required to set the start and stop dates for DST, and to notify the time code generator of pending leap seconds, and the (very simple) software will take it from there. The design of the new time code generators, in both hardware and software, is intended to be very simple, so we can have a hope of correctness. This, of course, assumes the microprocessor and other VLSI chips we are using are, in fact, correct. Naturally, the hardware is triply-redundant. The software, however, is not, so common-mode failures will not be prevented.

2. Radio clocks are not perfect. Even if the software is bug-free, and the hardware is glitch-free (neither of which hold in practice), two major holes still exist: WWV, WWVH, WWVB, and, I believe, GOES, have no error detection or correction capability. It is possible for a radio clock to receive false radio data due to noise. In the PSTI clock, I put in a sophisticated algorithm to try and reject false data, but it is probabilistic: there is a chance the clock will output the wrong time. Most likely, an incorrect output will be wildly wrong, so host systems can reject it as bogus, reset the clock (or let it correct itself when "good" data overpowers the "bad"), and continue. Furthermore, if you are using a radio clock as a security measure, you should be aware how easy it is to falsify WWV, WWVH, and WWVB. For testing the PSTI clock, we built a WWV simulator, using the guts of another clock, and three 555-based oscillators. Hooking this into the modulation input of our venerable, WW-II vintage signal generator, we were able to create radio signals just like, but more powerful than, WWV and WWVH, and thence to fool the clock. This was great for testing, so we could check behavior of DST start/stop, propagation delay changes, year rollover, leap second insertion/deletion, and so on. But if you are using a radio clock for security, be warned that someone in a van outside your building can trivially fake the signal.

I bet the GPS satellite time signals contain error detection codes, if not error correction, which ought to reduce false time output to a minimum, but won't stop a bad person from faking the time.

Unfortunately, I couldn't get anyone interested in modifying the WWV/WWVH code to include a public-key encipherment approach, so that if the clock can decode the signal, the signal must have come from WWV/WWVH. -- David Schachter

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

Date: Fri, 21 Apr 89 01:50:35 EDT From: "Leigh L. Klotz" <KLOTZ@AI.AI.MIT.EDU> Subject: Writing on write-protected 5.25" disks

No software hackery is necessary. Simply open up the disk drive and tape the switch closed or put something opaque in the path of the light sensor. I once had to do this to fix defective software on some commercially duplicated disks at a small software company.

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

Date: Fri, 21 Apr 89 09:27:23 EDT From: luken@ubu.cc.lehigh.edu (Kenneth R. van Wyk) Subject: Re: Writing on "write protected" disks

In Risks 8.61, David M. Zielke and Peter Jones point out vulnerabilities of current write protect mechanisms. Specifically, they say that write protection is done at a software level on some microcomputers, including Apple IIs and (at least some) IBM PCs.

There was a heavily debated discussion on PC write protection mechanisms on the VIRUS-L forum not too long ago. The outcome was this: I looked at the IBM ROM listing and saw that the ROM was attempting a write (via the hardware disk drive controller) and *then* checking to see if there was an error status returned. Furthermore, two of our students, Richard Baum and John Hunt, checked the circuit diagrams of the original IBM PC floppy disk drives and determined that, indeed, the write protection mechanism was in hardware. Now, assuming that the write protect sensor is correctly determining the presence of a write protect tab, we concluded that no disk writes could occur.

It may or may not be different on other PC models (such as the AT that David Zielke refers to), but the IBM PC floppy disk write protection is done in hardware. I invite anyone to prove otherwise by providing me (or Risks) with a piece of code that can verifyably write to a write protected PC disk on a machine whose write protect mechanism is functioning.

Kenneth R. van Wyk, VIRUS-L moderator <luken@ubu.cc.lehigh.edu> or <luken@lehiibm1.bitnet>

[Readers who have been exposed to this in VIRUS-L or who don't care about PCs, clones, and Apples MAY IGNORE THE REST of this RISKS issue. Otherwise, please pardon the redundancy, although the following messages add a little bit here and there. But I'll blow the whistle after this issue. PGN]

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

Date: Mon, 24 Apr 89 11:46 EST From: <PGOETZ@LOYVAX.BITNET> (Omniphobe) Subject: Apple write-protection

Recently, a posting appeared in RISKS which claimed that the Apple write- protection is implemented in software. Wrong. Take it from me; I unfortunately know everything about the Apple ][+. Write-protection is implemented in hardware. Software routines are used to _detect_ write-protection. You can remove these routines and fool the operating system into thinking that it has written to a write-protected disk, but it has not. (In fact, I have performed this test under DOS 3.3 with a 5.25" drive.) It is possible that 3.5" drives might not have write-protection, just a tab detector, but I doubt it. It costs almost nothing to do it in hardware. I attribute the claim that IBM drives do not implement it in hardware to the fact that the IBM is a shoddy conservative machine which can't even scroll the screen without flashing, and whose designers cannot compare to the Woz (who also designed the ][ 5.25" drive). But then, nobody can.

Apple drives sometimes destroy write-protected disks, but those cases are due to hardware problems.

Phil Goetz PGOETZ@LOYVAX.bitnet

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

Date: Sat, 22 Apr 89 23:21 EST From: <DLV%CUNYVMS1.BITNET@CUNYVM.CUNY.EDU> Subject: IBM PC's write protection is in the hardware!!!

Here is the reply to Mr. Zielke's letter that I sent to the IBM PC list. Since you chose to post his (uninformed) message, I think it would be a good idea to post my reply as well to aleviate some of the (totally baseless) fear and anxiety it might generate.

The technical reference to the Real IBM AT ('Personal computer AT high Capacity Diskette Drive', Aug. 31, 1984, pp. 7&8) clearly shows that the drive won't write unless the write protect sensor sees a hole. The protection is not in the software (DOS or BIOS) and not in the FDC firmware. It is done in the drive's hardware. If you want to write to disks with no notch in them, you have to disable the write protect sensor---a minor operation, but more than just writing some code. It requires a screwdriver. I suggest that you confirm this with your friend.

There was a long discussion in the virus list about whether the write protection on IBM PC is hardware or software; you may want to dig up its archive to read the sometimes heated discussion (Mac users stating that they know nothing about PCs but someone told them that only DOS calls check for write protection and BIOS calls will write irrespective of the notch; cheapo non-IBM drives that ignore black and/or mirror tabs; etc).

The question was settled for good in virus-l, and I hope there's no need for every un/misinformed user to submit his 2 bits worth to RISKS.

Dimitri Vulis, Department of Mathematics, CUNY Graduate Center

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

Date: Fri, 21 Apr 89 23:24:14 -0400 From: henry@utzoo.UUCP Subject: Re: Writing on "write-protected" disks

>... Do RISKS >readers know of other systems that are not protected at the hardware level?

It depends on what you mean by "at the hardware level". Almost any system with multiple heads (this includes most modern disk and tape) will find it difficult to run the final write signal to the heads via the write-protect switch. Any other scheme introduces electronics between the switch and the heads, and those electronics can fail. Also, said electronics may well include firmware in microcontroller chips -- is this "hardware" protection? That aside, everything I'm familiar with does the write-protect check at a level where user programming can't affect it... but what horrors microcomputer companies will perpetrate to save a few cents, only they and their customers can tell. (As witness the original IBM PC monochrome monitor, which software could burn out by setting control registers improperly -- IBM borrowed the monitor from an earlier product which wasn't user-programmable.)

Henry Spencer at U of Toronto Zoology

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

Date: Fri, 21 Apr 89 23:37 EDT From: Kemp@DOCKMASTER.NCSC.MIL Subject: Re: Writing on "write-protected" disks

I do not know what sort of Apple-]['s are used in Montreal, but mine certainly does have disk write protection in both hardware and software. Back in the days when Apple published schematics (before they made Macintoshes), their DOS manual contained schematics of both the disk controller card and the disk drive analog board. The analog board sits inside the disk drive and controls, among other things, the voltage applied to the erase head. The schematic shows that the write protect signal from the switch that senses the notch in the diskette is used to gate the write request signal from the controller, thus providing (in the absence of hardware failure) a non-overrideable write inhibit. The write protect signal was also provided to the controller card, where the software could query the write protect status of the drive.

Of course, many Apple owners were not afraid of modifying their hardware, and one particularly popular modification was to install an external write enable switch that bypassed the notch switch, or to disable the write protection entirely. This saved the user from having to cut notches in order to use the reverse side of single-sided diskettes.

Dave Kemp <Kemp@dockmaster.ncsc.mil>

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

Date: Fri, 21 Apr 89 18:51:53 EDT From: rich@pro-exchange.cts.com (Rich Sims) Subject: Re: Writing on "write protected" disks

In digest #8.61 it is reported that it is possible for software to defeat the "write protection" notch on 5.25" disks, on both Apple and IBM disk drives.

I can not speak for all disk drive manufacturers, but in the case of the Apple drives, the information reported in the article is totally incorrect. Apple 5.25" disk drives use an electro-mechanical switch that prevents writing to the disk unless the "write protect" notch is unobstructed.

It is possible to defeat the software "sensing" of the write-protect switch, but it is not possible to defeat the switch itself from software. If this is done, the only effect will be that the appropriate error message will not be presented to the user. The drive still can not write to the disk. Depending on how the software changes were made, there still may be an error message generated, when the O/S is unable to "verify" the supposedly written data.

It is still possible to destroy a disk though, given the right combination of hardware failures. In that case, the procedure recommended by the users group would be perfectly valid, and a very good idea. After all, if the hardware has failed to the extent of destroying disks, it makes good sense to test it on disks that you can afford to lose -- not your only copy of that $500 program that helps keep your business running.

Of course, a competent hardware person can just ........ :-)

Rich Sims

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

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