precedence: bulk Subject: RISKS DIGEST 19.01 RISKS-LIST: Risks-Forum Digest Tuesday 1 April 1997 Volume 19 : Issue 01 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: French computer systems found to be immune to Y2K problems (John O'Connor) The Year 2100 Problem: a simple solution (Martin Minow) Microsoft buys Sun (Mark Stalzer) Maybe we should start a "savoracle" e-mail address (Martin Minow) The risk of perceiving the usual as normal (Gene Wirchenko) Spry policy change causes e-mail denial (Michael Miora) Unsecure online banking (David Ross) AT&T Worldnet snafu/scam (Matt Holdrege) Free book because computers cannot lie (Mich Kabay) Re: Computer model blamed for $83 Million loss (Mark Stalzer) Re: RISKS of tracking packages (Matt Welsh) Correction for ``hard core bits'' reference (Paul Eggert) Re: all-ways green lights (Mark Brader, Steve Summit, Dik T. Winter) "Child Safety on the Internet" by Distefano (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 1 Apr 1997 0:59:59 +0100 (MET) From: "John O'Connor" Subject: French computer systems found to be immune to Y2K problems Paris, Tuesday, 1st of April 1997 The French Ministry of Informatics (MOI) today announced that they have determined that French computer systems will not be affected by the year 2000 problem. An extensive series of tests have been run on a wide range of applications within the country and on no system has a Y2K problem been apparent. A spokesman put this good fortune down to a side-effect of the French number system. In this system the number eighty is represented by the composite "quatre vingts" -- literally "four twenties." French computer systems represent the "quatre" as a single digit and will harmlessly roll over to "cinq vingts" or "five twenties" while the rest of the world collapses. Thus, "quatre vingts dix neuf" will increment to "cinq vingts." French speaking areas of Belgium and Switzerland are bemused by these developments, because they still use the older "septant, octant, nonant" system for 70, 80, and 90. The Belgian government is thought to be considering an urgent change in the language. This would provide a major boost for the less prosperous French speaking part of the country when computer systems are relocated to French speaking communes. Microsoft has announced that it will use similar techniques to guarantee the PCs will not suffer from such problems, by launching a new version of their operating system. "Windows ninety ten" is expected to be available in the year 2002. [``MOI?'', dit Mademoiselle Petite-Couchon (better known here as Miss Piggy). PGN] ------------------------------ Date: Tue, 1 Apr 1997 00:00:00 -0800 From: Martin Minow Subject: The Year 2100 Problem: a simple solution A few weeks ago, someone who used a calendar application I wrote e-mailed me a warning that the program *incorrectly* (his words) indicates that the year 2000 will be a leap year. (The application, including source, is available in several on-line archives. Use a search engine to locate mac-calendar-cs.hqx.) After explaining the entire leap-year algorithm to my correspondent, I realized that the overall year-2000 problem is just the tip of the software-bug iceberg. For example, in the year 2100, software using a popular oversimplified algorithm that computes leap years as "year evenly divisible by 4" will break for the first time since 1900 [when there were no computers doing this kind of calendar arithmetic anyway]. Since, by that time, software will be even more difficult to fix than it is today, I humbly propose that it would be simpler to fix the erroneous definition of the "second" than to fix the software. According to my calculations, by lengthening the second by only 0.00001312449483, which surely will be not noticeable, leap-years will occur every four years without the clumsy and error-prone corrections necessitated by the poor mathematical abilities of medieval monks. (Recall that the meter was recently changed so that the speed of light is exactly 3,000,000 meters/second). Because adjusting the duration of the second will lead to a considerable simplification of date-conversion software, and an elimination of a source of considerable confusion and error, it would be well worth the minor disruption (barely a second a day) that this might cause to existing, old-fashioned, analog timekeepers that can't keep time that accurately anyway. Of course, the length of the meter would have to be changed again. Martin Minow minow@apple.com [Martin's proposed solution seems very timely(!), and incurs *no* software costs -- in contrast to the Y2K problem, with estimates of fixes running in billions (and trillions?) of dollars worldwide. Incidentally, newer readers with foresight might go back and visit RISKS-17.83 and 84, noting that the length of a tropical year is (at present) 365.24219 days. Barry Jaspan suggested that the correction of making every 4000 years *not* a leap-year gives a closer approximation. Alternatively, Jan Vorbrueggen suggested that years divisible by 2000 would not be leap years unless divisible by 4000, and years divisible by 16000 would not be leap years unless divisible by 400,000, which averages out to 365.24219 days per year. Of course, by the year 400,000 the length of the tropical year will have changed. However, even if Martin's solution has to be tuned once in a rare while, it would never require any software changes. Think of the savings! On the other hand, what are the odds that there will still be a Risks Forum issue on 1 April in the year 400,000, and that it will still be devoted to recently discovered risks involving calendar arithmetic? PGN] ------------------------------ Date: Mon, 31 Mar 1997 17:04:01 -0800 From: mas@acm.org (Mark Stalzer) Subject: Microsoft buys Sun This item may be of some interest to RISKS readers, given all of the discussions about ActiveX and Java. -- Mark - - - - - - - - - - - - - - - Redmond WA, March 31 (Routers) - Microsoft Corporation announced after the close today that it will buy Sun Microsystems in a deal valued at $11.7 billion. The price works out to $50 a share, which is a premium over Sun's close at $34. Microsoft will finance the deal by issuing 50 million shares of common stock, using some of its cash reserves, and borrowing $5 billion at "very low rates" from a "long time strategic partner" rumored to be Intel Corporation. Every 4 shares of Sun stock will be exchanged for 1 share of newly issued Microsoft stock plus approximately $100 in cash. Bill Gates, Microsoft's Chairman said "It's time to kill Unix. Unix is providing stiff competition to Windows NT in the server arena. We have already placed NT on Digital and HP servers, and Sun was the only substantial holdout. So we decided just to purchase Sun to assure that their servers ship with NT." He continued, "We also wanted control over Java to better position ourselves to, uh, compete with Netscape." The deal was approved earlier today by the boards of both companies. Large institutional holders of Sun are known to favor the deal so it should get shareholder approval in the coming weeks. Privately, a Sun board member said "the price was so sweet, we would be violating our responsibility to the shareholders if we didn't accept the offer." Scott McNealy, Chief Executive Officer of Sun, was unavailable for comment. Several Sun employees expressed dismay, one adding simply that "this sucks." When asked about transition plans for Solaris, Sun's version of Unix, Taj Raji, Sun's Vice President of Systems Software, said that the "Solaris APIs will be wrapped around the NT megakernel in a seamless fashion to produce a robust feature-rich operating environment." A Microsoft spokesperson quickly added that "only native NT applications certified by Microsoft get to use the flying windows logo." Speculation about Intel's possible involvement centered on the SPARC chips that power Sun's servers. Intel might incorporate the SPARC architecture into their planned Hexium "You're Inside" family of processors. If these chips were used in Sun servers, analysts say that Intel would lock up the worldwide processor market. As for Sun's Java technology, if Microsoft follows their standard practice, they will make proprietary enhancements to assure market share. One insider suggested that they might make "Java more like C++", but others said that would be foolish. April Austin, a technology analyst with Hambust-Quick in Oakland CA, commented that "the buyout could really put a crimp on Netscape since Microsoft will control the two major means of placing active content on the web, ActiveX and Java. Microsoft will set the standards and Netscape will always be six months behind the feature curve." A spokesperson for the Department of Justice said there was no official comment on the proposed transaction. Although, a highly placed Justice source felt that there shouldn't be any problems because "Microsoft is a software company and Sun is a hardware company." The combined company's yearly sales will be approximately $16 billion based on end-of-year figures. For the day, Microsoft (MSFT.O) was up 1 5/8 at 97 7/8 and Sun (SUNW.O) was up 3 3/4 at 34. Officials at the Pacific Stock Exchange reported that the volume on Sun April 30 calls was 15 times normal. The SEC is investigating possible insider trading. ------------------------------ Date: Mon, 31 Mar 1997 10:07:31 -0800 From: Martin Minow Subject: Maybe we should start a "savoracle" e-mail address >From http://www.macintouch.com "The e-mail address we first reported for feedback on Larry Ellison's Apple takeover idea [saveapple@us.oracle.com] did not work, apparently due to an 8-character limitation in Oracle's e-mail system. The revised address is savapple@us.oracle.com ." Noted without further comment by Martin Minow minow@apple.com [I suppose they should have indirected it through Oracle@Delphi.com, which Greek legend tells us could have interpreted the address wisely. PGN] ------------------------------ Date: Fri, 28 Mar 1997 02:16:52 GMT From: genew@vip.net (Gene Wirchenko) Subject: The risk of perceiving the usual as normal Not too long ago, I moved from Vancouver, BC to Penticton, BC. It then being long distance to Vancouver, I needed to change my ISP. I did this. On the new ISP, the newsgroup service was flaky. How did I know about the flakiness? Simple. I continued with the same newsgroups that I had been using and noted a marked drop in volume as well as seeing responses to messages which I hadn't gotten. The latter had happened but rarely before. I was told I was the only one to complain. (Remember that Customer Service critters can always say this at least once (the first time).) It took some convincing on my part to get them to see it, but now they are looking at how to get out of their existing newsgroup feed contract. The risk here is getting used to a state and thinking that state normal. If I had just signed up in Penticton, I might never have noted anything out of the ordinary. Apparently, that's what has been happening. Gene Wirchenko ------------------------------ Date: Fri, 28 Mar 1997 10:06:25 -0800 From: Michael Miora Subject: Spry policy change causes e-mail denial Until last week, I used Sprynet as my ISP. They provided me with SMTP services (I have my own POP server) and Newsgroup services. Sometime last week, at a time and date nobody at Spry would or could divulge, Spry instituted a new policy: server access would be denied to anybody using a non "@sprynet.com" return address. This included SMTP and Newsgroup servers, along with unspecified other servers. The result of this unannounced policy change was that anyone with either his/her own domain name or using other external, ISP-independent addresses lost e-mail, newsgroup, and other unspecified services. We received unintelligible error messages from the Newsgroup servers. We received occasional e-mail returns with the message, "External server access denied." Not all e-mail was returned this way, some was simply discarded. In all cases, the time-to-return was unpredictable, in one case exceeding 12 hours. When the errors began occurring regularly, I tried contacting Spry tech support and customer service. The long distance numbers had wait times estimated at 20-30 minutes. After 45 minutes, I hung up. I connected to the IRC "chat.sprynet.com#spryhelp" and was told of this new policy. When I explained the implications, they replied: "Sorry, those are the rules. We are not responsible." They are quite correct, they are not responsible. This unannounced change on a system was a de facto denial of service attack on many legitimate users. Spry's explanation was that their SMTP and Newsgroup servers were being used by non-Sprynet subscribers and that this rule-based authentication was their only way of eliminating unauthorized use, given that these servers did not support log in protocols. I wonder how many of these "unauthorized" users were legitimate Spry customers with non-Sprynet addresses. Michael Miora, Miora Systems Consulting, Inc. mmiora@miora.com; http://www.miora.com ------------------------------ Date: Thu, 20 Mar 1997 21:18:31 -0800 From: David Ross Subject: Unsecure online banking Western Federal Credit Union (WFCU) at http://www.western.org/ provides for home banking over a supposedly secure Web site. Several problems plague this site. On entering the Home Banking site, a popup notifies the user that a secure document has been requested. The popup has no cancel capability; the Cancel button is deactivated. The user has to continue to the login page and then select a link to return to the home page. If the user continues by logging in, a total of seven "going secure" popups appear even though the site does not go insecure once. An error in the use of RSA tools is strongly indicated. Once within the secure site, the user sees an Exit button. Selecting that button returns the user to the WFCU home page without leaving the secure mode. The user is then on a Web page for which security cannot be justified. Selecting the link to the menu page (there being little else on the home page), the user remains in secure mode, still for no reason. For the user to return to insecure mode requires selecting the user's home page. This is definitely contrary to proper use of the RSA tools and indicates a lack of proper verification of the design of the Web site. This problem was reported to WFCU's Webmaster along with a request that users be notified of potential security failures caused by software incorrectly using RSA tools. A week later, the problem still exists; no user warning has been posted on the Web site. By the way, WFCU is the successor of SDC Federal Credit Union. The latter was the credit union for the employees of System Development Corporation (SDC), the company that initially established computer programming as a discipline distinct from designing and building computer hardware. Before then, the only people who programmed were the engineers who custom-built the computers. Somehow, I expected more from WFCU, given this heritage. David E. Ross http://www.geocities.com/CapitolHill/6727/index.html ------------------------------ Date: Mon, 31 Mar 1997 18:19:09 -0500 (EST) From: Matt Holdrege Subject: AT&T Worldnet snafu/scam Like many people, I signed up for AT&T Worldnet back when they first announced free Internet access for up to 5 hours per month. Also like many others, I decided I didn't like the service and stopped using it. I thought that AT&T being a reputable company would not give me any problems. Today I received a card in the mail saying that my introductory year is almost over and I need to choose which rate plan to use. I can choose unlimited for $19.95 per month or hourly for $4.95 per month plus usage. It says if I do nothing, I will automatically stay in the hourly plan and be billed $4.95 per month. There is no phone number to call to complain, nor is there an e-mail box listed. I tried AT&T main numbers but they know nothing about Worldnet. There is an URL listed, but I tried several times today to access it and the path to it is overloaded. I'm sure if I did find out the number to call, it would also be overloaded. I will make sure somehow that I am not billed, but I wonder how many folks will be surprised with a $4.95 entry on their credit card or AT&T phone bill. Matt Holdrege holdrege@eisner.decus.org ------------------------------ Date: Fri, 28 Mar 1997 04:57:55 -0500 From: "Mich Kabay [NCSA]" Subject: Free book because computers cannot lie Another in the "Computer Can't Lie" series that we have been seeing lately in RISKS (e.g., "Telephone Scam" responses in RISKS-18.91; "Bank cannot believe it made a mistake!" in RISKS-18.92): I received an interesting book from my synagogue office -- but never ordered it. When I called the synagogue office, the secretary told me that I had registered for a course several months ago, had ordered this book, and had actually paid for it. None of the above is correct. I protested that there had been a mistake, and offered to return the book. The secretary insisted that what she had said must be true: "Look, it's in the computer -- you must have done it." I gave up and am keeping the book until further notice. When they fix their files, I'll return their book. Mich M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com ------------------------------ Date: Mon, 31 Mar 1997 13:52:34 -0800 From: stalzer@macaw.hrl.hac.com (Mark Stalzer) Subject: Re: Computer model blamed for $83 Million loss (Kaplan, RISKS-18.97) Financial models are used for a reason more fundamental than the complexity of the instrument, namely there may not be a market available to discover the instrument's price. If you want to know the price of Intel, you go to Yahoo!, type in INTC, and get the price. This works because there is a liquid market in Intel shares. The markets in common Intel derivatives (calls/puts) out to expirations of a few years are also liquid. But let's say you want to buy an Intel call that expires in 5 years. This instrument is not traded on any exchange so what's it worth? Fortunately, models exist that can price this option if you know some parameters that can be observed in the markets. For example, the most common options pricing model, Black-Scholes, needs the yield curve of the dollar (risk free interest rate vs. maturity), current price of Intel, exercise price (strike), expiration, and volatility of Intel's stock price. All of these parameters are known or can be determined from current and past market data. You drop them in and out comes a value. You can test the model against market traded instruments and tweak the parameters (mostly volatility) as necessary. The model and the market determined parameters give traders the tools to write all sorts of funny contracts at sensible prices. It's certainly true that there are much more complex instruments and the models can get quite sophisticated. Obviously, there are bugs, and the users need to be very careful. It should be said that to really blow up an investment house requires a human. Barings fell due to forgery, misappropriation of funds, illegal trades, no management oversight, all the usual stuff. The financial community is responding with increased reporting requirements and some external review over pricing models (it depends on the country, but the UK appears to lead here). I think these are good ideas, but the computer related risks are increasing. Mark Stalzer, mas@acm.org ------------------------------ Date: 27 Mar 1997 15:12:41 GMT From: mdw24@cl.cam.ac.uk (Matt Welsh) Subject: Re: RISKS of tracking packages (Ishikawa, RISKS-18.92) Chiaki Ishikawa worries about tracking a postal package delivery (over the Internet, say) without any authentication: >In any case, I can't wait to mistype a digit/letter of an assigned number >to MY package to see if it will print out someone's supposedly private info. This has happened to me - in reverse. I was once tracking a package be delivered to me by a major US parcel carrier (I believe it was UPS), using the carrier's automated tracking system via a Web page. I entered the exact parcel number that I had been given, and lo and behold - I discovered that some months earlier a package had been delivered to a particular address and signed for by a particular person ... with the same tracking number. In most cases it's difficult to invent or mistype these tracking numbers (they may use a particular encoding or checksum), but in this case I was able to learn something about someone else's private delivery using MY OWN tracking number. Apparently this carrier recycles the numbers! So many problems in this world which could be solved with proper security and authentication techniques. What's really amazing is that this technology already exists, but politics prevents us from deploying it. M. Welsh, University of Glasgow/University of Cambridge ------------------------------ Date: Thu, 27 Mar 1997 15:39:06 -0800 From: Paul Eggert Subject: Correction for ``hard core bits'' reference (Re: Nelson, RISKS-18.94) In RISKS-18.94, when writing about using hard core bits to defend against statistical attacks on cryptographic algorithms, Jeff Nelson referred to the Eurocrypt '95 paper ``Universal hash functions and hard-core bits'', but unfortunately he gave the wrong authorship for that paper. The actual author is Mats Näslund of the Royal Institute of Technology, Stockholm. You can find a copy of the paper itself at: ftp://ftp.nada.kth.se/pub/documents/Theory/Mats-Naslund/hh-ec95.ps.Z ------------------------------ Date: Mon, 31 Mar 97 15:07:58 EST From: msb@sq.com (Mark Brader) Subject: Re: all-ways green lights (DeBert, RISKS-18.94) > Probably some of the same thinking is involved as that which led > certain parties at NASA to conclude that since the seals had > eroded by x% but the shuttle hadn't crashed, x% erosion must be okay. Didn't they even say that, after all, they still had a factor of safety of (100-x)/x? (As if the erosion had been modeled and was known to proceed at a constant rate, when in fact it was completely unexpected and its behavior was, as experience showed, unpredictable.) ------------------------------ Date: Fri, 28 Mar 1997 12:23:32 -0800 (PST) From: scs@eskimo.com (Steve Summit) Subject: Re: all-ways green lights (RISKS-18.94,95) Well, shoot! I've believed (and asserted) that it was impossible, too. Not (of course) because I have any deep faith in the perfection of software, but because it was so obvious to me that the right way to build a computer-controlled traffic signal would be to have the brand-new high-tech solid-state circuitry control the actual (110VAC) signal lamps through a last stage of old-fashioned relays, configured in such a way that it's physically impossible to have two conflicting greens on at once. (In the simple case, for example, the north-south green lights and the east-west green lights could be driven by opposite poles of a double-pole, break-before-make relay). In fact, I was so sure that this was the right way to do it that I'd managed to convince myself (based on no more evidence than sheer speculation) that this *was* the way modern signals were in fact constructed. Are they not? I'm crushed. (Would I be out of place if I exhorted those reading this to use such a design in any analogous safety-critical systems they have any control over?) Steve Summit scs@eskimo.com ------------------------------ Date: Sat, 29 Mar 1997 01:47:50 GMT From: Dik.Winter@cwi.nl (Dik T. Winter) Subject: Re: all-ways green lights (RISKS-18.94,95) There are many articles about this issue. However, it was solved in the Netherlands before such a thing as a computer controlled traffic sign could emerge. The general rule is that traffic from the right has the right of way. Traffic signs do *not* overrule that general rule %. A green sign merely grants you the right to proceed while a red sign tells you that you are not allowed to proceed. So if you enter a crossing with your light green you still have to obey the general right of way rule, even if you might think that his/hers sign was red. This ruling has been upheld in the high court (or supreme court or whatever translation you want to apply). The reasoning is simply that lights can be defective, so you can not get rights from a green light because the other party may have seen no light at all. ________ * Actually there are very few rules that override it, except explicit signs and a few more. For instance, if there is a one-way road on the right so you may not expect traffic from it, if there comes traffic from it you must yield the right of way. (Of course the other party may be guilty of going in the wrong direction in a one-way street; that is a different matter.) dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ ------------------------------ Date: Mon, 31 Mar 1997 14:11:49 EST From: Rob Slade Subject: "Child Safety on the Internet" by Distefano BKCHSFIN.RVW 961128 "Child Safety on the Internet", Vince Distefano, 1997, 0-13-569468-X, U$34.95/C$48.93 %A Vince Distefano %C One Lake St., Upper Saddle River, NJ 07458 %D 1997 %G 0-13-569468-X %I Prentice Hall %O U$34.95/C$48.93 +1-201-236-7139 fax: 201-236-7131 beth_hespe@prenhall.com %P 296 %S Classroom Connect %T "Child Safety on the Internet" This volume contains a helpful and generally realistic set of resources. It talks primarily about the dangers, but does note that the risks are not as bad as some of the hype. The book does, for once, look at other "dangers" besides pornography, and has a reasonable chapter on netiquette. Online service protection options, content rating systems, and protective/support groups are discussed. In addition, there are suggestions and advice for "after the fact" detecting and policing. There are some gaps in the book. The fact that there are weaknesses, inaccuracies and misleading statements in the (now infamous) Rimm study/Time special is dismissed as "not important". The subtle censorship of Internet filter software is not discussed. (One of the filter programs on the accompanying CD-ROM blocks non-pornography or violence related terms which are germane only to discussions of certain political leanings. Filter developers will not even confirm the dictionary of words used, with some slight justification.) Most filter packages do not allow parents to tune or manage the terms to be included or excluded. copyright Robert M. Slade, 1996 BKCHSFIN.RVW 961128 roberts@decus.ca rslade@vcn.bc.ca rslade@vanisl.decus.ca ------------------------------ Date: 1 Apr 1997 (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 [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] 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 19.01 ************************