precedence: bulk Subject: RISKS DIGEST 18.87 RISKS-LIST: Risks-Forum Digest Thursday 6 March 1997 Volume 18 : Issue 87 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. ***** Contents: ACM Kanellakis Award goes to public-key crypto creators (Peter G. Neumann) Risks of mouse-based interfaces (Jay Hersh via Phil Agre's RRE) Nevada May Ban Junk E-Mail (Edupage) "New" Java hole (Gary McGraw) Another view of what Bob Atkinson said on Authenticode (Christopher Rath) An alarm-system code feature (Robert Orenstein) SPAM generated from RISKS web site (Jim Thompson) Re: Risk of IRS Outsourcing Processing (Pete Kaiser) The number of the beast (Stu Savory) Re: Tattooing SSNs on dogs to secure against dognapping? (Brian A. Reynolds) Re: Not dead yet -- I'm still 3 degrees! (Bill Seurer) Re: Who made the call in the Moldova porn scam? (Aviel Rubin, Larry Kilgallen) AT&T "not responsible"? (Paul Colley) Fraudulent use of e-mail addresses (Andrej Panjkov) Re: Year 2K and my VCR: Dangers of Egg on Face (Nicholas C. Weaver) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 5 Mar 97 08:07:21 PST From: "Peter G. Neumann" Subject: ACM Kanellakis Award goes to public-key crypto creators At this week's ACM97, The Next 50 Years of Computing, the Association for Computing (ACM) has given its first Paris Kanellakis Theory and Practice Award to six people incisively involved in the creation of public-key cryptography: Leonard Adleman (University of Southern California), Whitfield Diffie (Sun Microsystems), Martin Hellman (Stanford University), Ralph Merkle (Xerox PARC), Ronald Rivest (MIT), and Adi Shamir (The Weizmann Institute of Science), ``for the conception and first effective realization of public-key cryptography. The idea of a public-key cryptosystem was a major conceptual breakthrough that continues to stimulate research to this day, and without it today's rapid growth of electronic commerce would have been impossible.'' The award is named in memory of Paris Kanellakis, whose tragic death in December 1995 cut short a distinguished research career. This event is most worthy of notice in RISKS, because the systematic use of public-key crypto has extraordinarily high potential for dramatically reducing many of the security risks so frequently discussed here -- including loss of confidentiality (e.g., through its use in the distribution of conventional crypto keys and in key management generally) and integrity (through its use in cryptographic checksums, digital signatures, and authentication). Congratulations! ------------------------------ Date: Wed, 5 Mar 1997 14:04:55 -0800 (PST) From: Phil Agre Subject: Risks of mouse-based interfaces [Once again the disability community takes the lead in decrying the GUI revolution, which has gone way too far. Interfaces should be measured in terms of how often one must move a hand from keyboard to mouse and back, in terms of the swapping delays that real users experience when endless little dialogue boxes have to pop up to accomplish anything, and in terms of the provision of meaningful keyboard equivalents for the functions that real people use. All the widespread PC OS's fail miserably at these criteria in my opinion. Except for a small number of crucial functions like copy and paste, I find myself being much more productive with a Unix command interface and my beloved Emacs text editor than with either the Mac or Windows interfaces and mouse- intensive WYSIWYG editors. Phil Agre] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help@weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Wed, 26 Feb 1997 12:24:37 -0500 (EST) >From: "Jay Hersh aka Dr. Beer (SM)" To: voice-users@cuckoo.hpl.hp.com Subject: Working with Quicken I am currently using Quicken version 6 and previously used version 5. What I have found is that many of the "buttons" do not register their names with the Windows API and therefore DragonDictate can't automatically build macros on the fly to access these. This situation is worse with Quicken 6 than it was with version 5. Overall I believe this is a significant problem within the application development industry, i.e. moving functionality more and more towards mouse oriented interfaces, using visual icons inside buttons rather than plain text and/or failing to register the text with the Windows API. Additionally more and more of the functionality of applications accessible through mouse usage lacks hot key equivalents making it difficult to create macros by hand (macros based on keystroke combinations are more reliable in general than those base on mouse positioning and button clicks since they are independent of window resizing). Another obnoxious trend is that of popping up windows for each bit of functionality rather than subsuming them within the current window. For instance Quicken does an automatic backup which puts up 5 different windows, one after another, each after you hit the enter key for the current one. This is annoying because you must wait each time for the new window to map onto the screen before you can hit the enter key. This also makes developing a macro to accomplish this difficult because of the timing issues involved in waiting for the next window to map before issuing the next enter key. I believe that we as a community, along with Dragon Systems, Kurzweil, and IBM as companies need to stop these trends now. The more applications become developed around an assumption of the mouse as a primary user interface the more difficult utilizing the current generation of speech recognition technology (which is based upon synthetic keystroke generation) will become, and the more a barrier is presented to us and especially to those with severe enough handicaps that hands free usage is their only option. Jay This is a key free document, no keyboards were harmed in its creation. (The DragonDictate speech recognition system, the CIC handwriting recognizer, or some combination was used.)a [Suggested to RISKS by "Mich Kabay [NCSA]" ] ------------------------------ Date: Tue, 4 Mar 1997 12:05:50 -0500 From: Edupage Editors Subject: Nevada May Ban Junk E-Mail (Edupage, 4 March 1997) The Nevada state Senate has introduced a bill that would make sending unsolicited ads directly to e-mail accounts a misdemeanor. "Most e-mail users pay for their service, so unsolicited e-mail is like receiving direct mail with postage due," says the Senate's majority leader, who notes the bill is modeled on a previous measure that bans unsolicited advertising over fax machines. California, Virginia and Connecticut are considering similar measures, but the Nevada legislature is widely viewed as closest to passing the ban. (*St. Petersburg Times*, 3 Mar 1997; Edupage, 4 March 1997) ------------------------------ Date: Thu, 27 Feb 1997 16:40:59 -0500 (EST) From: Gary McGraw Subject: "New" Java hole In a post to comp.lang.java.security and BUGTRAQ, Major Malfunction & Ben Laurie claimed on 25 Feb 1997 to have discovered a couple of new Java-based attacks. See: http://www.alcrypto.co.uk/java/ The first "less serious hole" allows a miscreant "to gain access to information from the client machine which would normally be considered 'secure'." This works with the Netscape Navigator. Though their attack works as advertised on the page, there is really nothing new to this discovery. On their page, they say: >All we can do is log the real identity of a client machine, despite >most precautions they might take to prevent us from doing >so... [firewalls, proxies, SOCKS, anonymizer...] >we take one call to InetAddress.getLocalHost()... And there you have it. Since the applet is running on the client machine and it is allowed to call InetAddress.getLocalHost(), it can find out the client machine's IP. Though this may surprise some users (especially those using the anonymizer), the ferreting-out of this information is not really a dangerous new invasion of privacy. The Web is currently not a private place. This demonstration serves to bring that point home. Your Browser is probably a blabbermouth. It is a clever move to use Java to look up an IP at the client end through several proxy layers, but not all that clever. The second attack is more disturbing. This one works only for the Microsoft Internet Explorer. They claim "this loophole allows an attacker to connect to any TCP/IP port on the client's machine." That's a bit of an overstatement, but interesting information about listening ports can be gathered (for possible later use). This may leave a firewalled host more susceptible to standard TCP/IP based attacks. That's bad. The Java Security Manager usually disallows port scanning behavior. But the crackers use the well-known trick of sticking some Java code in the browser's cache and later executing it through a file: URL (using frames in the usual way.) Since Microsoft's cache layout is transparent, this attack works. This is an interesting variation on the Hopwood slash-and-burn attack described on page 69 of the book I wrote with Felten "Java Security: Hostile Applets, Holes, and Antidotes". The attackers cheat a bit for demonstration purposes by having the patsy clear their cache to begin with, but even without this exercise, guessing the cache location (one of four possibilities) would not be all that much of a challenge. Contrary to the claim on their page, Java security rules are no longer relaxed for code loaded out of the cache (unless the cache happens to be in the CLASSPATH---not recommended). That problem was fixed. In any case, Microsoft apparently places HTML and class files in the same directory *stored with their original names*. Though MSIE can't browse cache files directly, HTML pages can reference cache files by explicit name. Thus the file: URL, if properly constructed, can invoke the Java class. The applet the crackers stuff in your cache is a port scanner. In this case, the port scanning attack works because an applet is allowed to open a socket connection back to where it came from. Guess where it came from? The client machine. So a port scan is carried out by their cache-bomb applet. That leaves only the problem of getting the port scan information back to the cracker site. They use the URL lookup covert channel to do this. (The Princeton team has explained this in a paper.) This is one of many ways of sending interesting tidbits out from an applet. In summary, the information released on 25 Feb by Major Malfunction & Ben Laurie provides a couple of examples of some known attacks. If that helps educate Web users about the risks of executable content, that's good. If it stirs up unnecessary panic, that's bad. Gary McGraw p.s. See http://www.rstcorp.com/java-security.html for information on the book, Java Security: Hostile Applets, Holes, and Antidotes Dr. Gary McGraw, Research Scientist, Reliable Software Technologies (RST) Sterling, VA gem@rstcorp.com ------------------------------ Date: 06 Mar 1997 07:20 EST From: "Christopher Rath" Subject: Another view of what Bob Atkinson said on Authenticode (RISKS-18.85) If I may be so bold as to re-state Bob Atkinson's arguments, here is my understanding of what he wrote: Since the earliest days of the down-loading of software from BBSes, most users have typically down-loaded software just because it is there and they want to run it. Users have not refrained from down-loading and executing software because of security concerns. Therefore, given that most users simply want to down-load and run whatever choice software offerings they encounter, Microsoft has endeavoured to make this process as transparent and unencumbered as possible. In my view, Microsoft had two possible avenues of development and marketing to choose from, as they developed their browser: 1) to move the security benchmark forward, as Java has done, or 2) to leave it where it is, or even allow it to slip a bit, in order to garner market share and further control of network-based software interests. Is it, then, any wonder that they chose the latter! The issues surrounding the consumer demand that Microsoft is responding to are the same issues which surround many other activities in society. To state this another way, there are many pursuits which have risks associated with them, and large numbers of people choose, every year, to rationalize-away those potential risks; smoking, promiscuity, obesity, and many other socially acceptable behaviours are all examples of the same phenomena we see manifesting itself in the view Bob Atkinson propones. Christopher Rath, Northern Telecom Ltd., Box 3511, Station `C', Ottawa, ONTARIO K1Y 4H7 CANADA crath@nortel.ca (613) 765-3141 FAX: (613) 763-4101 ------------------------------ Date: Tue, 4 Mar 1997 13:11:31 -0800 From: Robert Orenstein Subject: An alarm-system code feature A friend of mine was going on vacation for a week, and asked me to come by her house each day to feed her cat. The house has a standard alarm system: when you open the door, it beeps; punch in the correct number and the beeping stops. I memorized the code, but on the third day, I couldn't remember if the last digit was a 6 or a 7. I tried 7; the beeping stopped. I fed the cat and left. For the next two days, I punched in the same code, fed the cat, and left. On the last day, I punched in the code, fed the cat, and stayed around to read the paper. Five minutes later there was a knock on the door. It was the police. They asked me if I lived there; I said I didn't, but was cat-sitting. They asked me the address of the house I was in; I didn't know it, since my friend lives just around the corner from me and I know where the house is by sight, not by address. That was enough for them to assume that I was robbing the place; they handcuffed me and were about to take me to jail when a neighbor came out and verified that I was cat-sitting. What had happened? The last digit of the alarm code was actually a 6, not a 7. But there's an additional "feature" of the system: if someone is pointing a gun to your head and telling you to turn off the alarm, you can simply add 1 to the alarm code and punch that in instead. This sends an "extreme distress" signal: the beeping stops as if you'd entered the correct code, but the police are dispatched to what they assume is a high-risk situation. I'd been sending false alarms for four days, but leaving before the police arrived. The risks are clear: I could have been shot. As it was, my friend was billed for four false alarms; at $50 per false alarm, it cost us $200 (we split the bill). Robert Orenstein [Even though this item is marginally computer related, the design feature may be suggestive of related risks in authentication mechanisms -- especially those that seek to entrap attempted intruders. Incidentally, W.S. Gilbert was there before you: ``Either at sixes or at sevens.'' PGN] ------------------------------ Date: Tue, 4 Mar 1997 14:10:47 -0600 From: jthompso@netcom.com (Jim Thompson) Subject: SPAM generated from RISKS web site The following bit of spam just arrived in the mail >>>>> "spam" == RHill writes: spam> Hello, I saw your site at spam> http://catless.ncl.ac.uk/Risks/17.78.html/, it looks great... The spam goes on to tell me how to register in Internet directories for a mere $249. Note the reference to "your site" and the shallow compliment. The "site" that the spammer refers to is RISKS Digest volume 17, issue 78; it contains a short contribution from me. Looks like the spammer grepped the web site for e-mail addresses, possibly in mail-to: tags. Clearly e-mail spammers aren't any smarter or more discriminating than snail-mail spammers when it comes to gathering addresses; does this fellow really think that every mail-to: tag in a web page refers to its author(s)? I'm reminded of the well-known junk mail that begins "Dear Mr. and Mrs. Public Library, you have just won..." Jim jim.thompson@pobox.com ------------------------------ Date: Mon, 17 Feb 97 11:37:04 +0100 From: Kaiser@ACM.org Subject: Re: Risk of IRS Outsourcing Processing (Pescatore, RISKS-18.82) I believe that John understates the risk of outsourcing IRS forms processing, in several ways. First, the government employees will continue to have access to the information, so the exposure of information doesn't simply shift from one venue to another, but continues at the first and is added at others, plus the risks of transporting the data first in hard format, then in electronic format. There will also be all the points of exposure in auditing the contractors. Second, based on the behavior of the credit-reporting industry, private enterprise seems to show no very high standard of concern for privacy. The firms on which we rely for "preparing our tax returns, handling our checking accounts, or storing the records of counseling sessions" are individually responsible to us under law to maintain confidentiality, which gives them an incentive to act responsibly: if your accountant failed to safeguard your financial information, he could reasonably expect to find himself in court, with your personal lawyer at the other table. (Compare this to the record of the credit-reporting industry.) I doubt the same strict and direct responsibility would be found in outsourced processing of IRS forms, unless the IRS somehow magically could come up with a new and effective set of rules and operations to manage it, of a kind we have never yet seen. The RISKS item does little do allude to this. The government employee's "little to fear as far as termination of employment" is a red herring, to which it's possible to oppose another scenario: "Lowest Bidder, Inc." gets a big chunk of the IRS's outsourced forms processing business. Joseph Savvy, CEO of the business, knows a potential gold mine, and through friends in places where money is laundered -- with expert accountants and all the needed computing capacity -- does a lot of data mining on the stream of information passing through his business's keyboards. This leads to a brand new stream of expert and nearly untraceable financial crime, plus other traditional crimes like blackmail and extortion, and the sale of some really exciting mailing lists on the open market. After all, who checks the provenance of information on mailing lists? To me this seems not at all unrealistic. Pete kaiser@acm.org ------------------------------ Date: Wed, 05 Mar 1997 14:57:53 +0100 From: Stu Savory Subject: The number of the beast This is how dog tattoo numbers work in Germany, which your other SSN-reporter may care to adopt. Our dog has a 4-digit number tatooed in its ear. A finder can call the registry centre (number available at each local vet or attached elsewhere to the dog) and report e.g., Hellhound 0666 found. The registry centre database may report several different dogs 0666, so additional data about gender and breed may be asked for, for clarification. If you are on the owner short-list, you get a phone call, asking whether your dog is missing. If so, you are given the phone number/address of the finder. Lazy finders just turn the dog into the local pound & let them sort it out (maybe missing on the chance of a reward). Because dogs are required to be numbered, either per tatoo or per subcutaneous transponder, for crossing national borders, this mechanism is no extra hassle. Probably UK does not have this border requirement. Stu Savory (Owner, Bulldogs 0157 and (yes!) 0666) [They have Border Collies instead, whose collars enable Collie forwarding and Collie flowering. However, we are wandering, so let's terminate the ssnaggy dog stories. PGN] ------------------------------ Date: Wed, 05 Mar 1997 10:22:53 -0600 From: "Brian A. Reynolds" Subject: Re: Tattooing SSNs on dogs to secure against dognapping? It is common practice to engrave one's drivers license number onto object which are likely to be stolen. This assists in the identification and retrieval. Guess what? In Iowa, the Drivers License number is identical to one's SSN! So the risk is in assuming that your SSN is privileged information. It gets written on every check that I write, it's also my health care member ID number, employee identification number, etc. etc. etc. Brian Reynolds ------------------------------ Date: Tue, 4 Mar 1997 14:34:55 -0600 (CST) From: Bill Seurer Subject: Re: Not dead yet -- I'm still 3 degrees! > She replied, "3's an error code." On a medical device with 4 digits output what sort of meaningful error code would you except? Our home model does the same thing (although it flashes the result for an error) and its manual clearly states what each error code means. It also explains how to use it to avoid getting the various errors. Error "3" is that it couldn't read your temperature, usually a result of not aiming it properly. I don't think anyone would confuse that with a valid reading. The risk here seems to be that the nurse was not trained beyond "stick it in the ear and push the button". Sort of like if she had been trained with an oral thermometer to "stick it in the mouth" and not properly to place it under the tongue. At least the aural thermometer (is that what they are called?) tells you there's a problem whereas the oral one would just give a bad reading. They also work vastly better for "difficult" patients like small kids. Bill Seurer ID Tools and Compiler Development IBM Rochester, MN BillSeurer@vnet.ibm.com http://members.aol.com/BillSeurer/ ------------------------------ Date: 22 Feb 1997 16:32:16 GMT From: rubin@quip.eecs.umich.edu (Aviel Rubin) Subject: Re: Who made the call in the Moldova porn scam? A colleague of mine at AT&T suggested that this is similar to someone breaking into your house and making international calls. Who is responsible? Actually, I think it's more like someone knocking on your door, you let them in, and when you are not paying attention, they make these calls. Now, who is responsible? You? The phone company? Your house insurance? Although I hate to see people defrauded, I have been waiting for the day that people get burned from downloading programs from the net and running them. How can you expect anything else? Hopefully this publicity will help educate people against these dangers. Avi Rubin [usual disclaimers apply] ------------------------------ Date: Sat, 22 Feb 1997 14:40:09 -0500 (EST) From: "Larry Kilgallen, LJK Software" Subject: Re: Who made the call in the Moldova porn scam? (Horowitz, R 18.84) Perhaps phone lines should be password protected. That is available for incoming WATS calls. I have a simpler form for outgoing calls -- it is only one digit long and the password is "9". Only the most diligent of the scam artists would bother with this possibility. Even safer are the minority of folks whose password for an outside line is "7" or some other non-9 digit. Scam artists who bother taking that into account must be really rare, and deserving of being hired into an honorable (?) position fixing some of the commercial software so often discussed in RISKS. Larry Kilgallen ------------------------------ Date: Sat, 22 Feb 1997 10:08:43 -0500 From: colley@qucis.queensu.ca (Paul Colley) Subject: AT&T "not responsible"? >From: Marc Horowitz >Subject: Re: Who made the call in the Moldova porn scam? (Claar, RISKS-18.83) >... A more proper analogy: If someone steals your car, and crashes it into >another car, totalling both, the owner of the other car is not responsible. >If someone steals your phone line and makes lots of calls, AT&T is not >responsible. I'm not unhappy with your conclusion, but I strongly dislike your analogy. International calls are very profitable for phone companies. If someone steals your phone line and makes lots of international calls that AT&T can collect for, AT&T makes a substantial profit---and unlike the car accident analogy, doesn't risk lethal injury. This makes it to AT&T's benefit to be a "bad driver", to encourage as much damage and mayhem on the "road" as possible. Bad analogy; bad policy. There is good reason to hold AT&T responsible for calls made to that number after AT&T was notified of the scam; and good reason to hold the customers responsible before that point. Paul Colley colley@qucis.queensu.ca +1 613 545 3807 http://www.qucis.queensu.ca/home/colley/info.html ------------------------------ Date: Tue, 4 Mar 1997 10:55:11 +1000 From: A.Panjkov@latrobe.edu.au (Andrej Panjkov) Subject: Fraudulent use of e-mail addresses A recent item on fraudulent Usenet postings reminded me of a stunt some of my students pulled on me a couple of years ago. It seems that some students (we never found out who) posted some personal ads purporting to come from me on a romance web page. I found out about this when I received e-mail from some admirers. My wife was unimpressed. :> We traced the source of the forged messages to an undergraduate computer study hall. They have since changed their policy to require that users obtain accounts first. It took a whole week before the fraudulent message was removed from the web page it was on, and then only when I threatened to report the owner of the page to whatever authority governed fraudulent communications in their jurisdiction. The responses I received to "my" ad were from some quite charming ladies who were also victims of this scam. I regarded the matter as a prank, but the same technique could have been used to place my name in uglier contexts Lessons: monitor undergraduate computers carefully. At the very least, register users. And use PGP. Perhaps, we should all periodically sweep the web to see where our names are ending up? Dr Andrej Panjkov, La Trobe Uni, Melbourne, Australia A.Panjkov@latrobe.edu.au http://guardian.maths.latrobe.edu.au +61 3 9479 2595 ------------------------------ Date: Thu, 27 Feb 1997 17:45:49 -0800 (PST) From: "Nicholas C. Weaver" Subject: Re: Year 2K and my VCR: Dangers of Egg on Face (RISKS-18.84) Upon further testing (prodded by others), I poked around on my VCR and, well, it does have the proper calendar, although the date is shown wrong, only the year is affected. It gets the days right (Feb 29 2000 is a tues, and the VCR agrees). I guess the risk is worrying about non-problems when there are much important things. ------------------------------ Date: 15 Aug 1996 (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. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, 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 or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ End of RISKS-FORUM Digest 18.87 ************************