RISKS-LIST: Risks-Forum Digest Friday 10 August 2001 Volume 21 : Issue 59 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.59.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Laser eye surgery (Henry Baker) "You Can't Hide Those Lying Eyes in Tampa" (Adam Shostack) The Internet park bench (Richard Jay Solomon via Dave Farber) PDF backward compatibility failures (Marc Auslander) A lucrative fiasco (Brian Randell) Risks of automatic verification (Geoff Kuenning) Possibility of a Warhol Worm: Complete infection in 15 minutes! (Nicholas C. Weaver) Adobe clarification on spyware article (Gunar Penikis) Danish police: Safeguard Easy not broken; passwords were weak (Bo Elkjaer) Re: OT: rot13, practical uses of (Rich Wales) Re: Georgia scholarship info exposed (Phil Kos) Re: Freeware app to retrieve passwords from Internet Explorer (Marc Roessler) Mutual authentication - not! (Michael Bacon) Re: What is your area code, really? ((Declan McCullagh) Is your phone bill private? Think again... (Ted Lee) Re: Firefighter's phone lines disrupted ... SMS hoax (Stanislav Meduna) Caller ID "hack" not a hack at all (William Kucharski) ANI is NOT Caller ID (Danny Burstein) DoCoMo thttpd is not all.net thttpd (Fred Cohen) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 09 Aug 2001 13:52:21 -0700 From: Henry Baker <hbaker1at_private> Subject: Laser eye surgery Someone close to me had laser eye surgery to correct significant near-sightedness two days ago. The surgery apparently went very well, but as I watched the procedure being performed, I was horrified to see two things: * the use of Windows as the major interface for this system (www.ladarvision.com), both for the output of the real-time video of the eye, both the tracked and the untracked views, as well as for the entry and display of the parameters. Based on my personal experience with Windows (I reboot on the average of 3-4X per day), I find it almost inconceivable that someone would trust their eyesight to such a software disaster area. I wasn't aware that _anyone_ had done any source checking of the Windows system to make sure that the numbers typed in were properly interpreted in all cases. Furthermore, even if someone had done such a check, it is inconceivable that such checks would remain valid for more than one version of the software. (Getting input routines correct isn't easy -- I'm aware of popular software systems (non-Windows) that still contained the same input conversion bugs after almost ten years and 5 versions.) * during the entry of parameters, the technician quickly "clicked away"/dismissed a number of error windows of the form "parameter out of bounds" -- seemingly on almost every number entered. When error windows of this type pop up so frequently and are routinely dismissed, it is like crying "wolf" -- eventually, no one listens even when there is a really bad problem. I was, however, very impressed with the quality of the eye-tracking system, which keeps the laser locked onto the pupil for upwards of 2.5 minutes, with _no_ noticeable jitter (I would estimate that the jitter was well under a single pixel out of an image probably 640 pixels wide). ------------------------------ Date: Wed, 8 Aug 2001 13:03:34 -0400 From: Adam Shostack <adamat_private> Subject: "You Can't Hide Those Lying Eyes in Tampa" http://www.sptimes.com/News/080801/TampaBay/_They_made_me_feel_li.shtml is the story of Rob Milliron, whose picture, captured from Ybor city surveillance cameras, was published in US News and World Report. A woman in Tulsa saw his picture and (incorrectly) identifying him as her ex-husband, called the police. Many of the risks are generally familiar, issues like mis-identification. Worth asking is why didn't they choose the picture of a criminal who was actually caught? Perhaps because the system does not function as advertised? ------------------------------ Date: Fri, 10 Aug 2001 13:35:01 -0400 From: Richard Jay Solomon <rsolomonat_private> Subject: The Internet park bench (From Dave Farber's IP list) >http://news.bbc.co.uk/hi/english/sci/tech/newsid_1481000/1481783.stm Thursday, 9 August, 2001, 13:44 GMT 14:44 UK Bad start for Internet bench: The teenagers took advantage of the free service Two teenagers discovered the world's first Internet bench could be used to make free international telephone calls. The cyber-seat, which is based in a public park in Suffolk, UK, went online on Monday. Neil Woodman and Dan Sanderson, both 17, took a normal telephone handset along to the bench, which was created by Microsoft's MSN service in partnership with the local council. The pair cheekily phoned St Edmondsbury Council to warn them of the problem and then tried to call Microsoft boss, Bill Gates. ------------------------------ Date: 10 Aug 2001 16:50:56 -0400 From: Marc Auslander <marcat_private> Subject: PDF backward compatibility failures I can't read my Vanguard statements (back to 1998) with Acrobat 5.0. In looking at the Adobe site, this is not the only backward compatibility failure reported. So what has become a defacto document storage standard may in fact leave us with documents we can't read! Marc Auslander <marcat_private> 914 945-4346 (Tieline 862 Fax x4425) ------------------------------ Date: Thu, 9 Aug 2001 22:28:45 +0100 From: Brian Randell <Brian.Randellat_private> Subject: A lucrative fiasco Magistrates courts staff are having to work with two computers on their desks instead of one after being presented with new PCs which do not have the software to do the main job they were bought for. In the latest in a long line of government IT humiliations, the Lord Chancellor's Department is pressing ahead with the installation of new computers in 400 magistrates courts even though delivery of the core application, a new case management system, has been indefinitely delayed. The result is that staff still rely on their old computers - installed 10 years ago - to access the casework system, while using the new PCs only for basic functions such as word processing and e-mail. An investigation by *Computer Weekly* has established that by installing the computers, the contractor ICL is now entitled to be paid more than half the contract's 319,000,000 pounds value, despite its failure to deliver the core application. [Source: Court staff hit by IT fiasco; software snag hits magistrates computer project, Stuart Millar, (UK) *The Guardian*, 9 Aug 2001] Full story at http://www.guardian.co.uk/internetnews/story/0,7369,534162,00.html Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK +44 191 222 7923 http://www.cs.ncl.ac.uk/~brian.randell/ ------------------------------ Date: Tue, 7 Aug 2001 17:24:17 -0700 From: Geoff Kuenning <geoffat_private> Subject: Risks of automatic verification In the past year or so, a lot of e-shopping sites have installed fraud-prevention software that attempts to verify that you aren't using a stolen credit card. These systems generally operate by comparing the billing address for the card with an address provided by the shopper or with the shipping address for the merchandise. These systems have caused me endless headaches, because my billing address is a P.O. box in a different state. For some reason, the automated verification system insists on rejecting me with a message indicating that my information doesn't match what's in my bank's records -- despite the fact that I have spoken with the bank to make sure that it is the same. On more than one occasion, I have been forced to resort to telephone calls to get my transaction to go through. But my favorite was when one site gave me a reject message, so I retried with a slight variation on the address. After a second reject, I got on the phone and straightened it out (without any particular verification requirement, I might add). That evening, the bank called to ask why I had three charges from the same Web site... The RISK: programmers who assume that everyone runs their lives the same way the programmer does. There's an incompetent-programmer RISK here too, but what else is new? Geoff Kuenning geoffat_private http://www.cs.hmc.edu/~geoff/ ------------------------------ Date: Thu, 9 Aug 2001 15:11:50 -0700 (PDT) From: "Nicholas C. Weaver" <nweaverat_private> Subject: Possibility of a Warhol Worm: Complete infection in 15 minutes! Michael Constant and I have performed a basic analysis of a possible worst-case virulence for an active worm like Code Red. By simply changing the infection strategy, a "Warhol Worm" could be developed, able to infect all vulnerable machines in 15 minutes from the moment of initial infection of a single machine! http://www.cs.berkeley.edu/~nweaver/warhol.html Nicholas Weaver, nweaverat_private [And in Case you have not heard, Code Red III is now operating. PGN] http://news.cnet.com/news/0-1003-200-6835996.html ------------------------------ Date: Thu, 9 Aug 2001 13:24:49 -0700 From: "Gunar Penikis" <gpenikisat_private> Subject: Adobe clarification on spyware article (Maggard, RISKS-21.56) This is in response to Michael F. Maggard's posting in RISKS-21.56. I would like to clarify some misconceptions and misinformation that was posted regarding Adobe applications "phoning home". The component in question is AOM, Adobe Online Manager which is included in most Adobe applications. 1. AOM does not scan your computer for registration and product information. AOM runs concurrently with most applications, it's purpose is NOT to scan for registration and product information and phone home to Adobe. Registration information such as serial number, product name is ONLY sent from the product when the user selects the Registration menu item in the product. This launches the default browser to the registration web page that has product and registration information pre-filled as a convenience (so the customer doesn't have to find the product box, etc.) The serial number is obfuscated in this transaction to protect our customers and Adobe from piracy. Alternatively, customers can print out a registration form, use the registration card, or register via the Adobe.com and type in the product information manually. 2. AOM only sends registration information when you select Online Registration As I mentioned above, we only send registration information when the user clicks the Registration menu in the product. It is never sent at any other time or with any other interaction. 3. Removing any components is NOT recommended. We highly suggest NOT removing AOM or other files since these components are critical to functionality of the connectivity, collaboration and support features of the product. As part of the regular updates to the products, we are investigating eliminating the dependency of AOM. In the meanwhile, we suggest that users of older products update their version of AOM by selecting Adobe Online and clicking the refresh or update button. Newer product should select the Downloadables or Updates menu item to check for product updates. What is AOM used for anyway? AOM stand for Adobe Online Manager. It is core component that coordinates the online interaction between Adobe products. When customers request updated information from within Adobe products by selecting Adobe Online or Updates/Downloadables, AOM processes these requests so that collisions do not occur and the appropriate information is displayed to the user. I hope this helps clarify some of the concerns your readers have encountered. Gunar Penikis, Product Manager, Adobe Systems ------------------------------ Date: Thu, 9 Aug 2001 22:18:57 +0200 (CEST) From: Bo Elkjaer <booat_private> Subject: Danish police: Safeguard Easy not broken; weak passwords (R 21 58) This is to elaborate and correct the initial mentioning of Safeguard Easy in RISKS-21.58. It was reported in national media - including tv - that the police had successfully broken the encryption. This, it seems, is not the case. The police have managed to find the passwords of the five encrypted computers. The information concerning the successful decryption of the five computers protected with Safeguard Easy was presented in court by chief prosecutor Poul Gade. Investigation is lead by chief of police in Holstebro, Jens Kaasgaard. I have just interviewed Jens Kaasgaard. He says: 'To avoid misunderstandings, we haven't broken Safeguard by technically breaking down the encryption. We have located the passwords in different ways. We have done it like any hacker would have done, by trying to figure out the most probable passwords. This has payed success in five cases.' 'After doing that we entered the document-parts, the harddisk of the computer. Here we found some of the files unencrypted and other files further encrypted.' 'When you use Safeguard you put a sort of shell around your data. This is the first part you need to enter. This is what is claimed to be impossible. It is impossible. We have had six private companies looking at this, and they have all failed.' 'We have used completely ordinary police investigation methods. We know precisely who have had access to the encrypted machines. Then we can start assessing probabilities and calculate upon this and set up models for how, if you were a hacker, you'd find your way into the machines. That's what we have done.' You did this yourself? 'Yes. We did this inside the police system.' To conclude: Be careful when you choose your password. Bo Elkjaer ------------------------------ Date: Thu, 9 Aug 2001 17:06:52 -0700 (PDT) From: Rich Wales <richwat_private> Subject: Re: OT: rot13, practical uses of (Manfre, RISKS-21.58) Let's not forget, of course, that when the US Army decided to get serious about enforcing a "no encryption software" policy on the SIMTEL20 archive back in 1990, one of the programs that was kicked off the site was ... you guessed it ... a ROT13 utility. Rich Wales richwat_private http://www.webcom.com/richw/ ------------------------------ Date: Thu, 9 Aug 2001 14:45:08 -0700 From: Phil Kos <PhilKat_private> Subject: Re: Georgia scholarship info exposed (Slatkin, RISKS-21.58) > the security file was wiped out, exposing other files. I think I would be a bit ticked off if my IT people decided that one of my web servers should automatically be "cleaned" of not-recently-used files, but let's not let that distract us from the real issue. Rachel hopes that the "security file" was .htaccess. While I can't disagree, I think that it misses the point. Frankly, even .htaccess is not sufficient to protect passwords stored in plain text on an unsecured web server. This is the real problem here. Storing passwords in plain text is an even better-known bad idea than using unchecked buffers on the stack frame, and I hope the person responsible for this piece of phenomenally bad design gets the blame due them. ------------------------------ Date: Wed, 8 Aug 2001 17:45:08 +0200 From: Marc Roessler <marcat_private> Subject: Re: Freeware app to retrieve passwords from Internet Explorer Now this is interesting. I remember seeing something similar about three or four years ago, named "Snadboy Revelation" back then, worked fine with win95. I had expected MS to make this more difficult after seeing such a tool.. The RISKs of using password remembering functions are well known, but making revelation of passwords that easy borders the laughable. Of course, displaying an asterisk for each character of the password is another RISK in itself since it leaks information on the length of the password.. Standard UNIX login does not echo anything at the Password prompt for a reason.. Marc Roessler ------------------------------ Date: Tue, 7 Aug 2001 18:58:38 +0100 From: "Michael (Streaky) Bacon" <streaky_baconat_private> Subject: Mutual authentication - not! I recently received a telephone call from the fraud department at my bank. I had recently been using a card that I don't normally use and they were just checking that it was still in my possession. The fraud department asked me to identify myself by giving them my date of birth and 'secret code' that I had supplied years beforehand. They told me what the question was, so I remembered the answer. I declined, and asked them to positively identify themselves to me before I would give them the information. "But we only need to confirm it, I have it on my screen", the lady said. "OK, you tell me what it is and if I agree that's what I told you then I've authenticated you", said I - knowing that it should fail, but hoping that it wouldn't. "Then you can authenticate me." After much discussion and calling two supervisors, we agreed that they would tell me the last two purchases I had made on that card (approximately 1 hour and 20 minutes beforehand respectively from two different stores). If they could, then they were probably from the bank, and I would authenticate myself to them. All three people I spoke to said that, "No-one has ever asked us to identify ourselves!" The RISKS are clear. You supply some 'secret' data to the bank so that they can authenticate you when you call them. But there is no simple way to authenticate the bank when it calls you. You can't ask for the number and call them back, because you have no way of authenticating the number given. They're ex-directory, so you can't confirm it through Enquiries, and they withhold the number so the CLI doesn't show! If you blindly supply the data (as clearly many people do), then you may be divulging to a crook the 'secrets' necessary to authenticate yourself to the bank. The bank has not thought to provide any means of authenticating themselves. I suspect this to be endemic. Oh, and when I asked what would happen if I refused to authenticate myself -- they said that my card would be suspended "As a precaution." So at least I would know then that it had been the bank I hung up on! Streaky ------------------------------ Date: Tue, 07 Aug 2001 21:35:02 -0400 From: Declan McCullagh <declanat_private> Subject: Re: What is your area code, really? ((Koenig, RISKS-21.57) > Five minutes later, two police officers showed up at my door, saying > that they had received a 911 (emergency) call from my home. I had a similar problem this week. I was visiting my parents and helping my mother configure a PC that was last used on a university campus. The PC was still configured for the old area code, and that combined with the "9" prefix that was required to connect to an off-campus dialup gave a dial prefix of "911". (That's the police emergency number, for non-U.S. readers.) Without knowing how to change the default location -- not a trivial task for a Windows novice -- a person using the computer would have had to edit the dial string every time they tried to connect. Eventually, no doubt, someone would have neglected to do so with results similar to what Andrew experienced. The risks here are obvious. Unfortunately the obvious fix -- a prompt saying "Do you really wish to dial 911 and call police?" if the location is in the U.S. -- might come as a mild surprise if the user is connecting via an unusual PBX system that may require a "911" prefix. Declan ------------------------------ Date: Tue, 7 Aug 2001 15:03:02 -0500 From: TED_LEEat_private Subject: Is your phone bill private? Think again... I suppose this has already shown up and I missed it, but we'll see. I just called ATT's customer service line with a question about my bill. (I don't recall how many menus deep I had to go to get the answer, and even though it was too many, that's not my point.) Somewhere in the process I was asked if I was calling from the number I was calling about and since I wasn't (I was at work) I was then asked to enter the number -- and immediately it came back with a statement about what my bill was and when I'd paid the last one. I have to wonder what other information I might have been able to get without having to authenticate myself in any way. Ted Lee, Minnetonka, MN ------------------------------ Date: Fri, 10 Aug 2001 08:06:33 +0200 From: Stanislav Meduna <stanoat_private> Subject: Re: Firefighter's phone lines disrupted ... SMS hoax (RISKS-21.55) > The cause was a hoax SMS spreading in the network of one of the GSM > operators stating that it is possible to make free calls using this > number. Slowly the details of the case have emerged and - not surprisingly - revealed another common risk - a risk of not assessing the effects of a software change, even if it is fixing a simple bug. There really _was_ the possibility to make free calls. Let zzz be the emergency number. If you called zzz, the call was properly routed. If you called zzzyyyyyy, a software bug caused zzz to be stripped and the call was routed to yyyyyy instead. Charging software looks at the beginning of the number and have seen an emergency number, so such call was not billed. Then the operator fixed the bug and the fix was analogous to plain old telephone - ignore remaining digits. Suddenly, all of such calls ended at the firefighters. So we are back to software development basics: specify handling of an invalid input, test the handling and think before you make a fix public. The fix was good enough for the billing department, but caused massive problems somewhere else. ------------------------------ Date: Mon, 23 Jul 2001 22:52:16 -0600 From: "William Kucharski" <kucharskat_private> Subject: Caller ID "hack" not a hack at all (RISKS-21.51) In Risks 21.51, Alexandre Pechtchanski wrote of receiving a phone call with "hacked" Caller ID information. In fact, it is likely no such "hack" occurred, nor is a hack necessary. Caller ID, (actually CNID, Calling Number ID), is based on data that is sent on trunk lines along with other SS7 signalling data in a phone system. For home users, this information is normally the originating phone number for the call, as that is how your local telco has their switches set up. Things are a bit different for PBX (Private Branch Exchange) systems, typically found in businesses. They feed directly into telco trunk lines, and the systems are responsible for feeding their own CNID information into the telephone network. Most newer PBXs can be programmed to either send along the originating phone number of a call or to send a single pre-programmed piece of information. As an example, a company may want the same information sent (say the company name and their main incoming phone number) on all outgoing lines so those receiving calls from the company see the company name and number rather than the number corresponding to the actual outgoing phone line used to place the call. This is all perfectly OK, as CNID data is not and was never designed to be secure, and is not used for anything but caller ID services. In Alexandre's case, it's likely a telemarketer either just programmed a nonsense number into their PBX, or perhaps their PBX came preprogrammed from the vendor with a "sample" phone number in place (e.g. "John Doe (212) 555-1212".) Note that there is a completely different system, ANI (Automatic Number Identification), that is used when it is important a caller be properly identified. It is ANI information that is used to generate phone billing records and to provide calling number identification for 911 services. (For the security conscious, ANI information is also NOT blockable, and most phone companies offer real-time ANI to their toll-free customers. This means that even if you have "Caller ID blocking," if you call a company using their toll-free number, they will have your phone number pop up on their screen when the phone rings on their end or will receive it in their end-of-month statement. This has been ruled fair, as THEY are paying for the phone call, thus they have a right to know who is calling them.) The real RISK here is trusting a system that was never designed to be even remotely secure as a source of accurate information as to the identity of a caller... William Kucharski <kucharskat_private> ------------------------------ Date: Tue, 7 Aug 2001 21:03:13 -0400 (EDT) From: danny burstein <dannybat_private> Subject: ANI is NOT Caller ID (Re: Green, RISKS-21.57) This brings up the reminder that Caller Name/Number ID (CNID) is NOT the same thing as Automatic Name/Number Identification (ANI). The former, which is what is used by (the vast majority of) homes and "regular" (non "800") business lines, can be blocked by the caller on either a permanent per-line basis, or as a choice per-call. (Usually by prepending a special code, generally "*70", before dialing out). The latter, which is in use internally by the telcos and by businesses with (so-called) toll-free (1-800/888/877/866, and soon 855) numbers, can NOT be blocked by the caller. Adding in the blocking prepend will NOT have any effect. So... whenever you reach out to a tollfree number, the recipient of that call *will* get your phone number. Which, of course, lets them kick it through a database for all sorts of other purposes. Sometimes, as in this case, namely credit card receipt verification, a perfectly valid and legitimate one. The RISK: having just enough knowledge (about blocking CNID) to believe you're keeping info (your phone number) private when no such thing is happening. ------------------------------ Date: Fri, 10 Aug 2001 07:23:10 -0700 (PDT) From: Fred Cohen <fcat_private> Subject: DoCoMo thttpd is not all.net thttpd (Re: Poskanzer, RISKS-21.58) It should be noted that this is not the 'thttpd' from all.net that provides secure Web services... Fred Cohen Fred Cohen & Associates.........tel/fax:925-454-0171 fcat_private The University of New Haven.....http://www.unhca.com/ http://all.net/ Sandia National Laboratories....tel:925-294-2087 ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-requestat_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-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . [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. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => 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 risksat_private 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]. Lindsay Marshall 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 21.59 ************************
This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 19:37:40 PDT