RISKS-LIST: Risks-Forum Digest Friday 7 May 2004 Volume 23 : Issue 36 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/23.36.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Computer glitch gives out free gasoline (Jack Christensen) U.S. blunders with China, Iran keyword blacklist (Declan McCullagh) Risks of prisoner abuse vs. digital cameras (Lauren Weinstein) Auto-Blacklisting is a bad idea (Drew Dean) Re: Computer glitch grounds Atlanta flights (Tron Smith) Corrupted virus definition load blocks re-load (George Michaelson) Antivirus software prolongs viral life (Matthias Heiler) Challenge/response standards (Brent Laminack) Aus vs. Swiss speeding (Ivan Reid) Re: ... lost revenue from faulty speed cameras (Anthony Youngman, Michael Smith, Bertrand Meyer) MDT and a Fatal accident: a possibility? (Nick Lindsley) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 5 May 2004 17:28:12 -0400 From: "Jack Christensen" <j.christensen@private> Subject: Computer glitch gives out free gasoline Some Michigan college students discovered that swiping their driver's license instead of a credit card in pay-at-the-pump gasoline pumps allowed them to fill up for "free." What they evidently didn't count on was that information from their driver's licenses, sufficient to trace them, was in fact read and stored by the system. The exact mechanism of the "glitch" isn't detailed, but there are at least a couple Risks here, including: (1) Insufficient testing/robustness, with regard to unexpected input, can lead to retail losses and/or expenses to recover the losses, and (2) Failure to understand that ignorance (in this case, of the workings of embedded systems, and of their failure modes,) is insufficient reason to assume a best-case scenario. I know nothing of the specific technology involved, but I'm at least a little surprised at the interchangeability of different types of cards. I would think one of the first checks would be to determine if you were reading a credit card, or something else that you didn't want to process (driver's license, video store card, etc.) Strictly from personal observation when using these pumps, there is usually some sort of authorization that happens before you can dispense gasoline. If this authorization fails, as I assume it would when given a driver's license, then I would not think the transaction should proceed. [Source: Associated Press item, 5 May 2004] http://story.news.yahoo.com/news?tmpl=story&cid=817&e=1&u=/ap/free_gas Jack Christensen j.christensen@private ------------------------------ Date: Mon, 3 May 2004 11:20:10 -0500 From: Declan McCullagh <declan@private> Subject: U.S. blunders with China, Iran keyword blacklist (Politech) Declan McCullagh: U.S. blunders with keyword blacklist, 3 May 2004 http://news.com.com/2010-1028-5204405.html The U.S. government concocted a brilliant plan a few years ago: Why not give Internet surfers in China and Iran the ability to bypass their nations' notoriously restrictive blocks on Web sites? Soon afterward, the U.S. International Broadcasting Bureau (IBB) invented a way to let people in China and Iran easily route around censorship by using a U.S.-based service to view banned sites such as BBC News, MIT and Amnesty International. But an independent report released Monday reveals that the U.S. government also censors what Chinese and Iranian citizens can see online. Technology used by the IBB, which puts out the Voice of America broadcasts, prevents them from visiting Web addresses that include a peculiar list of verboten keywords. The list includes "ass" (which inadvertently bans usembassy.state.gov), "breast" (breastcancer.com), "hot" (hotmail.com and hotels.com), "pic" (epic.noaa.gov) and "teen" (teens.drugabuse.gov). [...] Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ------------------------------ Date: Fri, 7 May 2004 08:23:31 -0700 (PDT) From: Lauren Weinstein <lauren@private> Subject: Risks of prisoner abuse vs. digital cameras Perhaps understandably lost in the furor over Iraqi prisoner abuse is the role that technology has played in moving this story from "footnote" to "international firestorm" status. Without a doubt, the digital camera has played a central role. It's these relatively inexpensive cameras, producing vast numbers of high-quality shots at essentially zero cost per photo, images that can be easily stored and e-mailed, that have inspired the visual recording of scenes that otherwise would have been reduced to dry, easily ignored, textual descriptions at the most. Note the brief, sterile, vacuous January press release from CENTCOM, that Rumsfeld is touting as proof that everyone was already informed about possible "detainee" abuse problems in Iraq: ( http://www.vortex.com/centcom-abuse-release.html ). Now contrast the stark, full-color realities of the photos, most from a massive digital archive obtained by *The Washington Post* (and subjected to "appropriate" cropping and blurring -- it's OK to show all manner of visual horrors to the public, but you don't want to offend them with naughty body parts). The photos *are* the story, and apparently there are lots more to come. President Bush says that such abuses are aberrations that don't reflect the true nature of our society. In the "Reality Reset" column referenced by ( http://neon.vortex.com/blog/lauren/archive/000051.html ) I question this premise, but without a doubt the digital camera and related technologies are creating a sea change, the effects of which we cannot even begin to realistically predict. Lauren Weinstein +1 (818) 225-2800 http://www.vortex.com http://www.pfir.org http://www.factsquad.org http://www.uriica.org ------------------------------ Date: Thu, 06 May 2004 12:49:28 -0700 (PDT) From: Drew Dean <ddean@private> Subject: Auto-Blacklisting is a bad idea I recently received a challenge from someone's challenge-response spam filter. Alas, I had not sent the original message. Unfortunately, said challenge-response system warned that it was going to automatically blacklist my e-mail address if I didn't respond. But I didn't want to respond, because the original message was either malware (most probably, see below) or spam. Milgram's famous "six degrees of separation" turns out to make auto-blacklisting a really bad idea: many types of e-mail-based malware propagate via random choices from the victim's address book. As it's an awfully small world, there's a good chance that someone knows two people with common interests, who may not have exchanged e-mail before. (Lots of people seem to have my old e-mail address in their address books, even though I've never heard from them, or sent them mail, other than indirectly via a mailing list (or USENET posting).) If auto-blacklisting challenge-responses systems become the norm, there will be interesting risks related to the combination of forged mail, and auto-blacklists: what happens if you follow the challenge-response protocol to avoid being on someone's blacklist (the only obvious option), and said person (e.g., your research sponsor) receives a highly inappropriate piece of mail nominally from you? Other denial of service attacks are also possible: seed your competitors (auto-)blacklists with the e-mail addresses of your (mutual) funding agency. I'm sure the clever will have even more ideas about risks here. Auto-whitelisting, by contrast, has none of these problems. Drew Dean, Computer Science Laboratory, SRI International ------------------------------ Date: Tue, 4 May 2004 19:47:14 -0700 (PDT) From: Tron Smith <ziggart57@private> Subject: Re: Computer glitch grounds Atlanta flights (RISKS-23.35) Talk within the airline industry has it that Delta's problems on 1 May 2004 were the result of systems not patched and hit by the Sasser.b virus. ------------------------------ Date: Fri, 7 May 2004 09:55:20 +1000 From: George Michaelson <ggm@private> Subject: Corrupted virus definition load blocks re-load The desktop virus scanner we use appears to update windows registry, or some other record of load, *before its verified the integrity* of the loaded virus definitions. And, it refuses to re-load them if its recorded them as loaded. We have just had at least one host which fell over during the virus load phase off the net, and then spend an hour or more trying to find where to remove on-disk data to allow a reload of the file. The risk here is pretty obvious: a virus could quite easily be written to corrupt the virus definition state in registry and prevent you from downloading the current patches to remove the virus... George Michaelson, APNIC, PO Box 2131 Milton QLD 4064 Australia ggm@private http://www.apnic.net Phone: +61 7 3858 3150 ------------------------------ Date: 05 May 2004 09:56:54 +0200 From: Matthias Heiler <surname@private> Subject: Antivirus software prolongs viral life (Kuenning, RISKS-23.35) > Clearly, the "System Restore" feature has not been carefully thought out! "System Restore" is a functionality of Windows XP, not of any Antivirus software. So the header should read "Windows XP prolongs viral life". ------------------------------ Date: Wed, 5 May 2004 21:05:32 -0400 From: Brent Laminack <ibrent@private> Subject: Challenge/response standards What is your favorite color? Blue.. No, Yellow! Aaaargh!! Security professionals are well aware of password restrictions. ISO 17799 says that passwords should be at least six characters in length and free of consecutive identical characters or all-numeric or all-alphabetical groups. (Section 9.3.1) There are a number of variations on the theme: requiring internal numerics, mixed upper and lower case, etc. Here is a recent encounter I had where an organization tried to apply such a rule to a non-password. I was signing up for on-line bill-payment from our local ILEC PSTN telephone provider. I chose my user name and password, and was asked to provide a question and answer to re-set my password. Such challenge/response systems are fairly common. I liked that I could choose my own question. Some systems have a small set of pre-defined questions that are, unfortunately, matters of public record "What is your mother's maiden name?", "In what city where you born?" etc. They suggested using a question like "What is your favorite color?" I decided that that particular information was not easily found in government databases so I entered it as the question. I then entered my favorite color as the answer. I submitted the form and got an error message saying that the answer had to be at least six characters. Odd. Let's see.. common colors of at least six characters: Blue? Red? Green? White? Black? Cyan? Beige? Aqua? Gray? Pink? Navy? Olive? Peach? Rose? Tan? Teal? Clearly they have disallowed a number of valid responses. I finally picked a compound color name (which really isn't my favorite color) and finished the registration process. What think ye? Is it proper to apply password standards to challenge/response responses, or are other criteria (such as: not a matter of public record) more valid? I've looked, but can find no body of work setting forth standards for challenge/response questions similar to those standards which govern password creation and use. Clearly, this should be addressed if such challenge/response dialogs are used to reset passwords. This because authentication by strong passwords is for naught if the password reset mechanism is weak or flawed. ------------------------------ Date: Wed, 5 May 2004 07:46:40 +0100 From: Ivan.Reid@private Subject: Aus vs. Swiss speeding (RISKS-23.35) > The country is proud of its strictness in enforcing speed rules, sometimes > fining motorists for driving one kilometer above the posted limit (however > absurd that sounds). That's a little ironic, given that I was twice fined in Switzerland for "injuring the speed laws" by riding 1 km/h too fast, after a 5 km/h tolerance (86 in an 80 and 56 in a 50; for completeness my other fine was for four over at 59 in a 50 -- each fine was CHF 20 [since tripled] but no points accrue in the Swiss system). Ivan Reid, Electronic & Computer Engineering, CMS Collaboration, Brunel University. Ivan.Reid@private Room 40-1-B12, CERN ------------------------------ Date: Wed, 5 May 2004 09:19:26 +0100 From: "Anthony Youngman" <Anthony.Youngman@eca-international.com> Subject: Re: ... lost revenue from faulty speed cameras (Meyer, RISKS-23.35) "Last year their accuracy was questioned after reports that a truck with a maximum speed of 140 km/h was caught traveling at 164 km/h, and other similar incidents." I don't know how failsafe the UK system is, but UK fixed cameras take a double image with a time interval of maybe a second. Coupled with markings on the road, it's possible to work out the distance covered between photos, and hence calculate the speed. I'm fairly certain that on several occasions this has been used to prove the camera was faulty. The only thing I don't know is how the time gap is proven -- hopefully the time is stamped on the photo based on the national Radio Time Signal. ------------------------------ Date: Wed, 05 May 2004 03:26 From: Michael Smith <emmenjay@private> Subject: Re: ... lost revenue from faulty speed cameras (Meyer, RISKS-23.35) > The country is proud of its strictness in enforcing speed > rules, sometimes fining motorists for driving one > kilometer above the posted limit (however absurd that sounds). That sounds like an extraordinary claim to me. I've lived in Australia all of my life (over 40 years) and I've never heard of a speeding ticket being given for one km/h over the limit. Speed cameras are normally calibrated for between seven and 12 km/h above the limit. As for "The country is proud of its strictness in enforcing speed rules", I'm not sure how you would define "the country". Most official sources attribute a significant proportion of road deaths to excessive speed. (e.g. http://www.rta.nsw.gov.au/roadsafety/speedandspeedcameras/) and such sources normally describe the anti-speeding initiatives as being successful in reducing the number of road deaths. However there is a quite vocal "pro speeding" group. I don't have data to estimate the group's size, but they get significant media attention. They claim that speed limit enforcement is merely "revenue raising" (which is presumed to be a bad thing) and that speeding has little effect on accident rates -- suggesting that road improvements and driver training are preferable ways of reducing the number of road deaths. Mr Meyer's comments on the faulty speed cameras are, sadly, all too accurate. However I would be interested to know his sources on the comments outlined above -- for they contradict my own personal experience. Michael J Smith <emmenjay@private> ------------------------------ Date: Wed, 5 May 2004 07:25:51 +0200 From: "Bertrand Meyer" <Bertrand.Meyer@private> Subject: Re: ... lost revenue from faulty speed cameras (Smith, RISKS-23.36) I have been a frequent visitor to Australia (the equivalent of a month and a half a year) for the past ten years and this may be the most dangerous stage, at which you start believing that you know enough about the place even if you're still basically a tourist. Both of the claims that Michael questions are based on numerous conversations with diverse people. The fear of being fined for going 1 KM/H over the limit is prevalent among my acquaintances; As to being "proud" of the policy this is a general impression, which may be biased by the kind of people I meet -- typically, urban professionals. This illustrates the risks of voicing generalities about "the country", whatever that country is. Fortunately the other points in my note are, as you observe, factual, not a matter of opinion or impression. ------------------------------ Date: Fri, 7 May 2004 00:10:50 -0400 From: "Nick Lindsley" <nicklindsley@private> Subject: MDT and a Fatal accident: a possibility? ---------- Original Message ------------- From: fist <fist@private> Reply-To: fist@private Date: Fri, 07 May 2004 11:04:39 +1000 >Nick, One suggestion would be to send a short version of this to the Risks >Digest, asking if anyone had seen similar reports and pointing out the >dangers of drivers not watching the road I find this digest has some of the >most intelligent IT people around, and it might generate enough commentary >to give you something more to send along to the authorities. On 8 Sep >2002, Wayne Duncan (a colleague of mine) rolled his taxi with fatal >results on Airport Drive, Brisbane. It was unwitnessed and skid marks >indicated that he had swerved, possibly to avoid something in his way. For sometime before and after this accident, I had considered the possibility that using and reading the on-board computer system could contribute to an accident. It had nearly happened to me, looking up just in time to avoid a pedestrian. Wayne was not a bad driver, not always within the speed limit, but not outlandishly beyond it either. Black and White's taxi computer system is supplied by and maintained online by Raywood Communication of Melbourne, and works in conjunction with a GPS in the taxi which transmits its position (latitude and longtitude) and other relevant data to the cab base. I figured that if I knew the position of the crash by driving to the accident site and using my own GPS, I could perhaps find out if it coincided with the last transmission from Wayne's taxi, proving at least the possibility that he had been using the on-board computer close to the time of his death. After perhaps three months I visited Const Kelly Donahue at Boondall Police Centre, who was investigating the cause of the crash. I explained how we physically worked the on-board computer, roughly measured time with eyes off the road, reaction time, distance traveled therein and so on. As stated previously, Wayne's accident was unwitnessed. As luck -- if that's the word -- would have it, the first person on the scene was a doctor who declared him dead at 20:44. He probably had been killed instantly. Constable Donahue had a report from Black and White purporting to have come from Wayne's taxi timed at 20:40 (about 4 minutes before he was found dead), and printed shortly after the accident (I am not sure when or by whom). At that time, according to the report, Wayne had indicated his preferred work area as Eagle Farm and other details. Most interesting for me was the latitude and longtitude. I was looking for something close to 27deg 23.6mins South and 153deg 06.8mins East (about 300 to 400 metres before the tall control tower on the way to the Domestic Airport), roughly the site of the accident and marked nowadays by two small white crosses in the median section. Everything appeared to be in order EXCEPT for the latitude and longtitude. This indicated a position 1400 kms to the SW, near Melbourne, approximately 38 deg South and 145 deg East. When I pointed this out to Const Donahue she had no explanation. In fact she had been unaware that the report contained the current position of the taxi when it transmitted details at 20:40 even though she had been in possession of the report for some months. Now this could be seen as another simple computer glitch. Having an IT background and having spent many years using GPSs for navigating boats, I find this extremely unlikely. After all, everything else transmitted from the taxi to the cab base at 20:40 appeared correctly, so why not the latitude and longtitude? Const. Donahue had no explanation. Now over one year later I am still without an explanation. I have repeatedly asked the police, the coroner, offered my own experience, just to be basically ignored. I have even had the Freedom of Information act mentioned. Recently Constable Donahue phoned me from Landsborough, her new posting, to tell me that the coroner has decided not to have an inquest into the accident. I may not in fact have a right to know exactly what the reason for the false latitude and longtitude on the report was. My main concern is that the police and/or coroner are acting on the advice of B&W and Raywood Communications who obviously have an invested interest in a non controversial outcome. Additionally, if the position in the report was wrong, has the real position been saved? And was it close to the accident site? UPDATE SINCE THE ABOVE WAS WRITTEN There will be no inquest and I have received copies of the police report and witness statements. The following is a copy I have just sent to the Deputy Coroner here in Brisbane: C A Clements Deputy State Coroner 179 North Quay Brisbane 4000 Your Ref#COR 472/02 30 April 2004 Dear Mr/Ms Clements Thank you for sending me some of the details concerning the fatal accident to Clifford Wayne Duncan at Airport Drive, Brisbane Airport on the 8 September 2002. As you are probably aware, I knew Duncan on a passing basis and I was curious why a driver with his experience would suddenly swerve to the right through about 170 degrees, initiating a roll that killed him when his taxi collided with a steel pole. I had considered the possibility that his on-board computer (and back lit at the time 2041hrs) had distracted his eyes a moment too long, and when he looked up he desperately -- and suddenly -- swerved to avoid something in his lane (possibly a fox or another car). Unfortunately too late. Having read the reports and witness statements that you sent me, I am still unconvinced that the on-board computer was not a contributory factor in the accident. I noticed towards the end of Report Number 02/22444, Senior Constable Donohue recommended (and I quote from page 11): ``1. that Queensland Transport conduct a safety audit into the feasibility of taxi drivers operating the MDT safely whilst the vehicle is in motion. The operation of the MDT whilst the vehicle is moving may be akin to the use of mobile phones.'' It is the only recommendation that she makes. On page 9 of the same report she mentions in further information 1(b): ``I visually observed each of the drivers to take their attention from the road ahead for a period of at least 2 seconds at a time. Furthermore, conversations with the Black and White taxi drivers suggested that they are all of the opinion it is a safety risk, as monitoring requires the driver to take his/her eyes away from the road ahead, relying on peripheral vision. This risk was particularly enhanced during nighttime hours, as the illumination of the MDT was distracting when trying to refocus ahead. They all likened the operation of a MDT to a mobile phone.'' The Statement of Witness Greg Whitney (Service manager for Raywood Communications at the time of the accident) contains an analysis of how the GPS/On-board MDT work. Page 4 of that witness' statement contains the following: ``I have an MDT and radios fitted to my vehicle for testing purposes. I admit that in times past, I have been accessing the data screens whilst driving. When I have looked up, I have been surprised at how far I have traveled and admit that if a car was slowing down or stopped in front of me, or a pedestrian was to walk in front of my vehicle, my ability to stop safely may have been compromised.'' Coming from the manufacturers themselves, this is rather significant. Mr Whitney also mentions a software engineer with Raywood called Karl Leake (now based in North Sydney). On the report given to the police, the current location of Duncan is given in and around Melbourne (an error offset 1400km south west of the actual position). I discussed this matter with Mr Leake and Mr Whitney today and it appears that this ``error'' is well known and deliberate and used for their ``own internal purposes''. Neither could explain why this known error would be maintained in software that had been in use for some years with B&W Brisbane. Interestingly, Mr Leake told me that the actual correct position would have stayed on B&W hard disk as the ``error'' is only induced by the report generator. In theory the correct position should still be on B&W's computer system unless it has been deleted. Considering the severity of the accident, one can only hope that it hasn't been deleted as it will show quite conclusively where the Wayne Duncan was at 2041 hrs on the day he died -- and, more importantly, if he was closing in on the accident site ( 27 23.6South 153 06.8East). He would probably been looking at the screen just after his final transmission at 20:40:09 hrs to check the stats. I do not know if you felt a need for an independent technical witness (unrelated to the companies involved) but, considering the importance of the matter (it could happen again, if it happened at all) why will there be no inquest? Is it because you feel that there is absolutely no chance that the on-board MDT computer system contributed to the accident, and if so, where is the evidence for that side of the argument? Additionally, I would like to request copies of the following: Data Printout for B&W Taxi #682 for the 8 Sept 2002 Data Printout for Statistics for B&W taxi #682 for 1 Sept 2002 thru to (and including) 8 Sept 2002. Yours Sincerely Nick Lindsley Thank God for cut and paste. I have been around all the state govt houses -- police, transport, justice and, it seems, I am going around in circles. I am not 100% exactly how the driver was killed, but I do think the subject needs further attention. Interestingly, I belong to a Yahoo discussion group (Oz Cabs) and I put a post on this issue about a year ago to try an engender some interest in the matter. Yesterday the moderator -- a David Gawthorn (Melbourne) -- e-mailed to say that someone in Qld had called him to "moderate" my posts on this particular subject ("moderate" in this context means censor) quite a few months ago. I also cannot find my original posting. If you find this interesting, please contact me on 0418-727.727 Australia ------------------------------ Date: 5 Apr 2004 (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> The full info file may 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: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i] <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you 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/> . ==> 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 23.36 ************************
This archive was generated by hypermail 2b30 : Fri May 07 2004 - 15:24:34 PDT