From: risks@CSL.SRI.COM (RISKS Forum)
Newsgroups: comp.risks
Subject: RISKS DIGEST 14.04
Date: 12 Nov 92 02:26:16 GMT
Reply-To: risks@csl.sri.com
Distribution: world
Organization: The Internet

RISKS-LIST: RISKS-FORUM Digest  Weds 11 November 1992  Volume 14 : Issue 04

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

  Contents:
Abuse of federal computer access (Barry C. Nelson)
Therac-25 (Nancy Leveson)
When "yes" means "no" (More voting screwups) (Ted Shapin)
Re: Voting Machine Horror Story (David Conrad)
Voicemail problems (C Martin)
FBI digital telephony article in IEEE Institute (M. Granger Morgan via 
    Lance Hoffman)
Key registration risks (Phil Karn, Otto Tennant, Robert Philhower, PGN)
Re: Risks Of Cellular Speech (Robert Gezelter)
Re: Persistent resources and hypertext (David A. Honig)

 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 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 14, 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.

 For information regarding delivery of RISKS by FAX, phone 310-455-9300
 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com).

 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: Wed, 11 Nov 92 14:48:14 EST
From: "Barry C. Nelson" <bnelson@ccb.bbn.com>
Subject: Abuse of federal computer access

At the September 92 Seminar of the American Society for Industrial Security
(ASIS), I attended a lecture by the office of the Inspector General of Health
and Human Services (HHS-IG).  They are normally tasked with tracking down
people who cheat on Medicare and other assistance programs. Last year they
cited $15 million in penalties in over 2500 cases.

The lecture was about "Operation Private Trust" -- catching people who
abused their official computer access.  In mid-1990 HHS noticed that a
company in Florida was offering personal information which could
probably not be legally obtained as fast as they were providing it.
They called themselves "Nationwide Electronic Tracking" service, NET.

NET offered everything from credit checks in an hour ($10) to a 10-year
employment history ($175) in five days.  A scale of prices included
$7.50 to get someone's home address based on their Social Security
Number in under two hours.  They also offered info on a variety of
topics including your official criminal records, employers, neighbors,
post office box, driver's license and car registration, workmen's
compensation claims, etc.

There are normally 200,000 legitimate external IRS queries every year,
but processing them normally takes 2-4 weeks, providing a niche for a
criminal entrepreneur.  How do you identify the illegal queries?

To make a long story short: They laid a trap wherein a NET "customer"
requested information based on a certain SSN.  HHS then asked the IRS to
quietly monitor their system for a query.  It popped up two hours later
in Phoenix.  (The IRS had to modify their system to trace the identity
of the person requesting the information.) Investigators then did other
types of queries and soon discovered a large nationwide network of
middlemen with sources working at various government agencies.  Dozens
of government employees were selling information to which they had
online access.  Systems included IRS tax returns, and the FBI's NCIC.

In some cases the "customers" were drug dealers who were trying to check out
backgrounds in order to find undercover investigators.  Some of the "middlemen"
also turned out to be former IG and other HHS agents who were aware of the
records' accessibility and lack of system security.  The middlemen made huge
tax-free profits.  Where NET customers paid $100 for a report, the clerk who
did the access might receive only $5 for the effort.

As a result of the investigation, the US Attorney in Tampa issued ten
indictments against fourteen people, and 11 of them pleaded guilty.  They were
charged with over 30 counts of conspiracy, unauthorized disclosure of tax
return information, theft/conversion of government property (records), aiding
and abetting a crime, bribery of public officials, making false official
statements, and fraudulent access to Federal computers (18 USC 1030(a)(4)).
There were details of literally hundreds of illegal overt acts (some of which
were probably recorded on wiretaps).  Additional indictments were filed in New
Jersey with more to follow soon.

The IRS systems have now been tightened up so that fewer clerks have valid
access rights.  Audit records are now scrutinized monthly and clerk transaction
profiles monitored. The FBI is said to be "examining the problem" of user
authentication on their systems.

The moral of the story was: If you're given special access to online federal
information and you abuse it, you may have to pay the consequences which
include ten years in federal prison and a $10,000 fine.  No end-users of the
illegally obtained files were indicted and there continues to be a large market
for private information held in government computer systems.
                                                                -BCNelson

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

Date: Wed, 11 Nov 92 12:00:15 -0800
From: Nancy Leveson <nancy@murphy.ICS.UCI.EDU>
Subject: Therac-25

A paper describing the details of what really happened with the Therac-25,
including detailed descriptions of the software bugs and the response by users,
government agencies, the manufacturer, etc. is now in review for publication
and available as a technical report.  This is the result of three years of
detective work by myself and Clark Turner (my student) and the collection and
distillation of several large boxes of documents.  Many of the previous media
accounts and papers have been incomplete, misleading, or plain wrong.

To order, call or write to UCI (Info. and Computer Science Dept., University
of California, Irvine, CA 92717) or to UW (Computer Science and Engineering, 
FR-35, University of Washington, Seattle, WA 98195) and ask for:

    "An Investigation of the Therac-25 Accidents," by Nancy Leveson and
     Clark Turner.  UCI TR #92-108 or UW TR #92-11-05

        [Nancy gave a preview of this paper in New Orleans at SIGSOFT '91
        last December.  It has been long awaited, and I expect it will be a
        best-selling technothriller, even if it is completely NONfiction.  
        (Truth is often stranger than fiction, anyway!)  However, I hope RISKS
        readers do not deluge Nancy with TOO MANY requests that she decides 
        never again to make such a generous offer!  But I am absolutely 
        delighted that she is giving RISKS readers an early chance to review
        this report.  PGN]

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

Date: 11 Nov 1992 09:04:39 -0800 (PST)
From: Ted Shapin <TSHAPIN@biivax.dp.BECKMAN.COM>
Subject: When "yes" means "no" (More voting screwups)

From an article by Daryl Kelley, Los Angeles Times Staff Writer, Nov. 11, 1992:

Chagrined Ventura County [CA] election officials confirmed Tuesday [Nov 10?]
that they had fed inaccurate vote tabulations on 13 state ballot propositions
to the secretary of state's office last week.  The foul-up, which reversed
Ventura County's YES and NO votes for each proposition, did not involve enough
votes to change the outcome for any of the statewide measures, state officials
said.

"I don't know of any other county that screwed up, but I did," Ventura County
elections chief Bruce Bradley said Tuesday. "I linked their YES [computer line]
to my NO, and vice versa. So on Thursday when we found out, we corrected it."
The error was made only on the ballot measures, Bradley said.  Ventura County
tabulations in other state and federal races, such as the two for U.S. Senate,
were fed accurately to Sacramento by computer lines identified with the names
of the candidates, he said.  All the results for local ballot measures and
races were accurate, Bradley said.

Melissa Warren, spokeswoman for the secretary of state, said the error did not
affect the outcome of any proposition because Ventura County's voting trends
generally jibed with the rest of the state and because Ventura County voters
are a small part of the state total.

The closest ballot measure was Proposition 162, which shifts control of funds
in the public employees' retirement systems.  The measure won by 187,101 votes
statewide, according to semiofficial results, It lost by 5,528 votes in Ventura
County.

Such mistakes are not rare, Warren said.
==== ======== === === ===== ====== ====  [emphasis added!]

Over the next three weeks, California counties will count late arriving
absentee ballots and provisional and damaged ballots, Warren said.  Then they
will file a final count with the state by Dec. 1. An official count is expected
to be released Dec. 14.

John Flynn, chairman of the Ventura County Board of Supervisors, said he had
just congratulated Bradley on a particularly smooth election when he learned of
the mistake Tuesday.  "It's regrettable," Flynn said. "But these are human
beings who run these things."

   Ted Shapin, Beckman Instruments, Inc., 2500 Harbor, M/S X-11           
   Fullerton, CA  92634-3100   714/961-3393 tshapin@beckman.com

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

Date: Wed Nov 11 06:53:00 1992
From: dave@tygra.Michigan.COM (David Conrad)
Subject: Re: Voting Machine Horror Story (Stangenberger, RISKS-14.02)

   [tygra!dave@destroyer.rs.itd.umich.edu]

This sounds quite like the system used here in Detroit, MI.  I always
spot-check a few important items to a) make sure that they are correct and b)
give me confidence that the rest of the ballot is punched correctly.  This is
possible because the correct box numbers are printed on the ballot.

So, for instance, in the recent election I verified the holes on the card with
the numbers on the ballot for: President, Congressional Representative, and the
four major ballot proposals here in Michigan; but not for all the minor and
judicial offices.  I also looked at the ballot before I put it in the machine
to make sure no holes had been accidentally punched.

Some may consider this excessive, paranoid, or simply inconsiderate of
others who were waiting for my voting booth (we had a record turnout,
and I had to do it in the booth since I needed to be looking at the
ballot to compare the numbers), but considering how quick and easy it
was and that no perfect voting machine will ever be built, I think that
double-checking by the voter is the only prudent course.

Note also that checking would be impossible if the correct numbers were not
given on the ballot, as they are here in Detroit and apparently were in
Berkeley.
             David R. Conrad  dave@michigan.com

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

Date: 11 Nov 92 14:56:00 EST
From: "PGE" <CMARTIN@unode2.nswc.navy.mil>
Subject: Voicemail problems

    When I went to college (University of Maryland at College Park) our school
got a new voice mail system to keep up with the times.  This system offered a
message area for each user accessible from any phone so long as you knew the
passcode for that particular number.  The problem was that all the passwords
were set to 12345 at the beginning of the semester, so the people who first got
to campus started having a ball changing friends, enemies and strangers
passcodes.  By the time I got to campus, I had several messages that I could
not get to because the passcode had been changed(remember this was before
classes began so students had lots of time on their hands).  I had no way to
figure out my code except to go to the phone building on campus (though it
never came to that because a friend confessed to doing it and gave me the
number).
    Another risk was the students were never explicitly told that all the
numbers were the same, so some students left their number the same and as a
result people would "fish" for numbers to listen to the messages of.  If any
sort of security was there to protect the information (logs or the like) no one
I knew who did this ever got caught, and castigated.
    The final problem was the message append function.  What people could do
is the same as E-MAIL reply, except with the original message appended.  People
would send these messages back and forth until they filled your mailbox, then
they would send the message to every number they could think of(if you knew
someone in a dormitory, all the hallmates numbers clustered around their
number and so all of them might get the message).  
    During my final year there, when the system was installed these problems
were never noticeably addressed, including at the end of the semester being
asked to change the passcode back to 12345.
    Well, this is just a warning to system engineers to better recognize the
users of a system to better handle these shortcomings.

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

Date: Wed, 11 Nov 92 13:54:05 EST
From: "Lance J. Hoffman" <hoffman@seas.gwu.edu>
Subject: Re: FBI digital telephony article in IEEE Institute (fwd)

Reprinted with permission ("do with it as you wish.  Granger") 
[and forwarded by Professor Lance J. Hoffman, EECS, The George Washington
University, Washington, D. C. 20052, (202) 994-4955 hoffman@seas.gwu.edu]

A "Viewpoint " piece in  The Institute, November 1992

Balancing National Interests

  The September/October issue of The Institute carried a front page story
reporting that the Federal Bureau of Investigation is promoting legislation
that would require all telephone systems to be designed in such a way that they
can be wiretapped by law enforcement officials.  The argument is that
wiretapping is a key tool in much of law enforcement, particularly in fields
such as drugs, racketeering, conspiracy and white collar crime, and that unless
care is taken in the design of future telecommunications systems, this tool may
become difficult or impossible to exercise.  To solve this problem the FBI is
promoting legislation that would establish design requirements on future
telephone systems.  Not surprisingly, civil liberties groups and telephone
companies are reported to be less than enthusiastic.

	While interesting and important in its own right, this controversy is
perhaps even more important as a symbol of a broader set of conflicts between a
number of important national interests. As a country, we want to promote:

  * Individual privacy (including the right of citizens and other residents of
the U.S. to keep personal records private, hold private communications with
others, and move about without being "tracked".)

  * Security for organizations (including protection of financial transactions,
and the ability to keep corporate data, plans, and communications
confidential.)

  * Effective domestic law enforcement (including the ability to perform
surveillance of legitimately identified suspects, and the ability to audit and
reconstruct fraudulent activities.)

  * Effective international intelligence gathering (including the ability to
monitor the plans and activities of organizations abroad that may pose a threat
to the U.S. or to other peaceful states and peoples.)

  * Secure world-wide reliable communications for U.S. diplomats and the
military, for U.S. business, and for U.S. citizens in their activities all
around the world (including the ability to maintain and gain access to secure,
reliable, communications channels.)

	Just as with most of our society's other fundamental objectives, these
objectives are in conflict.  You can not maximize them all because getting more
of some involves giving up some of others.  A dynamic tension must be created
that keeps the various objectives properly balanced.  That socially optimal
point of balance may change gradually over time as world conditions and our
society's values evolve.

	An electrical engineer who thinks for a moment about the problem of
achieving any particular specified balance among the various objectives I have
listed will quickly conclude that communications and information technology
design choices lie at the heart of the way in which many of the necessary
tradeoffs will be made.  We would like easy portable communications for all,
but doing that in a way that allows people to keep their legitimate travels
private poses significant design challenges.  Banks and other businesses would
like secure encrypted communications world-wide, but promoting the general
availability of such technologies all around the world severely complicates the
signal intelligence operations of intelligence organizations.

	The troubling thing about the FBI's legislative proposals is not that
they are being made, but that we lack a broader institutional context within
which to evaluate them.  In making such choices, we need to look systematically
at all the legitimate interests that are at stake in telecommunications and
information technology design choices, consider the ways in which technology
and the world are evolving, and integrate all these considerations to arrive at
a reasoned balance.  In the old days, if things got too far out of line in some
balance (for example, between freedom of the press and protection against
liable), the courts simply readjusted things and we went on.  Today, and
increasingly in the future, with many of these balances hard wired into the
basic design of our information and communication systems, it may be much
harder to readjust the balance after the fact.

	There are several organizations that should be working harder on these
issues.  On the government side the Telecommunication and Computing
Technologies Program in the Office of Technology Assessment should be doing
more systematic studies of these tradeoffs to help inform the Congress; The
National Telecommunications and Information Administration in the Department of
Commerce (or some appropriate interagency committee) should be doing similar
studies to develop more coherent and comprehensive executive branch policy; and
the Office of Policy and Plans in the Federal Communications Commission (which
is an independent regulatory agency not directly subject to executive branch
policy) should be giving these issues more attention so it can better support
the Commissioners when they confront such tradeoffs.  On the non-government
side, the Office of Computer and Information Technology at the National
Research Council might appropriately mount a comprehensive study.  There is an
ideal opportunity here for a private foundation to fund an independent
blue-ribbon commission.  Finally, the computer and telecommunications
industries, both individually and collectively through their industry
associations, should be taking more interest in how the country will strike
these all important balances.
							M. Granger Morgan

M. Granger Morgan (F) is head of the Department of Engineering and Public
Policy at Carnegie Mellon University where he is also a Professor in the
Department of Electrical and Computer Engineering and in the H. John Heinz III
School of Public Policy and Management.  He teaches and performs research on a
variety of problems in technology and public policy in which technical issues
are of central importance.

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

Date: Mon, 26 Oct 92 20:29:17 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Encryption key registration risks

David Willcox spoke of the obvious risks of registering encryption keys with
some agency. Dorothy Denning responded in RISKS-13.86 that the "risk can be
reduced to about zero" and described a mechanism. Yet neither elaborated on
just what specific risks are to be protected against.

Denning chooses to ignore one obvious class of risks: defective warrants,
incompetence and/or outright corruption in the government and the key
registration agency. The government has abused its wiretap facilities in the
past (e.g., Operation Shamrock) and will do so again until the widespread use
of strong cryptography stops it.

Anyone who thinks that the warrant is a meaningful safeguard ought to consider
what happened recently in Poway, California (just northeast of San Diego).
Customs and DEA agents broke into an innocent man's house at midnight and
exchanged gunfire with the owner, who quite reasonably thought his home was
being invaded (the agents did not identify themselves). Last I heard, the owner
was in critical condition in the hospital. After the shooting, neighbors
overheard the leader telling his troops "Now get this straight. He shot first!"

The sole basis of the warrant? A "tip" from an informer, already known by
Customs to be unreliable. He admitted the next day that he had merely picked a
house at random when the agents pressed him to "produce".

The judge who approved this particular warrant obviously didn't scrutinize it
very closely despite the clear potential for serious injury to an innocent
person. It's not hard to imagine a judge being even less critical of an
application for a wiretap warrant. "After all", he'll reason, "what harm can to
you really do to an innocent person by just listening to his phone calls?  It's
not like the agents are asking for permission to break his door down."

That's the whole problem with government wiretaps. They're easy and (from law
enforcement's perspective) almost risk-free. Break down the wrong guy's door,
and there's no way to keep it out of the papers.  But tap the wrong guy's phone
and he may never know. Warrants?  Don't bother -- they leave paper trails, and
are unnecessary unless you want to produce the recordings in court. There are
many other uses for wiretaps that need not reveal one's "sources and methods".

This is especially tempting with radio. ECPA or no ECPA, the fact is that it's
incredibly easy to intercept analog cell phones and very hard to get caught
doing it.  Indeed, the government successfully opposed meaningful encryption in
digital cellular, even though it would only protect the air link -- the land
side of the call could still be tapped with the phone company's assistance.  I
wonder why.

Okay, so maybe I'm paranoid. But I don't think so. A healthy distrust of
government, particularly of those functions that are not always open to public
scrutiny, is essential to a free society. Or so the authors of the Constitution
seemed to think, even if the average person wouldn't mind repealing the Bill of
Rights to help fight the drug war.

But let's assume that we've found some saints to populate the entire Executive
branch, so we can safely pass a law requiring crypto key registration. Exactly
how would it be enforced? Routinely scan all private telephone conversations
looking for bit streams that cannot be easily decoded? What about certain rare
natural languages - ban them too? (Recall that the US military used Navajo
radio operators in the Pacific during WWII as "human crypto machines" against
the Japanese).  So much for the First Amendment.

Suppose you find an undecodable conversation that you actually have good reason
to believe conceals criminal activity. How would you compel the users to reveal
the key, if indeed they used a protocol that could be compromised in this way?
According to several lawyers I've asked, including a law professor at the
University of Wisconsin who specializes in the Fifth Amendment, a memorized
crypto key would clearly be considered "testimonial" evidence that could not be
compelled without a grant of immunity. So what do we do -- repeal the Fifth
Amendment too?

It is absolutely obvious to me that any attempt to control the private use of
cryptography could not help but impinge on some very basic Constitutional
guarantees. And yet it probably still wouldn't have the desired effect. It's
already a cliche, but it's still true: when cryptography is outlawed, only
outlaws will use cryptography. (And no, I *don't* believe the same is true for
guns.)
                                      Phil

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

Date: Tue, 10 Nov 92 22:43:16 CST
From: jot@teak.cray.com (Otto Tennant)
Subject: Evading registration of cryptography keys

Suppose both parties ("Joe Teflon" and "Louie") have a ".gif" picture of
something, say Yellowstone Falls, exchanged by disk.  An encrypted message
could be overlayed as "noise" on the video image, recovered easily on the other
end, while appearing innocuous to anyone intercepting the image.

(To tease, one could use politically incorrect images.)

Attempts to defeat encryption will defeat only the stupid.  Maybe that
is worthwhile.

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

Date: Wed, 11 Nov 92 09:51:32 -0500
From: philhowr@unix.cie.rpi.edu
Subject: Cryptic messages in RISKS (RISKS-14.03)

Our moderator writes:

>    [...Actually, there are all sorts of cryptic messages hidden in 
>    RISKS, but few people seem to notice them.  PGN]

It is not surprising that few people notice the cryptic messages hidden in
RISKS.  The longevity of the Forum itself attests to the fact that few people
notice even the obvious messages of RISKS.

Robert Philhower, Rensselaer Center for Integrated Electronics, CII 6111
Rensselaer Polytechnic Institute / Troy, NY 12180  philhowr@unix.cie.rpi.edu

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

Date: Wed, 11 Nov 92 18:15:12 PDT
From: "Peter G. Neumann" <neumann@csl.sri.com>

Thanks, Robert.  By the way, I think we have about mined this one out for the
time being, so let's see if I can end it without opening up more discussion!
Thanks to Dorothy Denning for having opened up a difficult debate at the
National Computer Security Conference, Rebecca Mercuri for having brought it up
in RISKS-13.84, and all the rest of you who contributed.  The problems are very
deep, and the risks of simplistic solutions are extensive.  This is probably
one of those cases in which "there are no easy answers."  However, just because
a supposedly "easy answer" got included in RISKS, don't assume it was correct,
or reasonable, or realistic -- even if it went unchallenged.  I did not include
ALL of the messages on this subject.  There were simply too many.  PGN

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

Date: Wed, 11 Nov 92 00:51:41 EST
From: Robert Gezelter <gezelter@rlgsc.com>
Subject: Re: Risks Of Cellular Speech (Johnathan Vail, RISKS-14.02)

There is a comment in "Risks of Cellular Speech" in RISKS-14.02 which, I
suspect, is not correct.

While I believe that it is true that the use of Cellular phones is prohibited
in aircraft (at least those operating under Instrument Flight Rules), I seem to
remember that the rationale is aviation related, not Cellular Phone related. To
be exact, my recollection is that the frequencies used by Cellular are fairly
close to some of the frequencies used by the avionics.

In any event, the prohibition is, I believe, a blanket one, not based on, for
example, altitude. If the problem were caused by cell overlap, then there would
need to be a ban on the use of Cell phones at any altitude where more than one
cell site would be over the horizon.

I seem to remember a discussion on this subject a couple of months ago in
rec.aviation, but I don't have easy access to an archive.

Bob    Robert Gezelter Software Consultant    5-20 167th Street, Suite 215
Flushing, New York  11358-1731   +1 718 463 1079   gezelter@rlgsc.com 

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

Date: Tue, 10 Nov 92 16:26:31 -0800
From: "David A. Honig" <honig@ruffles.ICS.UCI.EDU>
Subject: Re: (was persistent resources; risks of thinking hypertext complete) 

In RISKS-14.03 I saw mention of an earlier post in which I described my
discovery that BSD shared memory segments persist; people who know better will
be reassured to find out that I have since understood 1) that this persistence
can be a feature, not a bug and 2) the SysV libraries allow one to use mmap()
calls to implement shared memory, without the 100 segments of 1MB each
limitation (*).

But I discovered along the way two interesting things: first, you can't
trust the man pages' SEE ALSO section to give you complete cross-referencing
on all related topics, especially between the BSD and SysV camps.  Second,
the Net and Local Smart People (who turned me on to the mmap() calls) are
really great resources.

(*) It was pointed out to me that the BSD segments can be made contiguous,
which is helpful; but I also might conceivably need more than that (yes,
seriously.)

David Honig

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

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