RISKS-LIST: Risks-Forum Digest Thursday 9 October 2003 Volume 22 : Issue 94 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 http://www.risks.org as http://catless.ncl.ac.uk/Risks/22.94.html The current issue can be found at http://www.csl.sri.com/users/risko/risks.txt Contents: [THANKS for including "notsp"!!! That helps ENORMOUSLY. PGN] Analysis of California recall data confirms voting system doubts (Rebecca Mercuri via PGN) Faulty wiring led to windshield cracks in 3 Boeing 777s (Monty Solomon) The Earth's not slowing down fast enough to suit Motorola (Paul Eggert) German toll system unusable (Debora Weber-Wulff) School district sued over WLAN planning (Monty Solomon) Risk of trusting computer-free security? (George Mannes) Telephone evidence vs. armed robbers (Roger Willcocks) New CD antipiracy mechanism disabled by shift key (Joshua Levy) Re: Parking chaos in York (Chris Barnabo) Re: A new approach to roller coasters (Lars-Henrik Eriksson) Franklin security/liberty quote (Duke Robillard) Re: Fun with stolen credit-card numbers (Dimitri Maziuk) Re: Unencrypted credit-card submission forms (Ben Scott) Getting over that fishbowl feeling: harvested data (Rick Smith) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 09 Oct 2003 07:10:04 -0400 From: "Peter G. Neumann" <neumann@private> Subject: Analysis of California recall data confirms voting system doubts (from Rebecca Mercuri) Following is based on information from Rebecca Mercuri. [The words are hers, not mine, lightly edited for RISKS.] Rebecca Mercuri has analyzed California's recall ballot data and reports that it confirms numerous doubts about election systems. Her results demonstrate that the style of voting system in use (punchcard, optically scanned, or touchscreen) cannot be generically considered either "good or bad". She asserts that the particular model of the system, as well as the procedural controls in place in each county, along with the ballot layout, may have considerably more impact on the reliability of the election results than the type of system deployed. The analysis revealed some shocking details. Of the 8,359,168 votes cast statewide, some 384,427 (nearly 4.6%) were not recorded for the recall question. Almost half of these missing votes (over 175,000) were in Los Angeles, nearly 9% for that county. Yet the Datavote punchcards used in 14 other counties fared somewhat better, on average, than all of the optically scanned and touchscreen systems, with the exception of only the ES&S Optech Eagle (used in San Francisco and San Mateo counties) and the Diebold Accu-Vote-TS (used in Alameda, though with some reports of equipment malfunctions). The Sequoia Edge touchscreens, currently under litigation in Riverside County, performed slightly worse than the Datavote punchcards. The ES&S iVotronic touchscreens were ranked lowest of the three touchscreen types in the state, and were outperformed by all other systems with the exception of the Sequoia Optech optically scanned systems and the Pollstar and Votomatic punchcards. In earlier court battles prior to the recall election, the ACLU claimed that voters using punchcards would be unfairly disenfranchised, as compared to voters using optically scanned or touchscreen systems. As it turns out, the counties using Datavote punchcards had residual vote rates that were better than all but one of the optically scanned systems, and also lower than two of the three touchscreen systems. At the other end of the scale, the counties using Pollstar and Votomatic punchcards (which included heavily-populated Los Angeles) had worse residual vote rates than any other type of voting system in use in the state. Clearly it is not the punchcards themselves that are to blame, since the Datavote systems demonstrate that punchcards can be used successfully. The residual vote technique was previously used by MIT/Caltech in their studies following the 2000 Presidential Election. For the California analysis, she performed her calculations by comparing the difference between the total number of ballots cast, as reported by California Secretary of State Kevin Shelley's office, with the total numbers of "yes" and "no" votes on the recall question. It should be noted that the residual vote tally is incapable of differentiating between a voter who deliberately or accidentally did not make a selection on the recall question, and an equipment failure (such as hanging chad) that could result in a cast vote not being counted. The rush to fully computerized ballot casting is misguided. Although supplemental technologies are needed for disabled voters, there is no clear evidence that touchscreen systems are substantially or consistently better for use by the general population than other voting methods. The fact that the touchscreens in California do not provide any way to perform an independent recount [and no real assurance that votes are even handled correctly in the absence of the voter-verified audit trail that Rebecca has long been recommending -- PGN] should make them less desirable than the paper-based systems that do have such capabilities. Counties, like San Francisco, that are doing well with optically scanned ballots, and the smaller ones that use punchcards effectively, should feel no pressure to modernize. For further information, contact Rebecca Mercuri via telephone at 1-609/895-1375 or 1-215/327-7105, email mercuri@private and Internet at http://www.notablesoftware.com/evote.html -- -- -- -- Supporting Data for California Recall Question, Rebecca Mercuri 7 Oct 2003 Numbers represent RESIDUAL VOTE RATE as percentage of total votes cast according to type or model of machine: Punchcard 6.24 Datavote 1.94 Pollstar 6.02 Votomatic 8.17 Optically Scanned 2.68 ES&S Eagle 1.87 Diebold Accu-Vote-OS 2.36 ES&S 550 and 560 2.42 Mark-A-Vote 3.04 Sequoia Optech 4.35 Touchscreen 1.49 Diebold Accu-Vote-TS 0.72 Sequoia Edge 2.01 ES&S iVotronic 3.49 Statewide 4.59 ------------------------------ Date: Mon, 6 Oct 2003 23:47:56 -0400 From: Monty Solomon <monty@private> Subject: Faulty wiring led to windshield cracks in 3 Boeing 777s Faulty wiring in a window heater caused the windshield to crack on a Boeing 777 during a flight from Rome to New York in July 2003, and at least two other Boeing 777s have experienced similar problems in the past year, the Associated Press has learned. All landed safely and no one was hurt. But experts say three similar incidents in one year is unusual for an aircraft. ... [Source: AP, 6 October 2003] http://finance.lycos.com/qc/news/story.aspx?story=35949554 [See also: 3 Windshields Cracked on Boeing 777s, Leslie Miller, Associated Press, 6 Oct 2003] http://finance.lycos.com/qc/news/story.aspx?story=35948868 ------------------------------ Date: Tue, 07 Oct 2003 23:33:45 -0700 From: Paul Eggert <eggert@private> Subject: The Earth's not slowing down fast enough to suit Motorola Motorola reports that several GPS receivers in its Oncore line will misdisplay the date on 28 Nov 2003 at midnight UTC. For a one-second window the receivers will mistakenly report the date as 29 Nov instead of 28 Nov. Here's why. Every couple of years or so for the past three decades, the International Earth Rotation Service has announced a leap-second because the Earth is rotating slightly more slowly than an 86400-second day would suggest. But since 1 Jan 1999, we've had an unusually long dry spell without any leap seconds. The GPS week number in the UTC correction parameter is 8 bits long, which allows for 256 weeks of unambiguous time calculation. Until now this parameter has never rolled over, but because of the dry spell 28 Nov will be exactly 256 weeks after the most recent leap second, and the rollover will contribute to the bug. <http://www.motorola.com/ies/GPS/docs_pdf/notification_oncore.pdf> Steve Allen writes in <http://www.ucolick.org/~sla/leapsecs/onlinebib.html> that some JDAM smart bombs and other munitions are rumored to contain these receivers. Anyone intending to use those weapons around the magic window might want to reschedule their bombing runs for some other time. ... ------------------------------ Date: Thu, 09 Oct 2003 20:25:05 +0200 From: Debora Weber-Wulff <weberwu@fhtw-berlin.de> Subject: German toll system unusable A German consortium called TollCollect, consisting of global players such as the Deutsche Telekom and DaimlerChrysler has been trying for some time to create a "modern toll collection system" using GPS, among other things. The German Government decided today to postpone the introduction of the system, at a cost of millions of Euros, because it doesn't work. It was to be fully automatic. Trucks (and only trucks were to pay the toll) were to have an OBU (On-Board Unit, and of course a different one than all the other countries using such devices. Some trucks would need 3-5 of the things, depending on the routes they take). The OBU is to have a GPS receiver and a mobile transmitter, so that when the truck is moving it's position can be determined. When the truck drives over highways that are not toll-free for trucks, the toll is to be calculated and sent by mobile transmitter to a central office, that bills the shipping company direct. Sounds simple, doesn't it? For this purpose, lots of new masts were erected (as if we don't already have enough of this nonsense in Germany), and a beta test was arranged. Shipping companies complained that they were charged toll, although they were using the non-toll road that ran near a toll road. [GPS tolerance miscalculated? Maybe the German mapmakers made some mistakes?]. Others reported happily that they were charged no toll, although they were using a toll road. Some truckers reported the OBU busting its circuit breakers when the ignition in the truck was started. The problem is, that no one knows what the cause for the problems is. Maybe it is the map update system, which updates the map in the OBU about 500-1000 times a month [that is around once an hour, or more, according to my calculations! - dww]. And of course, the OBUs can't be produced fast enough so that all the trucks that cross Germany have one by 1 Nov, the date (already moved before) the toll was to have gone into effect. Foreign truckers were to use a special system of 3500 terminals that are installed at truck stops throughout Germany. Or, toll could be paid in advance "by Internet". Reports are, that this doesn't work, either, and takes an enormous amount of time. The minister for transport, Manfred Stolpe, has often been asked why German didn't use a low-tech system like Austria (they sell little stickers called Vignettes) or Italy (they put people in toll booths at specific points on the highways). Stolpe says, he wanted a high-tech solution that would work for decades. Perhaps using a current mobile techonology and old-fashioned notions of high-tech was not really a great idea? Germany has now sunk over 730 Million Euros into the project. The toll of 12.4 (euro)cents per kilometer was to bring in 2.8 billion Euros a year into cash-strapped Germany, with the consortium raking in a fifth of the take. There has also been scandal from the get-go in 2001, where by amazing coincidence a German-led consortium won the bid, although other bidders could show that they had experience in actually building such a thing. And then the government gave them a special liability dispensation, so that the consortium doesn't have to pay a fine for missing the start date, which has been moved before. So here we have a fine mixture of mismanagement, high-tech woes and government games. The EU in Brussels is beginning to sniff into the affair, as it is beginning to smell like fish left on the counter for a week. At least it gives Germans something to complain about to take their minds off the unemployment figures! [German language articles:] http://www.tagesschau.de/thema/0,1186,OID2318248_REF1_NAVSPM1,00 Prof. Dr. Debora Weber-Wulff, FHTW Berlin, FB 4, Treskowallee 8, 10313 Berlin Tel: +49-30-5019-2320 http://www.f4.fhtw-berlin.de/people/weberwu/ ------------------------------ Date: Tue, 7 Oct 2003 01:38:16 -0400 From: Monty Solomon <monty@private> Subject: School district sued over WLAN planning A school district is sued in Illinois over planning a WLAN without addressing a group of parents' concerns over electromagnetic radiation's effects. http://wifinetnews.com/archives/002303.html ------------------------------ Date: Wed, 8 Oct 2003 21:08:02 -0400 From: George Mannes <George.Mannes@private> Subject: Risk of trusting computer-free security? A dog trainer was sentenced to 6 1/2 years in prison Monday for providing defective bomb-sniffing dogs to the government after the 11 Sep 2001 attacks and lying about their credentials. Russell Lee Ebersole, convicted in June 2003 on 27 counts of fraud, insisted his dogs were competent and blamed his conviction on jealous competitors. ... Ebersole's Detector Dogs Against Drugs and Explosives, of Stephenson, Va., provided bomb-sniffing dogs to several federal agencies in the months after the 9/11 attacks. The agencies paid Ebersole $700,000 from Sep 2001 to May 2002. Ebersole's contracts were canceled after his dogs failed independent tests on five different occasions. On one test, dogs were unable to detect 50 pounds of dynamite and 15 pounds of C-4 plastic explosives hidden at the Federal Reserve parking garage in Washington. [Source: Man Jailed for Faulty Bomb-Sniffing Dogs, By Matt Barakat, Associated Press 8 Sep 2003] http://www.newsday.com/news/nationworld/nation/wire/ sns-ap-dogs-cant-sniff,0,4930607.story?coll=sns-ap-nation-headlines After years of reading RISKS, I have become instinctively suspicious of all the things that can go wrong in security -- and other areas -- if one trusts a computer too much. But, as this story taught me, my wariness around computers creates a new Risk: the belief that excluding a computer from a particular situation makes that situation inherently less Risky. Before I read this, if someone had asked me what was more reliable -- a bomb-sniffing dog or a bomb-sniffing electronic device -- I'm sure I would have said the dog. What's more honest, sincere and trustworthy than a dog? Plus, from Risks I've learned that there's a huge difference between a shiny gadget's performance in a lab under controlled conditions in a lab and its performance out in the field under less orderly conditions. Unfortunately, it appears, dogs can be programmed just as poorly as computers are. - GM [But are the high-tech systems really better than the canine sniffers? Some of the system technologies seem to have "gone to the dogs". PGN] ------------------------------ Date: Wed, 8 Oct 2003 16:34:26 +0100 From: "Roger Willcocks" <roger@private> Subject: Telephone evidence vs. armed robbers 'A gang of armed robbers collected 1.4-million pounds (UK) as they targeted the wealthy across London. The gang took all the precautions to avoid detection. Cars were stolen, laid up for a few days to make sure they had not been fitted with tracking devices, and then used. The gang wore gloves in addition to masks and balaclavas. As a result police were left without forensic evidence. But those said to be involved reckoned without the ability of telecom experts to link their use of mobiles to the areas where the robberies took place. "Telephone evidence is at the heart of this case" [the prosecution] told the jury.' [Source: *The Times* (London), 8 Oct 2003 (abridged)] It's been noted previously how handy it is that 'bad people' willingly carry tracking devices. I hope the police already had suspects and used the phone evidence to back up their case. The risk is that they could trawl phone records for correlations and suspect anybody who happened to be in the wrong place(s) at the wrong time(s). ------------------------------ Date: Thu, 09 Oct 2003 11:34:09 -0700 From: Joshua Levy <levy@private> Subject: New CD antipiracy mechanism disabled by shift key A new and humorous approach to audio CD copy protection is based on the Windows feature that auto-runs code on CDs when they are inserted. A Princeton student has pointed out that the feature is disabled by holding down the shift key when inserting the disc. http://rss.com.com/2100-1025_3-5087875.html A satirical, but entirely too believable, take on this: Keyboard Manufacturers Named in DMCA Suit German-based media giant Bertelsmann Group has launched a 400 million dollar lawsuit against major hardware manufacturers, alleging they traffic in banned circumvention devices that can be used to illegally copy their music CDs. It says that the Digital Millennium Copyright Act entitles it to protection from devices that can be used to circumvent its technological protections against piracy. Specifically, it demands compensation for the inclusion of "Shift" buttons on standard computer keyboards. http://www.kuro5hin.org/story/2003/10/8/201119/758 ------------------------------ Date: Mon, 6 Oct 2003 19:53:37 -0400 From: "Chris Barnabo" <chris@private> Subject: Re: Parking chaos in York (RISKS-22.92) Hmmm, tough one ... how about a POWER SWITCH? For a flaky 1.5M pound system you'd think they could throw in a few toggle switches gratis. ["Switches would be the icing on a flaky 1.5M pound cake" ...] http://www.spagnet.com ------------------------------ Date: Thu, 9 Oct 2003 09:28:30 +0200 From: Lars-Henrik Eriksson <lhe@private> Subject: Re: A new approach to roller coasters (Baker, RISKS-22.89) I have actually tried this thing and it is not apparent that Windows is controlling the RoboCoasters. The programming is certainly done on a touch-screen PC, but the program is delivered to the visitor on a smart card. The smart card is then inserted into the RoboCoaster's control system, which looks like a traditional industrial process control system -- e.g. no screen, but lots of lights and buttons. To me this looks like a prudent way of separating the programming and control systems which have very different user interface and safety requirements. Lars-Henrik Eriksson, Computing Science, Dept. of Information Technology, Uppsala University, Sweden http://www.csd.uu.se/~lhe +46 18 471 10 57 ------------------------------ Date: Wed, 08 Oct 2003 10:40:35 -0400 From: Duke Robillard <duke@private> Subject: Franklin security/liberty quote (Re: Cronkite: The New Inquisition) Old Ben wasn't quite *that* radical. :-) What he actually wrote was They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety Historical Review of Pennsylvania, 1759 (although he used it earlier in a letter; cf. http://www.bartleby.com/100/245.1.html) I think the Ben's choice of words makes his meaning quite different than your's. In particular, Ben says they "deserve neither," not that they'll "have neither." He's making a value judgment, saying that "essential liberties" are intrinsically better than "temporary securities," and that people who disagree don't deserve either. You're saying that giving up liberty will mean you can't get security. That argument could be made, but Ben wasn't making it in this quote. Ben's original quote also gives the Patriot Act guys plenty of wiggle room, by using the phrases "essential liberty" and "temporary safety." Who's to judge "essential" and "temporary"? ------------------------------ Date: Wed, 8 Oct 2003 19:07:15 -0500 From: dmaziuk@private (Dimitri Maziuk) Subject: Re: Fun with stolen credit-card numbers (Kamens, RISKS-22.93) Jonathan Kamens: > Subject: Fun with stolen credit-card numbers (OP re-formatted) > There are some questions whose answers I do not know, and neither Amazon nor > American Express is telling. Did the perpetrator use my name? Did s/he > know my correct billing address? A bank generally doesn't care about these. You put card number and transaction amount into EFT terminal and get a response sometime later, that's all. Response is a success or error code. And they don't really care about expiry date, either: you get a different error code for expired card. The number uniquely identifies a current account (I don't know if they guarantee that numbers will never get re-used). It does not identify the actual card: my wife and I have credit cards with the same number. There's no such thing as billing address for credit cards -- as far as bank is concerned. It gets better: my wife kept her maiden name. She is currently working at one university while I am working at another, in a different state. She has a different billing and shipping addresses, in addition to different name -- and the same credit-card number. So the vendor has no a priori means of deciding if the same credit card number may or may not be used with different name and/or address(es). They have 2 choices: 1) block legitimate purchases and drive off potential customers. In other words, what's not explicitly allowed is forbidden (totalitarian). PayPal does that -- account owner has to add the other cardholder to the account before PayPal will let them pay for anything. Or 2) let the transaction through and notify the cardholder so they can decide whether the transaction was indeed fraudulent. IOW, what's not explicitly forbidden is allowed (democratic). Since credit card issuers will usually reverse fraudulent charges at your say-so, there's little harm to the customer. > Since I assume that the fraudulent purchase was shipped to an address other > than mine, why didn't Amazon require additional verification before shipping > over $500 of merchandise to an address other than the card's billing > address? Because some people may be buying presents for others and have them shipped directly to the recipient, for one thing. > Some things did not work so well. Why didn't Amazon stop the perpetrators > in real-time from making a purchase using a card already registered to > another account, as opposed to only detecting the situation after the fact? Probably because Amazon doesn't lose enough to fraudulent purchases, so they're more concerned with making customer's life easier. Otherwise they'd go for totalitarian option. Credit card issuers do the same thing. Credit cards weren't designed to be secure, that's where the problem really is. But nobody's rushing to fix the system (unless you count another little number printed on the same piece of plastic -- well, on some of them anyway -- as a fix). Presumably because that'd be more expensive than just reversing transactions whenever someone tells them to. ------------------------------ Date: Thu, 09 Oct 2003 11:50:41 -0700 From: Ben Scott Subject: Re: Unencrypted credit-card submission forms (Silverberg, RISKS-22.92) My soon-to-be former web hosting company (name omitted until I can migrate my sites away from them, but it rhymes with "LinuxWebToast dot com"...) has a billing page which invites you to submit credit-card info, unencrypted. When you click on a tiny link to "Access this page securely", a browser security warning pops up - the certificate shows a company name of "SnakeOil Ltd" (which I understand is a sample included with many webserver software packages for testing purposes), and it's been expired since October 2001! I only discovered this when I tried to change the credit card I've been using for years; the company has ignored repeated requests for an explanation, though they're pretty prompt about responding to any other query... ------------------------------ Date: Thu, 09 Oct 2003 08:51:12 -0500 From: Rick Smith <smith@private> Subject: Getting over that fishbowl feeling: harvested data I was at Black Hat last week during which Lance Spitzer talked about hacker community activities he's been seeing. One comment that really caught my interest was his claim that today's typical hacker is actually in it for the money: there's something to be gained by harvesting legal e-mail addresses to sell to spammers and by harvesting credit-card data. And I mean *harvest*. Individual addresses and numbers aren't worth much by themselves. Spitzer also claimed that at this point the financial community assumes that all relevant credit-card numbers and personal information for all their customers has probably been captured by someone in the hacker community. The only reason one person or another hasn't been hit is because there are more potential targets out there than the perpetrators have time to attack. A piece of evidence he presented to support this was a set of estimates of the street value of ID information: $1 for a valid card number, $5-10 for one with personal info to back it up (name, addr, etc), and $10-15 if it includes the CVV2 number from the back (amounts are quoted from my notes). In short, it's a "buyers market" for credit-card info. One plausible use of all these exploitable card numbers is a variant of "salami slicing:" you systematically remove a small, plausible amount of money from a victims' account. I've seen two instances on our accounts, one apparently for "AT&T" phone and one for a "Columbia House" club. The charges seemed plausible because my daughter was at school and had been given permission to pay for such things. Moreover, the legitimate charges appeared on different credit-card bills from the illegitimate ones. Charges looked plausible when looking at bills individually. We only tracked it down when we compared monthly expenses across all the bills. This is an example of why even three or four credit cards may be too many to own. The credit-card companies did a fairly thorough job of reversing the charges, but I suspect the losses are still too small to expect that anyone will go after the perpetrators. Rick Smith, University of St. Thomas/Cryptosmith, rick@private ------------------------------ Date: 30 May 2003 (LAST-MODIFIED) From: RISKS-request@private 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 e-mail requests to <risks-request@private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomo@private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .UK users should contact <Lindsay.Marshall@private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => 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@private with meaningful SUBJECT: line. *** NEW: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: http://www.sri.com/risks http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.94 ************************
This archive was generated by hypermail 2b30 : Thu Oct 09 2003 - 17:52:24 PDT