precedence: bulk Subject: Risks Digest 21.56 RISKS-LIST: Risks-Forum Digest Thursday 2 August 2001 Volume 21 : Issue 56 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 and by anonymous ftp at ftp.sri.com, cd risks . Contents: NASA data from 1970s lost due to "forgotten" file format (Aaron Dickey) Motorola Stock Drops 99.95%! (Daniel Norton) JDS Uniphase quarterly results hacked? NO! (Dave Isaacs) Freeware app to retrieve passwords from Internet Explorer (Lyle H. Gray) Totally Hip with spyware (Michael F. Maggard) Medical records via e-mail (William Colburn) AS IF: draft-ietf-dnsext-ad-is-secure-03.txt (John Gilmore) Microsoft's PGP keys don't verify (Brian McWilliams) Telling all to the police (Norm deCarteret) Identity theft (Jack Holleran) Risks of profanity filtering (Paul Bissex) Car-door lock remote control activates another car's alarm (Mark Brader) S-not-SL (Mike Albaugh) Re: MSN security upgrade forces new e-mail address (Robert J. Woodhead) No Appleplexy needed (Dave Stringer-Calvert) Re: Autoresponder goes haywire (Richard Johnson) Re: Erroneous air navigation reading (Mike James) Re: Polarized sunglasses and LCD frustration (Chris J Dixon) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat, 28 Jul 2001 23:31:43 -0700 (PDT) From: Aaron Dickey Subject: NASA data from 1970s lost due to "forgotten" file format In 1999, USC neurobiologist Joseph Miller asked NASA to check some old data the Viking probes had sent back from Mars in the mid-1970s. Miller wanted to find out whether certain information on gas released by Martian soil, which at the time had been dismissed as meaningless "chemical activity," was actually evidence of microbial life. NASA found the tapes he requested, but they didn't find any way to read them. It turns out that the data, despite being only about 25 years old, was in a format NASA had long since forgotten about. Or, as Miller puts it, "The programmers who knew it had died." Luckily, Miller has been able to cobble together about a third of the data and get some useful results, but only because some form of printed record had been saved. (And yes, he does believe the Viking probes turned up evidence of microbes.) Source: Reuters. Original article is available, at least temporarily, at , , , or . ------------------------------ Date: Thu, 02 Aug 2001 10:17:06 -0400 From: Daniel Norton Subject: Motorola Stock Drops 99.95%! My Yahoo! alerts window popped up with an explosive sound this morning to notify me that Motorola's stock (MOT NYSE) value crashed. Incredulous, I went to the Yahoo! Finance page and confirmed it. Undaunted, I proceeded to the NY Times finance site which only concurred. Finally the NYSE site confirmed that, in fact, the value of MOT had been exactly one penny (US$0.01) at the open, but rebounded spectacularly, even to exceed the previous day's close! (cf. http://www.danielnorton.net/mot.gif ) Hopefully, anyone who automates trading programs around this kind of glitch (It _was_ a glitch, wasn't it?), but we RISKs readers know that such hopes aren't always fulfilled. Daniel Norton ------------------------------ Date: Mon, 30 Jul 2001 09:39:49 -0400 From: Dave Isaacs Subject: JDS Uniphase quarterly results hacked? NO! I saw this interesting aside in an *Ottawa Citizen* article (27 Jul 2001) about JDS Uniphase's latest quarterly results: "The world's largest maker of fibre optic components was forced to halt the trading of its stock for most of the afternoon yesterday because a hacker broke into its corporate network and stole a draft copy of the company's fourth-quarter results. It had been released before the markets closed yesterday afternoon." The article is at http://www.ottawacitizen.com/business/010727/5066222.html The obvious risk here is the consequences of storing very valuable information unencrypted on a network-accessible computer. Nothing new in that lesson. What would be interesting is knowing is *how* JDS Uniphase knew that this break-in had occurred, and what form the break-in took. It sounded like a story we'd all be interested in hearing. A further article, from the *Globe & Mail* (28 Jul 2001), with the rather convoluted URL of http://rtnews.globetechnology.com/servlet/RTGAMArticleHTMLTemplate/C,C/20010 728/wfhack?tf=RT/fullstory_Tech.html&cf=globetechnology/tech-config-neutral& slug=wfhack&date=20010728&archive=RTGAM&site=Technology contains more details. Apparently, there was no 'hacker' or 'break-in'. JDS had placed the release on their Web site. A sharp-eyed surfer noticed that if you type in the exact file name, up pop the results. I suspect that a document-naming convention was apparent from looking at previous financial results. As to how JSU found out about the 'break-in': the 'hacker' phoned them up and told them. Dave Isaacs [JDS apparently reported a $51 billion loss for the year ending 30 Jun 2001, and 16,000 jobs lost. PGN] ------------------------------ Date: Mon, 23 Jul 2001 22:24:15 -0400 (EDT) From: "Lyle H. Gray" Subject: Freeware app to retrieve passwords from Internet Explorer The following item appeared in the "Download This" section of the Earthlink Weekly Email Newsletter on 07/23/2001: * Windows: Password Recovery http://www.iopus.com/password_recovery.htm If you tell your browser to save Web site passwords so that you don't have to reenter them, you might forget those passwords over time. This program can reveal the passwords hidden behind those asterisks in Web site login screens. (Freeware) This item highlights an inherent risk of allowing IE to save your passwords (other than the obvious one that anyone with physical access to your system would also have access to your password-protected pages): Someone with access to your system may be able to determine a pattern to your password choices (especially if you only have one password...) [and also to use your IE passwords directly while masquerading... PGN] ------------------------------ Date: Tue, 31 Jul 2001 17:32:24 -0400 From: "Michael F. Maggard" Subject: Totally hip with spyware Recently it was discovered that the Mac software "Livestage Pro" by Totally Hip software has been reporting back its license, usage, and environment to its manufacturer via a covert http dialogue. The company has refused to respond to the discovery "officially", but one of their staff members has been corresponding publicly on the popular Mac website at http://www.macintouch.com/spyware.html. There he's expressed surprise that anyone is concerned and asserts his business has the full right to include this sort of tracking, that it is noted deep in one of the readme files and permission to "electronically verify their serial number " is specified within the software license. The non-representative goes on to state that in the future Totally Hip intends to somehow secure the collected information and this is all simply a legitimate anti-piracy effort. Finally he's taken the Web site to task for posting letters that detail how to block the reporting function (edit one's hosts file), likens it to supporting software piracy and closes with "Honestly we are not an evil conspiring company." This isn't an isolated incident for Mac software developers; powerhouse Adobe has been installing a mysterious file of their own that regularly "calls home" for reasons unknown. Adobe has promised to explain this new feature, what it does and what it is communicating but to date have not followed through. ------------------------------ Date: Mon, 30 Jul 2001 15:31:52 -0600 From: "Schlake ( William Colburn )" Subject: Medical records via e-mail I live in a small town. Two of the doctors I visit have been my doctors my entire life, and the third in the office has been a friend of the family just as long. The office has been run virtually the same my entire life (they still have the original monochrome monitors on their office PCs). The newest doctor, however, demanded some new-fangled ideas as part of her contract to work there. She makes recordings of her medical notes and they are transcribed by a third party company. The transcriptions come via e-mail (which the office can't receive) in MS word 2000 (which the office can't read), so she gets them at her house and prints them out. She is out of town for three weeks now, and they asked me to take care of this for them. I don't know if my experience is typical of the medical transcription business, but I suspect that it is. The transcriptions are made at the office from the doctor reading her notes onto tape. I didn't ask, but I suspect that the tape is then mailed or shipped to the transcription agency. The employee there then types up the information and e-mails it back out to the "appropriate place". The e-mail is not (cryptographically) signed, nor is it encrypted. In the case of my local office, it goes from the ISP of the person doing the work to a local ISP here in Socorro. The doctor has a wireless link from her house to the ISP and uses an unencrypted POP session. The transcripts are then launched from outlook into word, and printed out. She saves a local copy onto her hard disk (just in case) and deletes them from the server. These documents can contain a lot of information. A medical history will include tremendous personal data on not just the patient, but on their entire family, including date of birth and lifestyle. A simple office visit can be mundanely bland (a broken wrist) to life-shatteringly personal (someone here was inspired by "Bobbit"), but always contains the persons real name, complaint, diagnoses, and prescription. There are numerous places along the trip that this information could fall into the wrong hands. A virus could be present at either end of the e-mail which might compromise data. The data passes through ISPs in the clear, and could be intercepted or modified while in transit. The wireless ISP is like a scrolling marquee if someone has the right equipment. Outlook likes to "keep e-mail on the server" even if the user has deleted it, so all those transcripts could still be on the local ISP. And lastly, a copy of everything is stored on her computer in her house and not in the security of the office. I often tell people that I have "no delusions of privacy" in our modern world. It keeps me sane. ------------------------------ Date: Sat, 28 Jul 2001 12:16:53 -0700 From: John Gilmore Subject: AS IF: draft-ietf-dnsext-ad-is-secure-03.txt I think some of you guys have gotten so tied up in micromanaging DNS Security implementation details that you forgot what swamp we were trying to drain. There is no point in building a cryptographically-secured DNS in which many of the machines will be configured to "just believe whatever they are told, regardless of the cryptographic signatures"! We already have such a DNS -- today's. It doesn't need signatures or AD bits or big packets or any other changes. Anyone who is happy with that can go home and stop arguing. The rest of us are interested in the real security and integrity of the Internet. Any client implementation that listens to a single bit of the response to tell it whether the response is cryptographically valid must be considered noncompliant with the DNSSEC spec. It's just an old fashioned insecure DNS client. There's nothing wrong with that, as long as you don't have any high trust expections for it. Any server which deposits a single bit in the response to claim to clients that it has cryptographically validated the results, so they don't have to, is just encouraging the above abuse. I'm not shocked to find people advocating that such a server actually lie to the clients about whether it has validated the data. The entire model (trusting a packet to tell you whether somebody else has validated the data) provides ample opportunities for not only your friends but your enemies to lie to you. Just like in the current DNS. John PS: I know, I know, the "valid" bit will be secured by some "out of band" means. Like a shared static key, and/or by the security of the file system on the server. Right. For extra credit: composing several weak security primitives produces what? Strong security or weak security? PPS: The real question is why anyone is advocating that the DNS be "secured" by lame security. There are challenges aplenty even when you're working with strong primitives; trying to mix in weak stuff is just wasting everyone's time. People have encouraged me in the past to assume the possibility of mere incompetence rather than assuming actual malice (e.g. when the FBI's Louis Freeh testified to Congress about the security of DES). So: Were any of you on the standards committees for cellphone privacy? How about on the 802.11 "Wiretap Equivalent Privacy" committee? Did any of you have a hand in shortening the key in DES? Perhaps you designed the encryption scheme used in DVDs or in Adobe eBooks? Whether you're incompetent or malicious, stick to breaking codes, it's much easier. Especially when you break them in the standards committee before they're deployed. ------------------------------ Date: Thu, 26 Jul 2001 15:33:10 -0400 From: Brian McWilliams Subject: Microsoft's PGP keys don't verify [From Dave Farber's IP, archived at http://www.interesting-people.org/ Submitted by Ben Laurie, who commented that As the immortal phrase has it, "the RISKS are obvious." PGN] FYI ... Microsoft Bulletins Fail PGP Verification http://www.newsbytes.com/news/01/168397.html For at least four months, Microsoft has been sending out security bulletins which fail a popular e-mail authentication system. As a result, the company could be opening the door to counterfeit bulletins from malicious hackers. To protect against forgery, Microsoft's security response center digitally signs its bulletins with PGP before e-mailing them to subscribers of its security notification service. But since at least March, if recipients attempt to verify the messages' authenticity, PGP will issue a warning that the bulletins contain an invalid signature. "The problem is that Microsoft's bulletins effectively look as if they're forged. And telling a Microsoft forgery from someone else's is virtually impossible," said Paul Murphy, head of information technology at Gemini Genomics, a genetic research firm in Cambridge, England. [...] ------------------------------ Date: Fri, 27 Jul 2001 18:06:01 -0400 From: Norm Subject: Telling all to the police *The New York Times* reports (27 Jul 2001) on 17 Jul theft from 9 lockers at an upper East Side sports club. Directly after they called the police a call was received from "the police fraud department" and 4 victims responded to a series of questions and gave their credit card numbers, husbands names, SSN, PINs and mothers' maiden names. Anything wrong with that? That is, aside from when the police did arrived they said there is no such dept. One womans tale: she called the credit card issuers but couldn't reach her bank, being after hours and all. The next morning she found $500 had been taken using her bank card. The Risk, stupidity or cupidity aside, is being unlucky enough to be a victim outside bankers hours ... and in a bank not having a 24-hour notification phone#. There Oughta Be A Law, as credit cards, that limits consumer loss to $50 for such cases. (PS: the same woman said she had worked out daily until then but "Now I am so paranoid I haven't been back". That's probably the wrong lesson learned). Norm deCarteret NSDEC Inc ------------------------------ Date: Fri, 27 Jul 2001 00:12:26 -0400 From: Jack Holleran Subject: Identity theft It would interesting to see what the vetting process was for the salesperson(s)? There seems to be an incredible amount of information that was revealed without (m)any controls in place. Huge identity theft uncovered; Files with Social Security and driver's license numbers pasted in chat room; possible link to cell phone applications, By Bob Sullivan, MSNBC, 25 Jul 2001 Key personal data belonging to hundreds of individuals have been shared in an Internet chat room, in what one expert says could become one of the largest identity-theft cases ever. The data include Social Security numbers, driver's license numbers, date of birth and credit card information - everything a criminal would need to open an online bank account, apply for a credit card, even create the paperwork necessary to smuggle illegal immigrants. It is still unclear how the data ended up in the chat room, but an MSNBC.com investigation has revealed common threads among the victims - including the purchase of a cell phone online from VerizonWireless.com or an AT&T Wireless reseller. Full text of the article can be found at http://msnbc.com/news/604496.asp?cp1=1 ------------------------------ Date: Thu, 19 Jul 2001 20:36:19 -0400 From: Paul Bissex Subject: Risks of profanity filtering Observant readers will have already noted that my last name contains the word "sex." Recently, in trying to register with a Web site -- using my real name -- I was chastised for "profanity" and asked to choose a different ID. I declined, and since the company has offered no response to my inquiry as to whether this policy is really necessary, I thought I'd share the screen grab: http://bissex.net/paul/profanity.gif The business risk, alienating customers, is fairly obvious. More broadly, this highlights a familiar problem with "bad-word list" censorware. Imagine if this were an e-mail filter on a firewall instead of a registration script. Paul Bissex, CEO, e-scribe.com ------------------------------ Date: Tue, 31 Jul 2001 17:51:01 -0400 (EDT) From: msb@vex.net (Mark Brader) Subject: Car-door lock remote control activates another car's alarm [The following was posted by "K.D." in alt.fan.cecil-adams; forwarded to Risks by Mark Brader with the author's permission.] On at least three occasions, my battery-operated car unlock remote control set off the car alarms in nearby vehicles. I found that I could turn on the alarm, and with another press of the remote control, turn it off. Ad infinitum. The most astounding of these was the first time it happened (in Rochester, NY). But not simply because this was new information that I could set off the car alarm. Rather, because of the reaction of the owner of the other car. At first, I didn't realize how it was that the nearby car alarm had been triggered, since neither we or anyone else was close to the vehicle. Eventually, I figured out that *I* had done it with my remote control. I also figured out that I could turn the alarm off as well as turn it on. As we continued to approach my car, it also dawned on me that the owner of the vehicle in question was also coming across the lot. I pointed to the previously alarm-sounding vehicle, and asked if it was his. He said that it was. Lest he had observed what had just occurred and somehow thought I was up to no good, I said, "It seems that my remote control activates your car alarm." His response? "I don't have a car alarm." I looked at my sister, who was as perplexed as I was, and decided not to argue / explain. Perhaps I should mention that there was no other vehicle nearby that could have been sounding the alarm. It was not my vehicle. Especially now that it has happened two other times, I am sure my remote control triggered his alarm. One bummer about this is thus: You open your car door. The other person's alarm goes off. You press the remote control again to shut off the alarm and naturally your car door locks again. So, you have to unlock your car door, the alarm of the other car goes off, you open your car door so you can get in your car, and then you press the remote control again to shut off the other car alarm. I suppose if you just gave the alarm enough time, it would shut off on its own. [K.D. then posted this followup] In re-reading my post, I realized that this is screwed up. Yes, when you hit the remote control again ("unlock"), the door lock makes a sound. However, I now realize that it isn't re-locking -- just making that unlocking sound again. I think. At the time (second incident), I recall that when I tried to get into my car after turning off the other person's car alarm, I found that my door was locked. Duh -- I had just unlocked it. I then assumed that I had relocked my car door, even though I had presumably used "unlock" to turn off the alarm, as that is the button I had used that resulted in the alarm turning on. Damn -- if and when this happens again (so far, three times in about as many months), I'll have to study the phenomenon more closely. -KD ------------------------------ Date: Mon, 23 Jul 2001 16:07:25 -0700 (PDT) From: Mike Albaugh Subject: S-not-SL (Re: SSL, RISKS-21.53,54) I have found the following analogy useful, explaining to laypersons the "Security policy" most common on the Web: "Imagine a restaurant that assigns armed guards to escort your credit-card to the cash-register and back, then tacks all the carbons to the employee-bulletin-board, right inside an un-locked back door" Most of them get it immediately. ------------------------------ Date: Mon, 23 Jul 2001 19:52:39 -0400 From: "Robert J. Woodhead (AnimEigo)" Subject: Re: MSN security upgrade forces new e-mail address (Silberman, R-21.54) "Ami A. Silberman" wrote: >The risk? MSN's attempt to improve security (apparently by forcing spammers >to modify their software to change fake msn addresses) has resulted in >additional burden on list administrators. You think that's bad? I've been maintaining a bounce-management tool for a mac-based listserv app, and as such, I see a lot of weird bounce formats, many of which make the extraction of the bouncing e-mail address quite a challenge. But the all-time champ is a certain large ISP who shall remain nameless but whose initials are a,o & l. If one of their users has redirected his e-mail to another ISP, and the final destination e-mail address bounces, then our friendly large ISP sends a polite bounce message back that clearly contains the final destination e-mail address. Alas, since it doesn't contain the original destination e-mail address, it is impossible to determine who to unsubscribe; forevermore, you have a "zombie" in your mailing list. The listserv, alas, doesn't attach a useful header like "Original-Recipient:" that could be used to identify the zombie because it tries to conserve bandwidth by grouping e-mails to the same domain name into a single transaction. If mail servers added an "Original-Recipient:" header if they have to forward the e-mail (and there isn't already one in the headers), life would be immeasurably easier for bounce management. A standard for bounce reporting that made life easy for nonhumans would also seem to be an obvious idea. Needless to say, an e-mail to the large ISP mentioning the issue seems to have gotten sucked into a black hole. Robert Woodhead, CEO, AnimEigo http://www.animeigo.com/ http://selfpromotion.com/ The Net's only URL registration SHARESERVICE. ------------------------------ Date: Tue, 31 Jul 2001 16:13:52 -0700 From: Dave Stringer-Calvert Subject: No Appleplexy needed (Re: RISKS-21.55) The Apple-DNS-hacked item in the latest risks is not a hack - it's a "legitimate" use of the NIC records. Someone has registered hosts with the NIC who just happen to have apple.com in their name. The same thing has been done to Microsoft: ; whois microsoft.com@whois.internic.net [whois.internic.net] MICROSOFT.COM.Z---HELLO-FROM-SIBERIA---I.Z3S.COM MICROSOFT.COM.WILL.NEVER.SATISFY.A.TRUE.TELNETJUNKIE.COM [... and so on into the night] [This was noted by MANY readers. TNX. Sorry for my immoderate lapse. PGN] ------------------------------ Date: Sun, 22 Jul 2001 11:21:43 -0600 (MDT) From: rjohnson@ucar.edu Subject: Re: Autoresponder goes haywire (Bieber, RISKS-21.51) In RISKS-21.51, Joshua M Bieber mentioned the following problems that led to a quite typical autoresponder flood of one of his mailing lists. In addition to the suggested protective measures, it may also be wise for the list to send with the original sender's address as the From/Reply address, instead of using the list broadcast address there. That way, only one person gets nailed with the inappropriate autoresponse. That's still unacceptable behavior, but at least the damage is less severe that way. Better yet, however, is deleting that bogus autoresponder software. Any autoresponder that replies to a message where: 1) the Precedence header indicates Bulk or List, or where 2) the user's address does -not- appear in the To or Cc header is broken software. The author of such an autoresponder should at least be hauled out behind the barn for a strapping. The problem illustrated by Guilty Person, in cahoots with the author of the broken autoresponder used, is that of continually rewriting the same piece of software with the same old mistakes. In this case, it's particularly ludicrous; properly operating examples of 'vacation' have been available for free for 20 years. Richard Johnson ------------------------------ Date: Mon, 23 Jul 2001 21:54:24 +0100 From: Mike James Subject: Re: Erroneous air navigation reading (Hopkins, RISKS-21.53) That description of an aircraft navigation system out by 14 degrees on a bearing posted by Bill Hopkins reminds me of a 'trick' I played on myself. Take one Garmin GPS 12(XL),38,45,48 .... Probably most handheld GPS units. Set user compass variation... setup->navigation->heading->user and enter 180 degrees Now navigate to a waypoint. The bearing to waypoint will be displayed as asked, but 180 degrees out. The 'compass' display arrow correctly contradicts the bearing given. This is confusing but totally correct. Just be careful.... Smaller numbers would be less obvious as in the aircraft case. I was only yacht racing in the Solent and the error was obvious. Crashing off a mountain by using a magnetic compass and a GPS misconfigured like this could be worse. (standing still need magnetic compass for current heading) ------------------------------ Date: Fri, 27 Jul 2001 19:06:45 +0100 From: Chris J Dixon Subject: Re: Polarized sunglasses and LCD frustration (Boyd, RISKS-21.54) Surely it is the other way round. Displays are not fussy about the polarisation angle, but sunglasses are specifically oriented so that they are most effective at intercepting light reflected off (and polarised by) horizontal surfaces. Chris J Dixon Nottingham UK ------------------------------ Date: 12 Feb 2001 (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 e-mail requests to with one-line body subscribe [OR unsubscribe] which requires your confirmation to majordomo@CSL.sri.com . [If E-mail address differs from FROM: subscribe "other-address " ; 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 (Dennis Rears). .UK users should contact . => 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.comlogin anonymous[YourNetAddress]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.56 ************************