Black Box 4/BlackBox.cdr/textinfo/risks8c.arj/RISKS862.TXT

Text File | 1989-04-25 | 21.4 KB | 422 lines

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)

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

Date:     Thu, 20 Apr 89 21:02:09 EDT
From: Mark Brader <[e-mail]>
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, [e-mail]

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

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

Date:         Fri, 21 Apr 89 09:23:48 EDT
From: Hugh Miller <[e-mail]>
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 <[e-mail]>
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: [e-mail]
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                    [phone]

   [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 <[e-mail]>
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 <[e-mail]>
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" <[e-mail]>
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: [e-mail] (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
<[e-mail]> or <[e-mail]>

   [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: <[e-mail]> (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  [e-mail]

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

Date:     Sat, 22 Apr 89 23:21 EST
From:     <[e-mail]>
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: [e-mail]
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: [e-mail]
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 <[e-mail]>

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

Date: Fri, 21 Apr 89 18:51:53 EDT
From: [e-mail] (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
************************
-------