Text File

precedence: bulk Subject: Risks Digest 21.13

RISKS-LIST: Risks-Forum Digest Sunday 3 December 2000 Volume 21 : Issue 13

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.13.html> and by anonymous ftp at ftp.sri.com, cd risks .

Contents: Perspective on election processes (PGN) A better election process? (Dave Stringer-Calvert) Australian Internet cable severed (Dave Farber) CIA secret chat room investigated (PGN) McAfee VirusScan update crashes Windows (PGN) Ticking time bomb in buffer overflow (Jonathan Hayward) Re: The end of the Multics era (Tom Van Vleck) I am glad about the quality of my driver's license photo (Joel Garry) Re: Engine cutouts (Paul Nowak) REVIEW: "Practical Firewalls", Terry William Ogletree (Rob Slade) Abridged info on RISKS (comp.risks)

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

Date: Sun, 3 Dec 2000 9:59:37 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: Perspective on election processes

We have long noted in this forum and before that in the ACM Software Engineering Notes (which I created in 1976 and edited for 19 years, until succeeded by Will Tracz -- who has carried on the tradition) that there are very serious actual and potential problems in computer-related elections. The current issue of *The New Yorker* (4 Dec 2000) begins with The Talk of the Town section by considering the current mess: ``But it is not as if we were without warning.'' The article notes the series of writings of David Burnham in *The New York Times* in 1985 and Ronnie Dugger's long article in *The New Yorker* issue dated 7 Nov 1988. The article notes that Dugger's 1988 article quotes Willis Ware, who has long been a wise observer:

There is probably a Chernobyl or a Three Mile Island waiting to happen in some election, just as a Richter 8 earthquake is waiting to happen in California.

Many people have been asleep at the wheel for too long. See the Election material on my Web site http://www.csl.sri.com/neumann for pointers to some of the collected RISKS-historical material, especially the Illustrative Risks section on Election Problems, a document in which I have long cited Burnham's articles from *The NY Times*, 29 and 30 Jul, 4 and 21 Aug, and 18 Dec 1985. (I have already noted the 14% undervote for the Senate race in Florida in 1988.) What we are experiencing now is not a new problem. Unfortunately, it had not previously reached Chernobyl-like proportions or surfaced in a close presidential election. Nevertheless, the process that is currently before us is finally forcing an examination of many of the relevant issues. I hope that some of the more basic deeper issues will not be ignored in trying to resolve the immediate issues. The time has come for a serious reassessment of the entire process.

Apologies for the long gap since the appearance of RISKS-21.12 on 11 Nov 2000. We have received an enormous amount of e-mail on this topic, although some of it has been superseded by events, and some of it is too politically motivated to include here. There are so many issues at the moment, such as chad slots that have not been cleaned in many years, the causes of dimpled punched cards, absentee ballot irregularities, the desirability of manual recounts in Florida and New Mexico and elsewhere, etc., that we cannot begin to enumerate them here. On the other hand, objectivity would seem to be extremely desirable at this time.

Let me offer just a few suggestions:

* In the UK, Canada, France, Germany, and many other places, ballots for national elections consist of a single piece of paper with one candidate to be selected for one office. This is an extremely reliable process, is counted very quickly in a highly distributed fashion, and seldom challenged. Perhaps in the U.S., elections for the President should be considered a Federal function and conducted by a one-issue paper ballot, with all other election issues run by local jurisdiction in their own way, as is the case at present. Even in such a simple paper ballot, the challenges of avoiding fraud and accidents are significant, but by no means unsolvable. The reliability can indeed be greater than in all of the alternatives.

* If ballots are to be recorded and counted electronically, some sort of nonforgeable, nonalterable, and nonbypassable audit record must exist to make electronic tampering and accidents infeasible. Of course, voter privacy also needs to be honored. No existing electronic systems have anything close to what might be considered adequate, and the election system developers (with proprietary closed-source code) do not seem eager to take the extra miles needed for greater integrity. Claims of integrity are not backed up by standard practice of secure systems (which itself is extraordinarily weak), and no one seems to be applying even the relatively minimal standards of the Generally Accepted System Security Principles http://web.mit.edu/security/www/gassp1.html or reasonable certification processes.

* Voting by the Internet, even if only from well established polling places, is and will remain extraordinarily risky because of the inherent untrustworthiness of computer systems attached to the Internet and indeed the networking itself. It should not be recommended for use in the foreseeable future.

* Fraud and accidents must be anticipated throughout the election process. Election systems must be designed, implemented, and operated as systems in the large, and the human interfaces (for voters, administrators, maintenance personnel, etc.) must be considered as integral parts of the system. Any system should have live checking for invalid ballots. This existed decades ago in lever machines, and is common in electronic systems. If punched cards survive after 2000, card systems could easily include a single precinct display device that checks for overvoted or otherwise invalid ballots and for undervoted ballots before they are deposited.

* I previously noted the doctoral thesis work of Rebecca Mercuri. She has devoted an entire dissertation to the topic of election system integrity, and particularly the conflicts inherent with process integrity and voter ballot privacy. The thesis takes a broad system approach to voting security/integrity/reliability, and is in fact relevant in a much broader context. Highly recommended. For information, see her Web site: http://www.seas.upenn.edu/~mercuri/evote.html Rebecca also considers a proposal for an auditable paper trail of each electronic ballot that is verified by each voter before leaving and automatically deposited in a tamperproof receptacle. This is still not enough, but is worth considering as one more integrity measure. (For example, voters should not be allowed to photograph that record, because of the requirement that votes must not be salable, for example based on paper evidence of how you voted!)

Many wags have cited the aphorism that perfection is the enemy of the good. In election systems, there will never be perfection. But the existing state of the art is the enemy of sanity, and a rush to all-electronic voting is utter madness -- even though it may appeal to advocates of conceptual simplicity. It is by no means an easy path, if all of the desired requirements of the voting process are to be satisfied. And there is an enormous gap between the concept and an implementation that provides any real assurances.

[weak week typo fixed PGN]

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

Date: Fri, 01 Dec 2000 13:39:28 -0800 From: Dave Stringer-Calvert <dave_sc@csl.sri.com> Subject: A better election process?

If the election is not decided by the beginning of April 2001, then next time let's take inspiration from the lottery -- lottery `turn out' is much higher than in elections, and there is already a large investment in the necessary infrastructure at your local 7-11 to handle it.

Pay to vote. Pay $1 to cast a vote (we suggest voting early, and often). Note that, for the lazy voter, the machines already have a `random pick' function, if you have difficulty deciding on a candidate for yourself.

The collected monies are placed in a large fund which is either:

a) distributed to the `winners' of the election (winner := people who voted for the winning candidate);

b) distributed to the `losers' (loser := NOT winner), to compensate them for living under an administration they did not choose;

Of course, this would imply a tracking system in order to distribute the `prize fund', violating the principles of anonymity of voting. So let's turn this upside down and offer a more effective use of campaign funds -- pay the voters who turn out, say $5 each. They could use this to play the `real' lottery, and perhaps by voting next year, you could win enough to run for presidential office in 2004...

Dave (who doesn't have the right to vote anywhere, but can still play the lottery)

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

Date: Tue, 21 Nov 2000 21:05:35 -0500 From: Dave Farber <farber@cis.upenn.edu> Subject: Australian Internet cable severed

[PGN-ed from Dave Farber's IP.]

Australia's largest international Internet cable was severed on 20 Nov 2000 <http://www.it.fairfax.com.au/breaking/20001121/A25-2000Nov21.html>, partially disrupting Internet traffic in Singapore, Indonesia and Australia. The cable, carries about 60 percent of Australian ISP Telstra's international Web traffic. While Telstra has since managed to <http://www0.mercurycenter.com/svtech/news/breaking/merc/docs/026478.htm> redirect most of its Internet traffic to another undersea cable, bringing its Internet services back to around 75 percent of capacity, its not yet been able to determine how long it will take for Internet traffic across the cable to return to normal.

[For Dave's archives and subscription information, see http://www.interesting-people.org/ . PGN]

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

Date: Mon, 13 Nov 2000 08:16:29 -0500 From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: CIA secret chat room investigated

Following onto but totally unrelated to the John Deutch saga (RISKS-20.78), the CIA has uncovered a secret chat room within its classified confines ``to trade off-color jokes, musings, and observations that went undetected for more than five years'' -- involving about 160 employees.

[Source: URL: http://www.zdnet.com/zdnn/stories/news/0,4586,2652732,00.html, CIA secret chat room investigated, Tabassum Zakaria, Reuters, 12 Nov 2000, initially reported by *The Washington Post* on 12 Nov 2000. PGN-ed]

[Typo in 20.78 fixed in archive copy. PGN]

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

Date: Sun, 3 Dec 2000 10:11:16 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: McAfee VirusScan update crashes Windows

Windows 95, 98, and NT all seem to have crashed under McAfee virus definition file version version 4.0.4102. It includes a driver that actually imitates the virus. Network Associates recommended starting in Safe Mode and disabling VirusScan's startup scan.

[Only 4102 versions? Be sure to subscribe to the virus-a-day club.]

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

Date: Wed, 22 Nov 2000 14:27:19 -0600 From: Jonathan Hayward <jshayward@pobox.com> Subject: Ticking time bomb in buffer overflow

A couple of months ago, a buffer overflow vulnerability was discovered in Outlook Express that allows arbitrary code to be executed when the user downloads messages with mauled date headers.

MicroSoft has released a patch that many people consider a cure worse than the disease. They still have yet to release a patch that users won't curse.

The Morris Internet worm hit the Internet at a time when there was no money to be made on it by insider trading.

Am I the only one to see a time bomb here?

-Jonathan

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

Date: Sun, 12 Nov 2000 11:06:30 -0500 From: Tom Van Vleck <thvv@multicians.org> Subject: Re: The end of the Multics era

Multics's ideas and approach to problem solving continue to be relevant. Those who had the privilege to work with the system and its team remember the experience fondly and apply its many lessons to new challenges. As I have written elsewhere, "as long as we have Multicians, we have the best part of Multics." Let's all use what we learned, and do some more work we can be proud of.

Incidentally, the 9 goals are in "Multics -- the First Seven Years" by Corbato/Clingen/Saltzer, 1972 FJCC, available on the Multicians website, http://www.multicians.org/f7y.html

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

Date: Sat, 11 Nov 2000 14:02:05 -0500 From: Joel Garry <joel_garry@compuserve.com> Subject: I am glad about the quality of my driver's license photo

The following is a paragraph from an article on www.uniontrib.com entitled "Convention for chiefs of police displays crime-fighting tools," about The International Association of Chiefs of Police having their convention in San Diego:

Also on display will be the RangeFinder, a facial recognition system that is supposed to be able to scan everyone from people seated in cars to those standing at a public gathering and automatically identify them from data in government computer files. It is touted as capable of making allowances for changes in appearance of the people it scans, such as through aging, hairstyle alteration and weight gain or loss, said Mike Maloney, a spokesman for NEC.

Unfortunately NEC doesn't seem to have posted details of this yet on the website I checked (http://www.nectech.com, which does have details about a fingerprint device mentioned in the article). However, it seems to me there would be a risk of extrapolation error, as well as pattern matching variance issues. Beyond that, the differential between what humans perceive and what a technological device observes has already proved challenging to the legal system, and there is certainly a risk of believing the computer over people, as well as criminals modifying their behavior to fool the technology. I can't help but wonder how much of this technology relies on "image enhancement," where the algorithms employed may even have a net effect of supporting discredited theories of physiognomy.

http://ourworld.compuserve.com/homepages/joel_garry

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

Date: Fri, 1 Dec 2000 18:01:16 -0700 From: Paul Nowak - SUPCRTX <pnowak@superiorcourt.maricopa.gov> Subject: Re: Engine cutouts (Colburn, RISKS-21.10)

I got a kick out of this one having done the same thing with my 1990 Nissan 300zx when I first purchased it. My girlfriend lived in Pittsburgh, and between there and DC was a stretch of road that got over a steep ridge by means of a traverse. This naturally left little room for the Bear to set up and was the perfect place to test out my new wheels. I was carefully watching tach and speed so I would know the capabilities and handling of the car. Unfortunately I was unaware that there was an engine cutout and thought I had blown my engine. I just coasted down (I know how to drive with the power assist gone...just keep the key at "ON" to avoid the little difficulty of the steering column lock) and *very* tentively re-started.

The real risk is not advertising *all* the safety features.

Paul(N)

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

Date: Mon, 20 Nov 2000 14:56:51 -0800 From: Rob Slade <rslade@sprint.ca> Subject: REVIEW: "Practical Firewalls", Terry William Ogletree

BKPRCFRW.RVW 20000823

"Practical Firewalls", Terry William Ogletree, 2000, 0-7897-2416-2, U$34.99/C$52.95/UK#25.50 %A Terry William Ogletree ogletree@bellsouth.net two@twoinc.com %C 201 W. 103rd Street, Indianapolis, IN 46290 %D 2000 %G 0-7897-2416-2 %I Macmillan Computer Publishing (MCP) %O U$34.99/C$52.95/UK#25.50 800-858-7674 www.mcp.com info@mcp.com %P 491 p. %T "Practical Firewalls"

Unfortunately, not much of this book is really practical. And a lot of it is not about firewalls, either.

Part one presents the fundamentals of understanding firewalls and security. Chapter one looks at firewall basics, mentioning many topics but doing a poor job of explanation. Since the material is very generic there is almost no detail. The TCP/IP content, in chapter two, is also quite vague, with lots of irrelevant details like DNS (Domain Name Service) record fieldnames, but little related to security, and that of low quality. Security and the Internet gives a general listing of threats, most not related to firewalls, in chapter three. Chapter four has some good discussion of some aspects of policy and design, but it is limited. There are rough outlines of firewalls structures, but the material on pros and cons is poor. (As the book progresses there are increasing amounts of repetitious text, as this chapter amply demonstrates.) The review of packet filtering, in chapter five, has some good points, but too much of the text relies on "one size fits all" pronouncements. Again, there is a lot of irrelevant detail on TCP/IP headers and not much on, say, filtering rules. Because a bastion host is very highly secured itself, chapter six is merely general security material, touching on too many operating systems for good coverage. Some good points but limited scope makes the proxy server topic weak in chapter seven. Chapter eight does slightly better on auditing, by limiting itself to UNIX and Windows NT.

Part two looks at encryption, the relationship of which to firewalls is problematic. Chapter nine does not really cover encryption technology, being simply a set of definitions of basic terms. Since a Virtual Private Network (VPN) is defined, in chapter ten, in terms of tunneling, the material is necessarily restricted to that subsection of the field. Chapter eleven does not really tell the reader how to use PGP (the Pretty Good Privacy encryption program) but only deals with some aspects of installation.

Part three touches on installation and configuration of a number of products. Chapter twelve lists a number of firewall related tools, for UNIX, that are available on the Internet. "Lists" is definitely the operative word: so little information is given about the programs that chapters thirteen through sixteen cover basic installation and components of TCP Wrappers, TIS (Trusted Information Systems) Firewall Toolkit, SOCKS, and SQUID. ipfwadm and ipchains (for Linux) are described in chapter seventeen. Turning to Windows NT, chapter eighteen recounts the installation of Microsoft Proxy Server and nineteen does the same with the Elron CommandView firewall. Firewall appliances, or standalone units are promoted in chapter twenty. Chapter twenty one closes off with the same kind of vague generalities given in part one.

The most valuable part of this book is part three: even though the material is very limited, it is, at least, of some practical use. Most of the other content is of questionable accuracy or completeness, and therefore restricted in practicality. As noted, large sections of the text aren't even about firewalls. This book definitely does not compare with the classics like Cheswick and Bellovin's "Firewalls and Internet Security" (cf. BKFRINSC.RVW) or Chapman and Zwicky's "Building Internet Firewalls" (cf. BKBUINFI.RVW): a few suggestions about installation of specific programs does not make up for a lack of explanation of fundamental concepts, attacks, and defensive strategies.

copyright Robert M. Slade, 2000 BKPRCFRW.RVW 20000823 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade

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

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/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.13 ************************