Subject: RISKS DIGEST 17.79 RISKS-LIST: Risks-Forum Digest Friday 23 February 1996 Volume 17 : Issue 79 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, etc. ***** Contents: Deep Blue - Deep Trouble (Erik Hollnagel) Dangerous C Syntax (Alasdair Rawsthorne) A future risk pays an early visit... (David Lesher) Another early year-2000 problem (Bill via Jim Sims) Netscape Navigator 2.0 exposes user's browsing history (John Robert LoVerso) Re: Java security (Marianne Mueller) For A Good Time, Type www.whitehouse.gov !! (Dave Tarabar) Risks of Contributing to Risks (Tom Comeau) Security of NASA command workstations (Kevin Maguire) Hidden information in files (John Gilliver) Re: Filenames (Was: Re: Wildcards) ("enh") Re: Wildcards on Mac (Li Gong) Re: Wildcards: IBM Windows ftp (John Haseler) Re: Wildcards: dos is consistent, unix isn't (Morten Welinder) Risk of any special character ("Rolf") ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 22 Feb 1996 08:34:06 +0100 From: Erik.Hollnagel@hrp.no (Erik Hollnagel) Subject: Deep Blue - Deep Trouble In the latest battle between man and machine, the ACM Chess Challenge between Garry Kasparov and Deep Blue, which took place in Philadelphia, 10-17 Feb 1996, the machine apparently ran into some unexpected problems. Many of these were due to improper handling of the input and output, rather than to the software itself. In the 22nd move of game four, the following happened. The description is taken from the transcript, which can be found on www.chess.ibm.park.org/deep/blue/commgm6.html; since this is a stenographic record, there may be some technical inaccuracies, but the essentials are correct. "DR. FENG: I went back and Garry is thinking I should wait there until I finish the moves. The monitor that we are using is an energy saving monitor so it went blank. So I went back and I am typing the move, A3 and somehow the A did not get recognised, it recognised it as 3. And it was a command to process number 3 and then I type F3 and the machine say I see a repetition and then say there is a beep. And it stopped beating [beeping?] after that. And then I check with the guy in the back room. They are saying that could cause the program harm and I checked with Valvo and we restart the program. Mr. Seirawan: So they had to restart the program and get it back up to speed. How much time did that cost the computer on its clock? DR. FENG: About ten minutes. And those are lost. Mr. Seirawan: Just to be clear, stay with us please, ten minutes to reboot everything and then ten minutes of lost thought time, so DEEP BLUE got hit with a 20 minute -- DR. FENG: It would have played the same any way. Mr. Seirawan: It got hit with a 20 minute penalty, it seems to me." >From the risk perspective, the situation is that we have a highly developed and very sophisticated parallel computer which is supposed to represent the state of the art, at least in chess computing. But apparently all the efforts have been lavished on the chess playing part and none on the interface or input checking. Checking the syntactical correctness of the input should be elementary, even - or particularly - in complex software systems. Woe to the student who forgets that! But what would have happened if the computer had not been playing chess, but been applied to share trading, controlling a train signalling system, a satellite, a nuclear power plant or something else where the consequences had been more severe for a third party? Erik Hollnagel, Ph.D., Principal Advisor, OECD Halden Reactor Project P. O. Box 173, N-1751 Halden, Norway +47.6918.3100 Erik.Hollnagel@hrp.no [In a language in which dairy is pronounced daily, I suppose this might be Deep Yogurt -- as they say in California. PGN] ------------------------------ Date: Fri, 23 Feb 96 13:48:41 GMT From: Alasdair Rawsthorne Subject: Dangerous C Syntax In Continental Europe, the comma is often used where anglo-saxons would use a decimal point. A continental student has just asked for help with a programming problem - the following code loops infinitely: while (fabs(some expr) > 0,001) { iterate } Is this equivalent to the Fortran DO10I = 1.10 bug? I'm just surprised not to have seen this before... Alasdair ------------------------------ Date: Thu, 22 Feb 1996 13:53:33 -0500 (EST) From: wb8foz@netcom.com (David Lesher) Subject: A future risk pays an early visit... Friends running Chameleon under Windoze recently started being unable to use mail. Every attempt to resulted in an immediate GPF. But ftp, telnet, Netscape, etc., all worked. Frantic re-installs of any & everything had NO effect at all. Chameleon Tech support was totally baffled. Further, reading mail with OTHER programs ALSO resulted in crashes. This included replacing Chameleon with Eudora, Netscrape, etc. Yet each bombed in its own module. Four weeks into this, he spotted the non-obvious cause.... The system date had jumped to 2069 & it was the date-sorting that was crashing.... I'm beginning to seriously consider that advice [Dyson?] to withdraw ALL your money on 30 Dec 1999 & keep it cash for a day or two.... ------------------------------ Date: Wed, 21 Feb 1996 13:53:04 -0500 From: simsj@esn126.scra.org (Jim Sims) Subject: Another early year-2000 problem [Forwarded] At 02:30 PM 2/19/96 PST, Bill L. wrote: There are fewer than 999 working days left until the year 2000. I know this because one day several million dollars' worth of orders `disapeared' from our manufacturing system. The problem was that we displayed only orders due within 999 working days, which happened to [reach] the first working day in the year 2000. The program basically displayed all orders with a date less than 1-2-00, of which there were none. How did we fix it you ask? Why, we changed the program to go only 500 working days into the future. [Lightly edited by PGN] ------------------------------ Date: Fri, 23 Feb 96 10:03:49 -0500 From: John Robert LoVerso Subject: Netscape Navigator 2.0 exposes user's browsing history While riding home this past Wednesday (on my accident free commuter-rail line), I came up with an approach to utilize the JavaScript "feature" of Netscape 2.0 to track a user's browsing actions. The tracking happens in real time with the user's browser dutifully sending results back to a remote server, starting from the time the user visits a page with the devious JavaScript embedded in it. It can thus sniff any passwords or keys the user might use in a URL. My example version runs in a browser window that the user can see. I'm only demonstrating the vulnerability. Practically, the window can be made so small as to be invisible to the casual user. It also helps that a user isn't even informed when the HTML page they just loaded has some JavaScript code within it. Think about Netscape's new JavaScript-laden home page. The default action on startup of Netscape 2.0 is to go to that page. It could easily start off tracking your browsing actions. With the new on-line frontier being driven by advertising, the value of such a log is immense. Of course, if Netscape really wanted to do something like this, they could embed all sorts of things directly in their browser. Naturally they don't, but this is something that people often clamor about (e.g., the recent Microsoft Word and the never ending AOL controversies). As it stands, with Netscape 2.0 you cannot disable JavaScript. You can disable Java. This is an interesting choice on their part, since at least there has been a significant effort on the part of many people to justify Java's claim of security and safeness. Thousands of people have pored over the code and specifications. But, JavaScript and Java are totally different things. They share common names and syntax, but they don't share implementations. One is a byte compiled language executing in a restrictive state machine, the other is an interpreted scripting languages with vastly different properties. Compared with the thousands of people have looked at the source to Java, no one has seen JavaScript. Its specifications are defined by the implementation, which to date is solely Netscape 2.0. We're told it is "Secure. Cannot write to hard disk", which is how Java is also described. Is there enough commonality for such a comparison? It is hard to determine that a program is safe or secure after studying it. It is impossible without. My particular history tracker is the third (or fourth?) way to steal private data from a user via JavaScript. It stands out as the first one that does it in real time, reporting history as the user is browsing. In an interesting bit of irony, as I was writing the code to exploit this hole, a news article from someone at Netscape appeared noting how they has fixed 2.0 during the "beta-test" period to avoid the latest of the history stealing approaches. As it stands, JavaScript adds a viral element to HTML. I'm not sure why Netscape doesn't ship JavaScript disabled by default or why they don't alarm the user before it starts to execute, or opens up new windows. Finally, it is interesting to note that the Netscape Navigator already has the building blocks to block the execution of any JavaScript (or Java) code that doesn't come digitally signed from some trusted source. This would help provide a real safeguard against the types of attack downloaded code opens up. My JavaScript examples are at http://www.osf.org/~loverso/javascript/. John Robert LoVerso OSF Research Institute Added note: Did you ever try to teach someone the importance of keeping their ATM PIN secret, only to find that they never lock the doors to their house? A non-empty subset of the hosts who have visited my JavaScript "tracker" page run an X server with no access control enabled. ------------------------------ Date: Wed, 21 Feb 1996 20:40:10 -0800 From: Marianne.Mueller@Eng.Sun.COM (Marianne Mueller) Subject: Re: Java security (Dean, RISKS-17.77) This message is a response to the DNS spoofing attack described in Drew Dean's IEEE Security and Privacy paper, referred to by Drew Dean in his RISKS-17.77 posting as being in http://www.cs.princeton.edu/~ddean/java/ . Background A bit of background on DNS: (apologies for the oversimplification) DNS is the internet "Domain Name Service". It provides the mapping between computer names and computer addresses. For example, the name ds.internic.net has the 3 IP addresses, 198.49.45.10, 192.20.239.132, and 204.179.186.65. Probably, each IP address eventually is mapped onto a different computer, although multiple IP addresses could also map onto a single computer. The reason for many-to-many name-to-address mappings is that it enables system administrators to balance the network load on their machines. The name ds.internic.net is probably accessed hundreds of thousands of times every day by people all over the network, so it makes sense for that one name to be served by multiple machines with multiple IP addresses. Let's use the term "DNS spoofing" to mean that a computer on the internet has been able to advertise a false IP address for itself. DNS spoofing isn't directly related to Java, but might be used as part of a Java attack applet. Attack The attack scenario is like so. 1) The machine evil.hacker.com advertises two IP addresses for itself, the real IP address for that machine (say 1.1.1.1) and a fake IP address for that machine (say 6.6.6.6). The fake IP address is actually the address of target.com, which is the computer the attack applet wants to try to connect to, later on. 2) Someone using a Java-powered browser loads an applet from evil.hacker.com. Now, applets are allowed to make network connections only to the machine they came from, which in this case is evil.hacker.com. However, this attack applet tries to open a connection to the computer named "target.com". 3) The applet security manager does a DNS lookup on the name target.com, and checks if its IP address is in the pool of IP addresses that this applet is allowed to connect to. It gets the address 6.6.6.6. It turns out that this is one of the two addresses associated with evil.hacker.com, and so the connection is allowed. The connection should not be allowed. Why is this attack possible? There are two reasons why this DNS Spoofing attack works: 1) It's relatively easy for someone to advertise false IP addresses. That is, it's relatively easy for someone to run their own domain name resolver. 2) The applet security manager allows an applet to connect to any of the IP addresses associated with the name of the computer that it came from. What's the fix? The right solution for this problem is to make the Domain Name Service more secure. It shouldn't be so easy for anyone to advertise false names or false addresses. A fix for the applet security manager is to be more strict about deciding which computers an applet is allowed to connect to. The Java system needs to take note of the actual IP address that the applet truly came from (getting that numerical address from the applet's packets, as the applet is being loaded), and thereafter only allow the applet to connect to that exact same numerical address. Additionally, the Java system could be even stricter than that, by declaring that an applet can only connect to the same port number that it came from, in addition to only being allowed to connect to the same IP address that it came from. What's the bottom line for me today? An applet on its own cannot carry out this attack. It would have to be working in conjunction with a hacked DNS server owned and ascribed to some domain. Also, the attack applet would have to know the name and IP address of machines inside a corporate firewall, in order to try to establish a connection to machines behind the firewall. Sun will be distributing a patch to the applet security manager to implement the more rigorous checking described above. That fix will be available within a few days, and it will be distributed in source code and in bytecode format. ------------------------------ Date: Thu, 22 Feb 1996 08:47:41 -0500 From: dtarabar@systemsoft.com (Dave Tarabar) Subject: For A Good Time, Type www.whitehouse.gov !! *The Boston Globe*, 22 Feb 1996, reports that Socks the cat appears to be running an objectionable web site at the White House. Surfwatch is a commercial product that attempts to protect the user from objectionable content available on the Internet. Apparently it works by searching for `hot' words. On the White House Web pages, Socks the cat has a virtual tour of the White House and one stop on the tour contains the word `couples'. This got that page on the tour blocked by Surfwatch. Responsible adults may judge for themselves at http://www.whitehouse.gov/WH/kids/html/couples.html Dave Tarabar, SystemSoft Corp., 2 Vision Drive, Natick, MA 01760 508-647-2952 dtarabar@systemsoft.com [Other filters have tripped on this one, but somehow have not get made it into RISKS. The *San Francisco Chronicle* a while back showed a web page with four photos -- of the Pres and VP and their wives -- that was censored by one of the service providers because of the offensive word "couples". Will RISKS now be so censored because of this item? Stay tooned, he said, comically. PGN] ------------------------------ Date: Fri, 23 Feb 1996 13:00:53 EST From: "Tom Comeau @ Space Telescope Science Institute" Subject: Risks of Contributing to Risks Recently (RISKS-17.70, item 1) I contributed a short article on the risks associated with an automated train-control system. A few weeks prior to that I had contributed a joke about French nuclear testing to rec.humor.funny. I'm also subscribed to the SCRNWRIT mailing list, and regularly make contributions. Brian Lynch reminded us (in RISKS-17.78, item 3) of some of the Risks of not thinking before submitting, but I have been rather nastily reminded of another. After both news postings, I received several rather nasty e-mail messages questioning my intelligence, heritage, and character. One response to the RISKS article suggested I was an idiot for not recognizing that only a moron would leave a speeding train under automatic control. (Which ignores several decades of psychological research on the willingness of people to submit to authority figures, such as the supervisor who refused permission to switch to manual.) The responses to the joke were even nastier. One writer suggested that people like me were "threatening the safety of the Free World" with such comments. (He probably could not know that I approve of the testing regime as important to the French weapons safety program.) While this hasn't risen to the level of threatening phone calls reported in RISKS-17.75, item 5, my office phone number was (until recently) included in my .sig files, so it is certainly possible that things could get that out of hand. I have made contributions in print media (for example, Letters to the Editors of both Newsweek and Playboy) but those have included only general information, such as a name and city. A determined attacker could still find me, but the ease of replying to electronic postings seems to encourage immediate attacks. Playboy now prints the e-mail addresses of people who send electronic Letters to the Editor. If I send Playboy anything in the future, I will be sure to send it on paper. I supposed I could stop contributing electronically, or ask that any contributions be anonymous. However, among the few flames were some thoughtful comments (and one kind correction) that I am loathe to forgo. The main Risks seem to be the ease and immediacy of electronic attacks, and the ability (using DejaNews, etc) of the disgruntled to gather additional details about a person with whom they disagree. This is not really news to veterans of Usenet newsgroups, but people contributing to any electronic forum need to be much more prepared for "flamage" than someone writing to a newspaper. Tom Comeau Computer Scientist, Space Telescope Science Institute ------------------------------ Date: 22 Feb 1996 22:20:15 GMT From: maguire@tina.jpl.nasa.gov (Kevin Maguire) Subject: Security of NASA command workstations Re: Lack of Common Sense is Biggest Risk Of All (Gunderson, RISKS-17.73) At least at JPL, there's an enormous difference between the security procedures applied to the personal workstations and the flight workstations. I won't go into any details, to avoid giving anyone hints, but when a new procedure was put into place for access to the secure machines, my first attempt to log into the secure machines failed due to a misundertannding about the procedure. I got a phone call from the SAs within 6 hours, checking to make sure the series of failed attempts was indeed me. Kevin Maguire Kevin.P.Maguire@jpl.nasa.gov ------------------------------ Date: Fri, 23 Feb 1996 11:20:18 +0000 (GMT) From: john.gilliver@gecm.com (John Gilliver) Subject: Hidden information in files (was WORD risks) The problem of files containing other information than that shown in the application which generated them certainly predates Word; I have seen such information by looking (with Xtree or similar) at various files. In particular, newsgroup postings often contain them, presumably due to people `including' files generated by their favourite WP without realizing that this would happen. Surely the problem is the original application saving more of memory than it needs, or (if the case is that garbage is picked up from the disc) incorrectly writing the file size to the directory when it does a disc write, so that subsequent reads read more than necessary? The extra information is certainly not needed to reconstitute the file. J. P. Gilliver, GEC-Marconi Research Centre, GEC-Marconi Ltd, GREAT BADDOW, Essex, CM2 8HN, UK. +44 1245 473331 x 2133 john.gilliver@gecm.com ------------------------------ Date: Thu, 22 Feb 96 08:43:08 From: enh-a@ugrad.cs.york.ac.uk Subject: Re: Filenames (Was: Re: Wildcards) If I may step back a bit from the wildcards arcana, perhaps the real risk is the notion that files are anything other than their entire contents. With MacOS, DOS/Windows and UNIX we (the humans) use filenames to identify files, while they (the computers) use serial numbers and the file contents to perform the same task. We choose to give our files names to indicate to us what the files contain. Some of us choose to give our files special names to indicate to the computer what the file contains. Now we've had two risks associated with this behaviour mentioned close together. One day it's Microsoft's Word for Windows and its virus, the next it's - oh, look - Microsoft's Windows 95 and its wildcard inconsistencies. (Interesting to note that the only complaint about UNIX's wildcarding was from someone who though ls was equivalent to dir - is this just because UNIX users are better-educated, or because UNIX is more consistent? Either way, the untrained users are the ones left with the poor tools.) But I want to consider the claim that the problem with OSes that offer a command-line is that they "require an equivalent amount of understanding of the inner workings of the operating system," which "may be unreasonable in an era of pervasive personal computing." What alternative can we go out and buy? Does using icons in preference to text help? The visual wildcarding is performed in one (terribly inconsistent) place - my brain. And I see files that look similar, and get the wrong one. Because if they *look* the same, then they obviously *are* the same. Does clicking rather than typing help? I can click quicker than I can type. And I can usually select all or "lasso" a group. So I don't use wildcards as much, and only resort to a shell when I want rid of all the files ending in .o (lasso-ing files with similar endings is harder than those with similar beginnings). So I'm less likely to abbreviate and make mistakes. But I make still make mistakes. They're just different mistakes. Off-by-one errors and accidental inclusions/exclusions of previous selections are hard to imagine at the shell prompt. Names are inadequate for describing a file's type, and they're even worse when it comes to describing a file's contents. It makes no difference whether I type a filename or click it, say it or write it (Apple do have one great product). It's the *naming* itself that's the real problem. Until we can ask our computers to "get rid of all the files that I'm never going to want ever again", there'll be trouble. But I'm not worried. I alias rm to rm -f, disable my dumpster and trust in backups. And even with such recklessness I've only ever had to ask for two files to be recovered. If you don't have a good system, make sure you get good users. - enh ------------------------------ Date: Wed, 21 Feb 1996 12:03:59 -0800 (PST) From: Li Gong Subject: Re: Wildcards on Mac (RISKS-17.78) Martin Minow described the virtue of Macintosh's two-stage delete process -- dragging a file's icon to the trash bin and then emptying the bin. However, what if I want to delete more than one file and do not want to do the drag and drop many times over (in other words, what is the equivalent to the use of wildcards)? A common solution is to select many files at one time (by holding down the Shift key and clicking on icons) and then moving them all in one go. Risks? Once I was trying to move a fair number of files (to another directory, not to the trash bin). After I had selected a few icons, I accidentally hit the space bar. In a flash all those selected files disappeared, straight to the void and not to a middle-stage trash bin. It is amusing that the largest key on a keyboard is assigned this short-cut functionality. Li Gong, SRI International, http://www.csl.sri.com/~gong/ ------------------------------ Date: Thu, 22 Feb 96 23:52 GMT From: jhaseler@cix.compulink.co.uk (John Haseler) Subject: Re: Wildcards: IBM Windows ftp I found an interesting variant on this theme. Using the IBM Windows package for FTP, I wanted to access a mainframe I never use and get a file which was supposed to have been put in my directory. The FTP package is nicely designed, with windows showing local and remote, and you select files either by typing a name or clicking, then hit on an arrow to transfer them. I was not sure what to expect nor what the file name might be, so I typed in "*" in the remote window and clicked on the arrow (I may also have given a confirming response). The PC disc seemed very busy and odd messages were flashing across the window: when I aborted, nearly every file in the current directory on the PC had been deleted. I guess the (cautious) IBM approach to transfer is this: Does the file already exist on the TO machine and directory? If so, remove it: if this works, transfer from the FROM machine. So, to transfer "*" you first delete "*" ... and to crown it all, in my case the file had NOT yet been copied for me to FTP. Result: copying all files to my machine added none and removed all. (It is possible that newer versions may be better behaved). ------------------------------ Date: Fri, 23 Feb 1996 01:00:08 +0100 From: Morten Welinder Subject: Re: Wildcards: dos is consistent, unix isn't As far as the method of handling wildcards goes msdos is consistent while unix isn't: msdos: wildcards handled by application. unix: wildcards sometimes handled by shell ("ls -l *") and sometimes by application ("find -name '*~' -print"). (And weird examples could mix those.) Due to better and more available libraries Unix usually comes out ahead, but still we have inconsistencies with respect to (say) file names starting with a dot. Morten Welinder terra@diku.dk ------------------------------ Date: Thu, 22 Feb 1996 13:58:34 +0100 From: rolf@cs.rug.nl Subject: Risk of any special character Concerning the discussion about inconsistent expansion of wildcards I can't help submitting one of my favorite mistakes in assuming program behavior. I was using "mail -f toobig" on a unix system in order to distribute emails from folder "toobig" to different folders, one of them named "important". Now, if you save *incoming mail* to a folder it gets deleted automatically (mv'ed), if you do that from a different folder it stays there (cp'ed). I'm sure there are reasons for that. Now at a certain point I considered myself very smart and typed "s important;d" assuming that was one command for saving and one for deleting to be executed one after the other. The message "Saved to 'important;d' [New file]" quickly informed me about my mistake, I repeated the action using two commands as usual, made a mental note to delete the junk file and kept going. Then the work was done, I left the "mail" program, decided to clean up and go home. Thus, I issued "rm important;d". Although it was not funny I had to laugh when I was told "d: command not found". Worst of all, I don't believe that this sort of risk can be resolved unless one wants to use a formal language for issuing commands, which I don't. And do not tell me that clicking subsubwindows makes the situation any better. Rolf ------------------------------ Date: 14 February 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) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] 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. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. 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. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://ftp.sri.com/risks PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the INFO file at RISKS-Request (one-line message INFO noted above). ------------------------------ End of RISKS-FORUM Digest 17.79 ************************