Subject: RISKS DIGEST 18.09 RISKS-LIST: Risks-Forum Digest Weds 1 May 1996 Volume 18 : Issue 09 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. ***** ****************** including periodic PRIVACY info update ******************* Contents: Breaking Java security restrictions with Javascript (Stephen Anderson) More on Java security (Peter Hughes) Cambridge University systems hacked! (David Alexander) File permissions 705 (Mordechai T. Abzug) Libel writ served by e-mail (Andrew Martin) X-Image-URL e-mail header line (Andrew Dalke) Internal e-mail addresses don't work (John Gilliver) File your tax return on the Web! (Jakob Schiotz) Australian court emulates Swedes (Ashley Robertson) Re: Warning! My [...] let me [act] (Geoffrey Cooper) Correction: The RISK of attributing error to malice (Paul R. Potts) Re: The RISK of attributing error to malice (Randal L. Schwartz) Odds of an accident for the Challenger (Michael Perelman) Children on the Internet: A Forum, Chicago, 18 May 1996 (David E. Sorkin) UNABRIDGED Info on RISKS (comp.risks), subscriptions, etc. ---------------------------------------------------------------------- Date: Wed, 1 May 1996 12:30:13 +0000 (GMT) From: "Stephen.Anderson" Subject: Breaking Java security restrictions with Javascript I'm unaware of whether this point has been raised: under Netscape 2.01 and Atlas, there is a hole in Java vs. Javascript security that allows an Applet to (amongst other things) contact a host other than that it was loaded from. As Netscape allows use of "javascript:" URLs, it is possible to construct a Javascript string in a Applet, then execute it by a call to showDocument(). This Javascript is *not* subject to the same security restrictions as the Applet. There are only three immediate risks I can think of: 1. People can end up reading pages they didn't expect or have any wish to (though this is a risk with Javascript more than with Java, Java offers an extra layer of concealment) 2. On a related note, people can end up running Applets they didn't expect to, from different hosts, and these Applets may be able to compromise security by communicating with each other. 3. Any Javascript security holes are also available to Java Stephen Anderson, Planet Online : The White House, Melbourne Street, Leeds LS2 7PS UK. +44 (0) 113 2345566 Stephen.Anderson@theplanet.net ------------------------------ Date: Wed, 1 May 1996 12:43:29 -0700 From: Peter Hughes Subject: More on Java security It seems to me that no end is in sight to the security holes in Java. In addition, I have been hearing that Java (and net access in general) will soon become more deeply integrated into desktop OSs. Just how bad could this get? Is there a way that uncontrolled or malicious Java applets could propagate themselves about the net? Examples: * A Java applet that runs server code, propagating itself from its own server? * An applet that inserts copies of itself into a server on a machine that is also used to run a browser? * An applet that runs compiler code, creating an application of the author's choosing on the target machine? * An applet that attaches itself to Java-enabled applications or their documents (a la Word macro virii), perhaps then using file sharing to propagate itself? I can think of other scenarios that are not specific to executable applets, such as the exploitation of security holes on the net. (The Morris worm is an example of such). Given how few users take security seriously (or understand its implications), how likely is an event that causes massive damage? The folks that designed Java took all this and more into account, but the continuing bugs show that the propagation of executables of this type carries an inherent RISK. The community is to be commended for scrutinizing Java. Pete (I turned off Java, and I don't run Word 6) ------------------------------ Date: Mon, 29 Apr 1996 10:19:01 +0100 From: David Alexander Subject: Cambridge University systems hacked! The following article was in Saturday 27th April (UK) Daily Mail newspaper: Start> Cambridge computer chaos as hacker hits secret files A worldwide hunt has been launched for a computer hacker who accessed sensitive research information at Cambridge University. Confidential files were broken into using the Internet. Now up to 10,000 academics and students are being forced to alter their passwords as the university's computer experts try to plug the leak. Many of the files belong to top research scientists and contain commercial, academic and medical information. Richard Stibbs, Director of computer science studies at the university said: "The hacker could come from anywhere in the world. The potential damage to Cambridge University and beyond is enormous. Fortunately no files appeared to have been tampered with, but we are asking everyone to check very carefully." The alarm was raised when a network security system which links universities detected a rogue program in the Cambridge computer. The hacker is thought to have gained access through the university's E-mail system, the Ethernet [sic]. Experts are trying to trace when he broke into the system - which is being replaced to prevent any similar lapses - and find out where the calls came from. If caught, the culprit could face up to 5 years in jail. Subject: File permissions 705 Under IRIX 5.3 (and perhaps other Unix variants), if someone 'chmod's a file or directory to allow world access but to deny group access (i.e., 705), then members of the user's group can't access the file. I don't know why this should be, but assuming it makes sense, I've found a way around it, even though I only belong to one group and can't 'newgrp': I made a symbolic link to the file and put it in my web directory. Many 'httpd's (including the one here) allow sym links to files/ directories outside the user's web directory, and many httpd runs as user nobody or guest. Presto! Access to the Mail directory of a friend who thought he was being quite clever. Of course, I immediately showed him what I had done, and warned him to use 700, but I didn't have to. . . Mordechai T. Abzug http://umbc.edu/~mabzug1 mabzug1@umbc.edu finger -l mabzug1@gl.umbc.edu ------------------------------ Date: Wed, 1 May 1996 15:19:41 +1000 (EST) From: Andrew Martin Subject: Libel writ served by e-mail [I suppose the only new risk here is that a court is seen to be believing some rather flimsy evidence.] `The Electronic Telegraph' [Web Edition of Major UK Newspaper], by Robert Uhlig, 1 May 1996 In a ground-breaking case, lawyers have used the Net to enforce a British court order overseas. THE INTERNET has for the first time been used to serve a legal injunction outside the UK, arguably establishing a precedent allowing the global computer network to be used as a medium for distributing legal documents, in the same manner as a fax machine. The development could also spell an end to the freedom of speech enjoyed in hundreds of specialist news groups on the Internet, where users discuss a wide spectrum of matters ranging from the complexities of rival computer operating systems to libellous speculation on celebrities' sexual practices. The media and entertainment law firm Schilling and Lom in London received threats, via e-mail, from an individual in Europe who claimed he was planning to disseminate libellous material about one of its clients over the Internet. "The e-mail contained the sender's two Internet addresses," said Jonathan Coad, a libel partner at the firm. "When an injunction was obtained against him, we persuaded Mr Justice Newman to grant us leave ex parte to serve an order via these e-mail addresses. "We have to prove that the defendant received the injunction, and used the 'return receipt' capability of e-mail to prove that the defendant had seen the injunction on his computer screen." Mr Coad added that the defendant also acknowledged separately that he had received the injunction. [...another lawyer] pointed out that there was still doubt over which nation's laws applied if someone made a libellous statement on a global medium such as the Internet. "Courts will have to move with the times and there are a number of modern judges who are willing to make the move," he said. ------------------------------ Date: Tue, 30 Apr 1996 00:47:41 -0500 From: "Andrew Dalke" Subject: X-Image-URL e-mail header line I just received e-mail with a header line I have never seen before, > X-Image-Url: ftp://ftp.somewhere.else/pub/images/face.tiff It appears to replace the 'X-Face' header as the URL was an image of the sender's face. The risks are similar to those of web browsers, but ones I hadn't expected from an e-mail message. Two are: 1) If the URL is accessed when I read my mail, by looking at the server logs the sender knows many things, including when I read my mail and the machine I use to do so. Imagine if mail handled by an anonymous remailer did not strip out this header. The (supposedly) anonymous receiver checks e-mail, the mail reader contacts the originator's site, and the sender knows at least the machine the recipient uses, and probably has a good guess as to the identity. 2) Inappropriately designed mail readers might not offer a "Stop" button to stop the transfer of large images. If the mail message proper is displayed after the image is downloaded, it might take a long time to transfer the image, while the mail itself is just a few lines longs. Andrew Dalke dalke@ks.uiuc.edu ------------------------------ Date: Tue, 30 Apr 1996 15:50:44 +0100 From: John Gilliver Subject: Internal e-mail addresses don't work In RISKS 18.08 appeared: : From: Andy Piper : The RISKS? Don't make assumptions about how your intended audience will view I was going to discuss this privately with the poster (basically, although it is to some extent a valid point, the practice of assuming fixed-spacing fonts for news - so that, for example, ^s come out right - is quite widespread); however, I noticed where I would be sending it. I suspect this is an address which works well internally, but would fail if I tried to use it. I'm sure it is an old RISK, but obviously still needs mentioning! {The software I use at home [Turnpike] won't allow me to send to an address without an @ sign, and at least one dot after it, which must be both preceded and followed by at least one character, which would have stopped me sending the reply - but of course doesn't help anyone actually wanting to contact Andy. [Perhaps that was the intention (-:!]} J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW, Essex, CM2 8HN, UK. +44 1245 242133 john.gilliver@gecm.com [Yes, it is indeed an old risk, but still prevalent. I am always astounded at how many e-mail messages I cannot answer for this reason! PGN] [Plus, there are now more cases where there are large internal networks, so people may be increasingly under the impression that it does work (as they may spend some time e-mailing internally before venturing into the big wide world outside, which maybe they didn't as much before). JPG] ------------------------------ Date: Fri, 26 Apr 1996 13:13:48 -0500 From: Jakob Schiotz Subject: File your tax return on the Web! Last year I moved from Denmark to the United States, so I have just had the "pleasure" of filing my tax returns in two countries. This has made me appreciate the efforts the Danish authorities have made in recent years to make the process easier. Basically, almost everything they need to know has already been reported to the authorities by the employer(s), the bank etc. Then they send you a tax return form with the relevant numbers printed on them, and you are then supposed to check them, correct any wrong numbers (unlikely) and add any info they do not have (more likely). This year they have gone a step further: you can call a specific number and use you touch tone phone to file, or you can file on the Web at http://www.tastselv.toldskat.dk/ (in Danish). To file you need your CPR number (similar to the US social security number) and a 7-digit individual security code printed on the form. You can then fill out the form and submit it. If you make a mistake it can be corrected the same day, but if you discover it later you have to contact the local tax authorities. This means that a manual override system is in place, IMHO a good thing. I am not a lawyer, but there must be some legal RISKS here. If I try to cheat how are they going to prove that it was me? And even if they know, is filling a form on the Web has any legal value? I don't sign anything, can typing a code that presumably only I know be legally equivalent to signing a document? A more worrying RISK is that somebody actually do mess with other peoples tax returns. They don't use encrypted transfers, so sniffing the security code should at least in theory be trivial. It may be easier to get the code by social engineering, especially if the victim has no experience with computers and passwords ("Hello, it's the tax department. Due to a computer error some of our records have been lost, would you please tell us the numbers printed on the front page of the tax return form we sent you?"). An even more scary situation is that someone actually breaks into the machine running the web server. The requirement that any corrections must be made the same day may actually be an example of good risk management. If the info is transferred from the web server to another computer, and if that other computer only accepts to amend a filed return on the same day the original was filed, then the damage from a hacker will be limited to the returns filed that day (although if that day is April 30, the last day to file, the damage may still be considerable). Finally, we should also consider the risk of typos. Whom do you trust the most to get the numbers right? Yourself, who will be directly affected by an error? The OCR program "reading" your handwriting? Or maybe the (tired) clerk that has to manually type in the numbers on the forms where the handwriting is too illegible? This is (IMHO) a point in favor of the type-it-yourself service. Jakob Schiotz, Dept of Physics, Washington University, St. Louis, MO 63130 +1 (314) 935 4968 schiotz@howdy.wustl.edu Fax +1 (314) 935 6219 ------------------------------ Date: Tue, 30 Apr 1996 11:07:43 -0800 From: Ashley Robertson Subject: Australian court emulates Swedes (re: Gong, RISKS-18.06) A similar situation has occurred here in Western Australia. New parents of a baby boy were unable to give their child an ancestral name because of the accents on some of the characters. The name was not offensive or difficult to pronounce. The reason given was that the computer system of the Registry of Births and Deaths could not accept the name because it was not a standard ASCII character. The solution was not as easy as removing the accents because that substantially changes the pronunciation of the name. The child remains unnamed! Ashley Robertson, Murdoch University, WESTERN AUSTRALIA +(619) 360 2101 ashley@babbage.cs.murdoch.edu.au http://www.cs.murdoch.edu.au/~ashley [I suppose you could try to name a child something like Ju-umlaut-rgen or He-aigu-le-grave-ne? (with or without the hyphens, according to your taste after rereading RISKS-17.95). PGN] ------------------------------ Date: Thu, 18 Apr 1996 11:00:46 -0700 From: Geoffrey Cooper Subject: Re: Warning! My [...] let me [act] (Bailey, RISKS-18.03) In RISKS-18.03, Rob Bailey writes that a human operator is an intrinsic part of a system in which he or she operates. Therefore, the human operator must share the blame if the system fails. This is true; Since the human is part of the system, the strengths and weaknesses of the human must be taken into account in "good" system design, just as must be done for any other system component. In the original design of the manual typewriter, there was a problem with the operator hitting the keys too fast; this caused mechanical jams. The problem was solved by the addition of the QWERTY keyboard encoding, which slowed down the typist by alternating the key locations between his two hands. This is was an appropriate design for the human component, even if it does not excuse us from still using QWERTY today. We bristle when the media leaps to blame the operator; we must similarly bristle if we leap to blame the machine. The RISKS we seek are in the combination of the two, when the interface with the machine confuses or confounds the operator and encourages mistakes. For example, an airplane that is willing to touch down without the landing gear deployed is not necessarily a bad system design, since: - the pilot has procedures to prevent this from happening, including licensing to ensure that the pilot understands these procedures. - the pilot may need to land the plane in this way in an emergency. Conversely, an autopilot that automatically limits the pilots steering requests to avoid damage to the airplane might indeed be a bad system design. The human component might correctly need to damage the airplane in a sharp turn in order to save the lives of the passengers. - Geof Cooper, Compact Devices, Inc. ------------------------------ Date: Tue, 30 Apr 1996 12:40:30 -0400 From: potts@cancer.med.umich.edu (Paul R. Potts) Subject: Correction: The RISK of attributing error to malice (RISKS-18.08) In the paragraph where I wrote: >I haven't explained the duplicate copies on the remote machine or why the >message was seen earlier, but this isn't necessary in order to convince me >that this "forgery" was really an accident. the text should have read "why the message wasn't seen earlier." ^^^^^^ Since the mail program automatically opens windows holding unsent outgoing mail when it is launched, the question was why the staff member did not see the message the morning after it was written, when she fired up her computer and launched the mail program. There are lots of possible reasons: maybe she hadn't really shut down her computer and didn't re-launch the mail program the next morning, or maybe she simply didn't notice the mail message, or maybe the mail program didn't open the window for some reason. I jumped to the conclusion that perhaps the file's creation date had been faked by resetting the Macintosh system clock, obviously failing to apply Occam's razor to the various hypotheses. I'm confident that our moderator can come up with an appropriate pun here, perhaps something about shooting the mail-message(r) or a close shave that cuts both ways : ) "Paul R. Potts" Technical Lead - Health Media Research Lab University of Michigan Comprehensive Cancer Center potts@cancer.med.umich.edu ------------------------------ Date: Tue, 30 Apr 1996 08:14:54 -0700 (PDT) From: "Randal L. Schwartz" Subject: Re: The RISK of attributing error to malice (Potts, RISKS-18.08) And such an unfounded witch-hunt can even further lead to criminal convictions, as it did in my case. For details, see the website http://www.lightlink.com/fors/. If you are web-challenged, you can get the executive summary by writing to my reply-bot at fund@stonehenge.com (the content will be mostly ignored). I urge everyone with system administration responsibilities to be aware of this case, and to share the information with others. Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095 Snail: (Call) PGP-Key: (finger merlyn@ora.com) ------------------------------ Date: 26 Apr 1996 01:58:33 GMT From: michael@ecst.CSUChico.EDU (Michael Perelman) Subject: Odds of an accident for the Challenger I have heard that just before the Challenger flight, NASA issued a reports of the odds of an accident. Does anybody know of a source? What were the odds? Michael Perelman, Economics Department, California State University Chico, CA. 95929 michael@ecst.csuchico.edu ------------------------------ Date: Tue, 30 Apr 1996 20:07:19 CST From: "David E. Sorkin" <7SORKIN@jmls.edu> Subject: Children on the Internet: A Forum, Chicago, 18 May 1996 The John Marshall Law School Center for Informatics Law, in association with the Illinois Privacy Council, announces the following conference: CHILDREN ON THE INTERNET: A FORUM FOR PARENTS AND EDUCATORS. Saturday, May 18, 1996, 8:30 am-5:30 pm, at The John Marshall Law School, 315 South Plymouth Court, Chicago, Illinois. The purpose of The Forum is to explore the benefits of the Internet and online services and to learn about risks as well, so that informed parents and educators can cooperate with service providers so as to enjoy the advantages of the Internet while avoiding the negatives. Panelists will demonstrate Internet resources available for children; will discuss the potential for commercial manipulation of children, invasions of privacy, access to objectionable materials, and other risks; and will suggest appropriate roles and responsibilities of parents, educators, and institutions in minimizing these risks. The registration fee of $40 includes continental breakfast, lunch, and conference materials. Registration deadline: May 13, 1996. Space is limited. For more information, call the Center for Informatics Law at (312) 987-1419, or e-mail privacy@jmls.edu. Information about the Forum is also available on the World Wide Web at http://www.jmls.edu/conf/ipcforum/. -- David E. Sorkin (7sorkin@jmls.edu) -- Associate Director, Center for Informatics Law, The John Marshall Law School [I wonder if there are any three-generation families of RISKS readers? I know there are a bunch of two-generation families. PGN] ------------------------------ Date: 1 April 1996 (no fooling!) (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: UNABRIDGED Info on RISKS (comp.risks), subscriptions, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S. users on .mil or .gov domains should contact (Dennis Rears ). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, THEN please send requests to the newly automated , with first text line SUBSCRIBE or UNSUBSCRIBE [with option of E-mail address if not the same as FROM: on the same line]. INFO gets you this file. HELP gives instructions on using the Majordomo listserver in other ways, although not all are yet implemented for RISKS. CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, nonrepetitious, and without caveats on distribution. By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited noncommercial public distribution and redistribution in electronic and print form. Diversity of content is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses. Contributions will not be ACKed; the load is too great; if you feel neglected, send a follow-up message. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Particularly relevant contributions may be adapted for the RISKS sections of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. * Submissions: By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited public distribution and redistribution in electronic or other form. * Reuse: Blanket permission is hereby granted for reuse of all materials in RISKS, under the following conditions. All redistributed items must include the Risks-Forum masthead line. All reuse must be accompanied by the following statement: Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse. As a courtesy, reusers of individual items (as opposed to forwardings of entire issues) should notify the authors, and should pay particular attention to any subsequent corrections. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [yes, VL = volume, IS= issue] (Please report any format errors to Lindsay.Marshall@newcastle.ac.uk) RISKS ARCHIVES: ftp://unix.sri.com/risks if your browser accepts URLs, or ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP; Issue J of volume 18 is in that directory: "get risks-18.J". For issues of earlier volumes, "get I/risks-I.J" (where I=1 to 17, J always TWO digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory and I subdirectory; "bye" I and J are dummy variables here. REMEMBER, Unix is case sensitive; file names are lower-case only. =CarriageReturn; FTP.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username and password. Also ftp bitftp@pucc.Princeton.EDU. WAIS repository exists at server.wais.com [192.216.46.98], with DB=RISK (E-mail info@wais.com for info) or visit the web wais URL http://www.wais.com/ . Management Analytics Searcher Services (1st item) under http://all.net:8080/ also contains RISKS search services, courtesy of Fred Cohen. Use wisely. 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 PRIVACY DIGESTS: * The PRIVACY Forum is run by Lauren Weinstein, with some support from the ACM Committee on Computers and Public Policy. He manages it as a rather selectively moderated digest, somewhat akin to RISKS; it spans the full range of both technological and non-technological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the first text in the BODY of a message to: privacy-request@vortex.com You will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". Information and materials relating to the PRIVACY Forum may also be obtained from the PRIVACY Forum Archive via ftp to "ftp.vortex.com", gopher at "gopher.vortex.com", and World Wide Web via: "http://www.vortex.com". Full keyword searching of the PRIVACY Forum Archive is available through the World Wide Web access address. * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. ------------------------------ End of RISKS-FORUM Digest 18.09 ************************