Text File

precedence: bulk Subject: Risks Digest 21.15

RISKS-LIST: Risks-Forum Digest Weds 20 December 2000 Volume 21 : Issue 15

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

***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/21.15.html> and by anonymous ftp at ftp.sri.com, cd risks .

Contents: Wells Fargo computer network outage (PGN) ATM network for voting: a non-starter (David Jefferson) Re: Voting by machine (Fred Cohen) Alaska Airlines flight 261 (Jim Horning) NY State DMV canceling auto registrations (Danny Burstein) Another DMV Break-in, in Oregon (PGN) Healthcare data bank contains inaccurate and flawed information (Mike Beims) Germany to rely on on-board diagnostics for vehicle emission checks (Bernd Felsche) High reliability (Adam Shostack) Electrocution leads to more deaths (Martin Minow) Spam as a denial of service attack? (Steve Bellovin) Re: Seattle Hospital Hacked (Lynda Ellis) Computers, Freedom, and Privacy CFP2001 Call for Participation (HIIP) Abridged info on RISKS (comp.risks)

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

Date: Sun, 3 Dec 2000 21:12:02 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Wells Fargo computer network outage

On 1 Dec 2000, the nationwide Wells Fargo computer network crashed for a few hours, three days after WF had finished merging their computer networks with those of Norwest (which bought WF in 1998). One of four Hitachi Tritium 400 mainframes in the Minneapolis data center shut itself down, apparently after detecting some sort of anomaly. The result stopped all banking operations that depend on real-time interaction. [Source: Article by Sam Zuckerman, *San Francisco Chronicle*, 2 Dec 2000, PGN-ed]

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

Date: Tue, 19 Dec 2000 20:34:40 -0800 (PST) From: David Jefferson <jefferson@pa.dec.com> Subject: ATM network for voting: a non-starter

The suggestion to use the inter-bank ATM (automated teller machine) networks for voting in public elections has has been floated in several places recently. From a purely hardware point of view, the ATM network has some very desirable security properties: It is a private, national-scale network, unconnected to the Internet, and thus not subject to Internet-based attacks. The terminals are hardened, and are often equipped with cameras and other security devices for remote monitoring, and hence are resistant to tampering (as befits machines carrying tens of thousands of dollars in cash). They are very rugged and reliable. Many have touch-screens, which allows about the simplest possible human interface.

However, in a number of other ways the ATM network is not appropriate for voting. The first problem has to do with voter privacy, coercion, and vote selling. When a person votes in a private situation (i.e. other than a public polling place) there is opportunity either for the voter to be coerced, or to sell his/her vote. Although we live with this fact for absentee ballots, it is not a good idea to give up entirely on the strongest election security and privacy measure ever invented: the Australian secret ballot system in which people are required to vote alone in the privacy of the voting booth, with public observers to assure that no one accompanies them to influence them.

A related issue is voter authentication. It is not sufficient to simply issue voters ID cards with magnetic stripes so they can authenticate themselves using the ATM machine's bank card reader. This is a clear case where the requirements for voter authentication are much stronger than that for financial transactions. People are entitled to authorize someone else to use their ATM card, since it is common for people to share access to money accounts. But a voter authentication system must prevent such sharing, even with a trusted person or a spouse, since the right to vote is nontransferable. Furthermore, unfortunately, voter ID cards and PINs can also be sold, opening the door to widespread vote selling. Stronger authentication than the presentation of a card and PIN must be required when there are no election clerks around to take voters' hand signatures (which can be checked against registration records).

By far the greatest concerns, though, with the possible use of the ATM network for voting, are reliability and security. Even assuming we have confidence in our ability to design and build reliable, secure distributed systems in general (a false assumption), an additional fundamental problem arises in contemplating voting over the ATM network: an irresolvable conflict in the need to run two independent secure systems (the election system and the ATM banking system) on the same networked platform at the same time.

An absolute requirement for the reliability and security of any voting system is for election officials to control ALL of the hardware, software, and networking of all clients and servers, including the operating systems on the voting terminals. (This is the same argument showing why remote Internet voting is today so hopelessly insecure.)

An exactly symmetric argument applies, of course, from the bankers' point of view: the security of the ATM system also rests on the fact that they control ALL of the hardware, software, and networking of their platforms.

If one tried to run both systems on the same terminals and network concurrently, then either the banking software could act like a giant Trojan horse inserted into the election system, or vice-versa. Election officials would worry (rightly) that bank employees or contractors might insert code to undermine the election; and banking officials would worry (rightly) that election administrators or vendors would insert code to steal money! Or the presence of either system might degrade the reliability or performance of the other. It is a practical impossibility to prove that the combined system has no bad interactions, and in general it is just not hopeless to run two mutually-distrusting, mission-critical, high security systems on the same network platform. The situation is made even worse (if that is possible) by the fact that ATM software is totally proprietary; and unless the principle of public source software is established for elections, the same will be true for election software.

The bottom line, then, is that in order to permit secure voting over the ATM network, the (many) network owners would have to be willing to turn it over entirely to election officials for the duration of the election. Since, quite reasonably, the owners are not about to do that even for one day, let alone for enough time to build, test, debug, and certify such a system, the suggestion to use the ATM network for voting is a complete nonstarter.

David Jefferson, Compaq Systems Research Center, Palo Alto, CA

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

Date: Wed, 13 Dec 2000 05:09:05 -0800 (PST) From: Fred Cohen <fc@all.net> Subject: Re: Voting by machine

In order for any practical election process to really gain assured trust, it must have several properties:

1) It must be sufficiently simple and open so that the average person on the street can clearly see exactly how it works, understand it clearly and fully, and participate in it.

2) It must be observable by all parties at all times so that there can be no real question about its legitimacy that cannot be answered by the individuals who were present at the scene.

3) It must produce evidence that cannot be easily altered or destroyed, that can be judged by non-experts examining it, and that is not separate from the actual vote - they must be one and the same.

4) It must be very inexpensive to purchase, maintain, and operate. The lifecycle cost must be on the order of pennies per vote or less and it must be easily maintained by untrained people.

5) It must not depend on anything outside itself to operate, like electrical power, telephone lines, servers, etc.

6) There must not be significant spoilage of supplies or recorded results - either before or after the fact.

7) It must be physically securable on a local basis by local officials and police officials.

8) Each voting location must be able to function independently of all others in every vital aspect of the operation other than the summarizing of overall votes that cross localities.

9) Each voting location must be able to have unique vote layouts and candidates to accommodate the wide range of elections that run both simultaneously and sequentially.

10) The voters must believe that the systems works.

At this point in time, and for the foreseeable future, computerized and particularly Internet-based voting machines and networked voting systems do not, and will not, fulfill the majority of these requirements.

1) They are far too complex and full of details for the average person on the street tun understand at all.

2) The vote goes into a mystery thing and comes out somewhere else as a total. Nobody at the scene sees it go in or come out.

3) The evidence they produce is easily altered and destroyed and it requires substantial expertise to even view any evidence it leaves. Furthermore, that evidence is not in any physical way linked to the original vote.

4) They are expensive to purchase, maintain, and operate. The lifecycle cost is on the order of dollars per vote and they can only be properly maintained by experts.

5) They depend on electricity, network connections, servers, and so forth.

6) There are no supplies (except power and hardware components that require maintenance and replacement) but spoilage cannot universally be detected.

7) The votes not physically securable on a local basis by local officials and police officials because the system is networked.

8) Each voting location can not function independently of others.

9) Each voting location can have unique vote layouts and candidates

10) I don't believe that the systems work, but most voters may be fooled into that belief by a sufficient perception management process.

Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225 Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171 Fred Cohen - Practitioner in Residence - The University of New Haven

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

Date: Tue, 19 Dec 2000 10:47:48 -0800 From: Jim Horning <horning@intertrust.com> Subject: Alaska Airlines flight 261

[FW: Not a computer risk so much as a systemic risk, but interesting. JH]

AVflash Vol. 6, Issue 51a Monday, December 18, 2000

The Top Headlines From AVweb's Expanded, Illustrated News Coverage at <http://avweb.com/n/?51a>.

ALASKA AIRLINES FLIGHT 261: THE HEARINGS... In the aftermath of the January 31 crash of Flight 261, where an Alaska Airlines MD-80 plunged uncontrollably into the Pacific Ocean after failure of part of the aircraft's stabilizer assembly, the NTSB is uncovering some of the shortcomings of a number of systems currently in place. We found out last week, through official FAA testimony, that the jackscrew assembly (a 1960s design) has outlived its paper trail. FAA officials testified that they could not provide an account of how the part was approved -- nor could they provide records of the process which approved it. So, what we are left with is a part with some 35 years of flight history, but not a single official record or word on how it came to be approved for installation in the MD-80.

...WHAT WE KNOW, NOW... While the design of the jackscrew assembly was supposed to assure that the failure of any single part within the assembly can *not* result in complete loss of control, the crash of Flight 261 explains with relative certainty that the failure of a single part *is* capable of causing failure of other parts in the assembly and that those multiple failures are quite capable of bringing down the aircraft. Further, while the manufacturer was aware that the assembly was subject to continuous wear, they were content in the notion that regular maintenance could assure its operation. Alaska Airlines was inspecting the jackscrews every 15 months, but the accident aircraft had flown 8,874 hours since its last inspection -- well beyond the 7,200 suggested by Boeing. The hearings revealed that the FAA had "accepted" the carrier's jackscrew maintenance schedule.

...AND WHAT THE CREW SAID, THEN The pilots radioed their Seattle base seeking advice and relaying their understanding of the serious nature of the situation. Portions of the communication that were made public last week indicate that the base operators were not immediately aware of the magnitude of the problem. This may have induced some agitation in the cockpit as ground-based counterparts second-guessed the captain's decision to divert to LAX and the problem proved its ability to overcome each sequence of corrective measures set forth by the flight crew. During the aircraft's final dive, the verbal exchange between the pilots appears to imply that they attempted to stabilize the aircraft in inverted flight and work with its gyrations to help them roll it back over and keep the nose near the horizon with rudder and elevator inputs. But all attempts by the crew to regain control proved futile as the MD-80 made its final plunge to the ocean.

[PGN-ed: Article in *The New York Times* 18 Dec 2000 noted by Kevin Ziese, who observed that "Had the system operators realized that parts replacement is itself a critical computing function, it's possible that safeguards would have been in place to generate the appropriate alert in a more timely manner. This underscores the importance of recognizing 'critical computing' requirements in all organizations. Even though the system may not be man critical, it may have a significant impact on safety. Integrated systems, especially in a network-centric world, need better safeguards and control mechanisms then the typical software developer provides."]

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

Date: Mon, 11 Dec 2000 03:29:36 -0500 (EST) From: danny burstein <dannyb@panix.com> Subject: NY State DMV canceling auto registrations

The New York State Department of Motor Vehicles (DMV) has a new computer system that is supposed to help locate uninsured motorists, based on information provided electronically by insurance companies. Unfortunately, the database includes drivers who are apparently properly insured -- and who are very unhappy when they are arrested even if they are carrying valid proof-of-insurance cards. The DMV blames drivers for not responding to mailed warnings, although it certainly does not appear blameless, based on the frequency of complaints. [Source, Ann L. Kim, Insurance Is No Insurance Against State DMV Glitch *Newsday*, 10 Dec 2000; PGN-ed]

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

Date: Sun, 18 Dec 2000 22:00:11 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Another DMV Break-in, in Oregon

On the heels of Paul Nowak's RISKS-21.14 report of the Arizona Motor Vehicle counterfeiting rings came this somewhat belated report of a break-in at the Gresham, Oregon DMV office on 12 Dec 2000. The thieves were apparently pretty well prepared, as they took less than two minutes to take computer equipment containing personal information on 3,215 people who had recently obtained licenses, plus blank cards and a machine for making bogus drivers' licenses and ID cards. [Source: Stuart Tomlinson, *The Oregonian*; PGN-ed. Was at http://www.oregonlive.com/news/oregonian/metroeast_week.ssf ?/news/oregonian/00/12/metroeast/e6_dmv15.frame]

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

Date: Mon, 11 Dec 2000 10:01:55 -0500 From: Mike Beims <mbeims@mail-fair.ivv.nasa.gov> Subject: Healthcare data bank contains inaccurate and flawed information

From Reuters and Medscape (Reuters Health), 1 Dec 2000:

"The US government's warehouse of disciplinary records and malpractice actions against physicians and other healthcare practitioners is incomplete and inaccurate in many cases, congressional investigators conclude in a new report."

http://managedcare.medscape.com/reuters/prof/2000/12/12.04/20001201legi001.html

The National Practicioner Data Bank is considered by this report to be seriously flawed and raises a red flag regarding patient privacy.

Like other data banks mentioned in the Risks Digest, when used to track social issues such as credit, criminal activity, and driving records, these data banks can be useless and possibly dangerous to everyone involved.

Mike Beims <Mike.A.Beims@ivv.nasa.gov>

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

Date: Thu, 14 Dec 2000 09:46:38 +0800 (WST) From: Bernd Felsche <bernie@innovative.iinet.net.au> Subject: Germany to rely on on-board diagnostics for vehicle emission checks

*Auto Motor und Sport*, 8 Dec 2000, [a motoring magazine published in Germany] reports that the emissions compliance inspection of new vehicles will be performed solely by reading the ODB (on-board diagnostic) codes. The "testing" regime is to commence no later than July 1st, 2001.

All new gasoline-engined cars are already equipped with OBD, according to DEKRA [a company which performs vehicle inspections] and all diesel-engined cars from 2003.

OBD is a self-checking function of engine management systems that determines whether there are excessive deviations in exhaust emissions [amongst other factors] by checking plausibility and correlation with other sensors. A check-engine warning usually alerts drivers of a problem with various sensors and actuators.

Emission checks can also be performed simply by reading stored error codes from OBD, specifically if the lambda sensor(s) [aka O2 sensor] functions correctly and if the catalytic converter is still converting sufficiently.

The simplified "check" is expected to reduce inspection costs to motorists; by some 70 to 80 German Marks according to DEKRA.

[Loose translation by Bernd from http://www.autouniversum.de, PGN-ed]

Regular RISKS readers might observe that there are would longer be any external checks to verify that the system is actually doing what it reports.

Bernd Felsche - Innovative Reckoning, Perth, Western Australia

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

Date: Mon, 4 Dec 2000 13:51:20 -0500 From: Adam Shostack <adam@zeroknowledge.com> Subject: High reliability

An article on a new center to study high reliability computing http://www0.mercurycenter.com/svtech/news/indepth/docs/nasa120300.htm contains this text:

> current practices in the semiconductor industry. Both are enormously > complex processes, but the semiconductor industry has figured out a > way to produce chips with relatively few errors -- at least in > comparison to the software industry, which typically has from 6 to > 30 errors per line of code.

Not to mention the journalism industry, with an error rate of 1 error per 6 to 30 bits when reporting technical information... :)

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

Date: Mon, 18 Dec 2000 23:49:48 -0800 From: Martin Minow <minow@pobox.com> Subject: Electrocution leads to more deaths

Two teenagers were electrocuted by "an energized streetlight." After the electrocution, the county ordered all streetlights extinguished until they could be rewired. Then, a man was struck and killed by a car while crossing the darkened street and a motorist killed in a two-car collision in the same area. [Summarized by Martin Minow, minow@pobox.com] <http://www.miamiherald.com/content/today/news/dade/digdocs/062954.htm>

Quoting from the article:

Some residents complained Sunday that the precautionary order by the county to turn off the 92 streetlights has made matters worse. Now passing motorists see only with the illumination from their headlights. ... It's unclear how long the maintenance work on the streetlights will take, Miami-Dade spokeswoman Rhonda Barnett said.

[When will they see the light in Miami-Dade? PGN]

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

Date: Sun, 10 Dec 2000 09:47:13 -0800 From: Steve Bellovin <smb@research.att.com> Subject: Spam as a denial of service attack?

According to the AP, Verizon was bombarded by millions of spam messages, slowing e-mail to its dial-up customers. Verizon believes that "it was a malicious attack".

--Steve Bellovin

[Doneel Edelson cited *InformationWeek*, 18-25 Dec 2000, page 37: <http://www.informationweek.com/817/verizon.htm> That article notes that 70,000 subscribers had delays up to several hours, and this was the *third* spam attack against Verizon in two weeks. PGN]

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

Date: Wed, 13 Dec 2000 10:52:10 -0600 (CST) From: "Lynda Ellis (LabMed)" <lynda@mail.ahc.umn.edu> Subject: Re: Seattle Hospital Hacked (RISKS-21.14)

Here's the response from the University of Washington, Health Sciences and Medical Affairs, News and Community Relations, 7 Dec 2000

The following statement is for attribution to Tom Martin, director and chief information officer for University of Washington Medical Centers Information Systems:

An Internet-based news service yesterday netcast a rumor that 'a hacker took command of large portions of the University of Washington Medical Centers internal network earlier this year.' Unfortunately, this rumor was reported as fact. However, it is completely inaccurate.

Last summer, we halted an unknown hacker who had gained criminal entry into portions of our academic computer system. This is the only incident we are aware of that bears any resemblance whatsoever to the report in yesterdays SecurityFocus News. While we have no evidence that confidential data were obtained as part of that incident, we do know for certain that no one has ever gained unauthorized entry into our separate and highly confidential patient-care computer systems.

The UW and most other universities make limited use of firewall technology and are under constant assault by recreational hackers. Recognizing this, we take extraordinary measures to protect our clinical-based systems that go well beyond the high security employed, for example, by most community hospitals. These measures include the latest hardware and software, encryption technologies, and strong host-based security.

As the incident we detected last summer illustrates, we are constantly vigilant for hacker attacks on all of our computer systems. We believe that rumors such as the one given credence in yesterdays netcast only encourage recreational hackers to pursue their criminal activity."

For more information, contact L.G. Blanchard or Walter Neary, 1-206-543-3620

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

Date: Fri, 15 Dec 2000 14:37:45 -0500 From: HIIP@Harvard.edu Subject: Computers, Freedom, and Privacy CFP2001 Call for Participation

CFP2001: The Eleventh Conference on Computers, Freedom and Privacy

Hyatt Regency Cambridge Cambridge, Massachusetts, USA March 6 - 9, 2001

CALL FOR PROPOSALS

The Program Committee of the Conference on Computers, Freedom, and Privacy (CFP2001) invites your participation and proposals for the eleventh annual CFP, which will be held at the Hyatt Regency in Cambridge, Massachusetts, USA, on March 6 - 9, 2001.

CFP2001 is sponsored by the Association for Computing Machinery (ACM).

CFP is the leading policy conference for exploring the impact of the Internet, computers and communications technologies on society. For more than a decade, CFP has anticipated the policy trends and issues and shaped the public debate on the future of privacy and freedom in the online world. Each year at CFP, key members of the technical, government, business, education, non-profit, legal, law enforcement, security, media and hacker/cracker communities gather together to address the cutting edge questions in computing, freedom and privacy. CFP themes are broad and forward-looking. CFP explores what will be, not what has been.

Since this CFP will be held in 2001, the theme is the future of computing, freedom and privacy, including the convergence of information and communication technologies with other advanced technology areas and the new challenges to freedom and privacy that they engender throughout the world. The Internet is a global phenomenon with significant local impacts. We encourage innovative and imaginative thinking on these topics and invite you to submit proposals for CFP2001 conference activities. Of particular interest are proposals on:

GOVERNANCE, including impact of the Internet on governance; impact of governance on the Internet; ICANN; voting; standards; antitrust and competition policy; new models for governance; and stakeholders in governance.

SOCIAL IMPACTS, such as the relationship between the individual and her communities.

INDIVIDUAL AUTONOMY AND INTEGRITY, particularly human rights; freedom of expression; censorship; free speech and access; freedom of association; freedom of movement; and exploration of the roles of non-identifiability, pseudonymity, and anonymity.

CONVERGENCE of information and communication technologies (ICT); of ICT and content; of ICT with other advanced technology areas, including biotechnology, biology and materials science; and related industry mergers, consolidations and activities.

DIGITAL DIVIDE in the face of the growth of the ubiquitous information environment; access to the network infrastructure; access to information; broadband policy; education policy; and related telecommunications, cable, intellectual property and freedom of information (FOIA) rules.

PRIVACY, including the growth and role of the chief privacy officer; privacy as the default; US legislation; international developments and trends; and an international privacy convention.

INTERNATIONAL ISSUES, especially the emerging issues of global privacy protection; international principles of human rights; security of information systems; intellectual property; objectionable content; cybercrime; jurisdiction; regulation; and legislation.

ELECTRONIC COMMERCE, including consumer protection; and the impact of payment systems, regulations, and technical standards on personal freedom and privacy.

We encourage proposals not only on these subjects, but also on the border areas between these topics, such as intellectual property protection and privacy.

We strongly encourage proposals that involve leading experts, innovators, policymakers, and thinkers.

CFP2001 PROPOSAL SUBMISSION GUIDELINES

Proposals should be submitted no later than January 5, 2001, via the CFP2001 website at http://www.cfp2001.org.

Proposals should include the following information:

1. PRESENTATION TITLE 2. PRESENTATION TYPE Plenary conference sessions (30 minutes to 1.5 hours) Lunch breakout sessions (1 hour) Tutorials (3 hours) BOFs ("birds of a feather" sessions) (no time limit) 3. PROPOSED LENGTH OF PRESENTATION 4. NAME(S) OF SPEAKER(S), PLUS BRIEF BACKGROUND DESCRIPTION FOR EACH SPEAKER 5. A BRIEF DESCRIPTION (no more than 100 words) OF THE TOPIC AND FORMAT, suitable for conference brochure and press release. 6. COMPLETE CONTACT INFORMATION (e-mail, phone, and mailing address). For presentations with more than one speaker, please include complete contact information for all the proposed speakers.

We encourage a variety of formats, including panels, debates, individual speeches or keynotes, interviews, role plays, reverse role plays, case studies, Socratic dialogues, etc.

DEADLINE FOR SUBMISSION OF PROPOSALS

All proposals must be received no later than January 5, 2001. Please follow the submission guidelines above.

PLEASE SUBMIT PROPOSALS AT HTTP://WWW.CFP2001.ORG.

For additional information about CFP2001, please visit the conference website at http://www.cfp2001org.

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

Date: 15 Aug 2000 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to <risks-request@csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact <risks-request@pica.army.mil> (Dennis Rears). .UK users should contact <Lindsay.Marshall@newcastle.ac.uk>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/info/textfiles/risks-digest/ . ==> PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks .

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

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