Subject: RISKS DIGEST 17.88 RISKS-LIST: Risks-Forum Digest Monday 11 March 1996 Volume 17 : Issue 88 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: The risks of being unrelated twins (Tony Melius) Unluckiest lottery ``winner'' ever: risks of input errors (Christian Murphy) Rail safety controlled by satellite (David Kennedy) Yet another Trojan horse lurking in Netscape 2.0... (Jon Reeves) Netscape's too-lenient syntax checking (Henry G. Baker) Re: CIA & NSA run remailers (Raph Levien) Locking the key inside (Arthur Marsh) Backdoors, bugs, and Oracle [Identity withheld] Over 10,000 sites running nonsecure versions of NCSA web server (Mike Prettejohn) Re: Teen convicted on mismatched metadata (Jack Campin) Re: Teen convicted: a similar example (Joel Garry) Signs of Intelligent Life (Mark Thorson) Solving the year problem through 3979 [old style] (David desJardins) Causes of leap-year difficulties (Jeff Mantei) Re: bleep-year (F. Barry Mulligan, John Oram) Time, days, and water (Chris J. Phoenix) Year 2000 and Unix `struct tm' (Paul Eggert) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 11 Mar 1996 18:04:48 AEST- From: tonym@gil.com.au Subject: The risks of being unrelated twins The following article, accompanied by a photograph of the two women, appeared in *The Sunday Mail* in Queensland, Australia, on March 10, 1996: Hey, Belinda, meet Belinda They could not look more at odds, but these two women are "twins" locked in a bureaucratic nightmare. Banks, building societies, government agencies, the Electoral Commission and even the local library cannot tell them apart. When one went for a loan, the other found her credit cancelled. When one enrolled in university she was offered the other's completed degree. Though one is an Aborigine with melting dark eyes and curly brown hair and the other a straight-haired, blue-eyed blonde, computers across Australia refuse to accept they are not one and the same person. The problem is not simply that they bear the identical name: Belinda Lee Perry. Even more uncannily, B1 and B2 have the same date of birth January 7, 1969. The two Belindas stretch the bounds of mathematical probability. Sports betting agency Centrebet figures the odds against such a biographical collision are five million to one. The first time blonde Belinda suspected she might have a double was back when she was still in high school. A mix-up at the Medicare office had her with a broken arm instead of an injured hand. The next problem arose when blonde Belinda, who was born and raised at Caves Beach near Newcastle in NSW, tried to claim social security benefits. The CES [Commonwealth Employment Service] already had her on the books. The following year the other Belinda joined the City of Sydney library and suddenly her namesake found her library card cancelled because the computer recognised only one Belinda Lee Perry. Blonde Belinda then had her name struck off the electoral roll after the other Belinda changed address. But brunette Belinda also had problems. She had applied for an Abstudy (Aboriginal Studies) grant and was informed she already had an Austudy loan. Later she was sent a bill for $3000. And blonde Belinda has been unable to transfer her Visa card to another bank because of the "twin" mix-up. But, despite the difficulties, the two women hit it off from the moment they met. "It's like we're related," they both said. [The risk? With an Australian population of around eighteen million, and odds of one in five million, where is the *third* Belinda Lee Perry born on January 7, 1969? TM] Tony Melius tonym@gil.com.au azmel0@qed.qld.gov.au +61 18 872 592 ------------------------------ Date: Mon, 11 Mar 1996 20:29:23 +0100 From: Christian Murphy Subject: Unluckiest lottery ``winner'' ever: risks of input errors I read somewhere that the chances of winning the lottery are the same whether you enter or not. According to a report in the Irish Times (February the 24th -- I get mine sent to me in Munich) a man is suing the National Lottery for payment of 250 000 Irish pounds (nearly 400 000 US dollars) because his winning lotto panel was not entered into the system. The man submitted 32 panels of numbers, but one of the panels was entered twice, so the winning panel was left out. He has little chance of winning his case, as each lotto receipt bears the warning "Before leaving the Lotto agent's premises, check the numbers on your tickets..." The risk? People forget that the probability of the agent miskeying your numbers is much greater than the probability of winning the lottery, even (especially?) if you submit 32 panels at once. The best way to avoid the risk is not to play, of course. I'm waiting patiently for a (misaddressed) lotto cheque to drop in my mail box any day now... ------------------------------ Date: 11 Mar 96 01:17:28 EST From: 76702.3557@compuserve.com (David Kennedy, NCSA SysOp) Subject: Rail safety controlled by satellite [PGN Abstracting of an AP article, Courtesy of Associated Press and CompuServe's Executive News Service:] Use of the Air Force's satellite-aided navigation system is being proposed for keeping track of trains throughout the U.S. The system would sound warnings to train engineers if inter-train distances were too small, and would actively cause trains to slow down or stop if it anticipated an imminent collision. `Because the satellite would establish locations with greater accuracy, trains could travel faster and closer to one another than the widely varying guidelines being used today.' ``Before making a commitment to something like this, you really have to make sure it works,'' said Tom White, spokesman for the American Association of Railroads. [Who is YOU, White-man? Wow, the potential risks here are fascinating, but beyond the scope of my habitual interstitiation. This is intended not to prompt further discussion here, but rather to alert you all to this possibility. PGN] ------------------------------ Date: Mon, 11 Mar 1996 13:41:04 -0500 From: Jon Reeves Subject: Yet another Trojan horse lurking in Netscape 2.0... I noticed, while loading a web page, that there was a mailto: URL active (using the "Easter Egg" Ctrl-Alt-T popup to see active URLs). Sure enough, after I cancelled that and examined the source, I saw something like this:
A quick test on my local machine shows that this will send a message to nasty@secret.org with the subject gotcha and the body "hi=there". This is insidious; it means that E-mail messages, purportedly from me (and all traces will show they really are from me) can be sent anywhere, without my knowledge, with contents that I do not approve. Further, it means that I can no longer count on browsing a site without my userid being disclosed. Unlike Java, there is no way to disable this. [Also been submitted to Netscape.] ------------------------------ Date: Sat, 9 Mar 1996 07:51:22 -0800 (PST) From: hbaker@netcom.com (Henry G. Baker) Subject: Netscape's too-lenient syntax checking > From: [webmaster @ affected site] > RE: Re: [site name deleted] Web Link > From [frustrated web site visitor] > > The main link to [site name deleted] doesn't > > work through 'lynx' because the html is not > > correct. The ' > link is never terminated with '', so that > > the [site name deleted] link won't work. > > Could you please look at this problem, and > > send me a message when it is fixed. > > Thanks very much. > > Thanks for the input. The mistake was never noticed before because the > Netscape browsers are smart enough to detect the error and deal with it. > Lynx, however, is not. The problem is fixed, although I don't recommend > looking at the site with anything but Netscape 1.1N and higher. We > incorporate too many of Netscape's features to make viewing these pages > without it useful. I have nothing against Netscape trying to be smart, but the very sloppiness that makes it behave reasonably for unreasonable input leads web page designers to believe that their web pages have been debugged if they work correctly on Netscape. Perhaps Netscape should have a `careful' mode for helping web page maintainers to provide `squeaky clean' pages. I have found numerous web page problems with Lynx in this way, and when informed of these problems, some web page maintainers have been downright snotty in their responses. Their attitude seems to be `it serves you right for not using a graphical browser like Netscape'. Perhaps the web site designers should wake up to the fact that most of the sophisticated web surfers that I know either use an ascii browser like Lynx, or turn off image loading when surfing, because they actually want to visit more than one web site per day. All those pretty 4-color _buttons_ (??) that they use look good for _one_ visit, and thereafter become the source of a lot of irritation due to slow page loading. Henry Baker www/ftp directory: ftp.netcom.com:/pub/hb/hbaker/home.html ------------------------------ Date: Mon, 11 Mar 1996 13:42:55 -0800 From: Raph Levien Subject: Re: CIA & NSA run remailers (Mayer-Schoenberger, RISKS-17.87) As the maintainer of a remailer-list, I felt I should respond to this. Strassmann and Marlow have lately been getting quite a bit of press spreading anti-remailer fear, uncertainty and doubt. Almost all of it is inaccurate. It is certainly possible that governments are running remailers. Personally, I tend to doubt it, but that's just because I know most of the remailer operators. Even if governments were running remailers, the use of a chain of remailers, rather than just one, protects against compromise of identity even if one or more remailers are compromised. It suffices that one of the remailers in the chain is honest. It certainly isn't the case that the most popular remailers in France and Germany are run by government agencies. Maybe if there were remailers in these countries, they would be, but there aren't. There used to be one in Germany, but it's no longer operating. There's never been one in France. If there were, it would be quite illegal, due to the French crypto restrictions. The ability to crack 1000-bit keys would represent a major advance in factoring technology. 1024-bit keys less than an order of magnitude more effort to crack than 1000, so recommending them in face of 1000-bit keys having been cracked is ridiculous. The current record for factoring an RSA key is still RSA-129, which is only about 428 bits. Advances in factoring are expected, but most people figure 1000 bits is a long way away. [... don't forget that if you can monitor and compare the incoming and outgoing mail from an anonymous remailer, ... PGN] Remailers come in three different grades of security, depending on how sophisticated a client is used. Low grade remailers, including the popular anon.penet.fi, are subject to simple comparison of incoming and outgoing messages. So-called type-1 remailers use PGP encryption, so they are not vulnerable to this attack, but can be analyzed by correlating the size of incoming and outgoing messages. The Mixmaster remailers, by Lance Cottrell, are based on David Chaum's original digital-mix theory, and can't be size-correlated either. I can't guarantee that the remailer network is secure, but I feel that ease-of-use, reliability, and vulnerability to spamming are greater concerns at this point. Not to mention misinformation. Raph Levien ------------------------------ Date: Sun, 10 Mar 1996 05:14:53 +1030 (CST) From: "Arthur Marsh" Subject: Locking the key inside Where I work, a security grille is opened and closed by means of a remote control unit. As the grille can be closed by a short press of a button on the remote control unit, it is quite possible to accidentally end up with the operator on the outside of a closed security grille with the remote control unit left locked inside. I did that yesterday morning. For all the complexity of the situation, I had simply locked a "key" - the remote control unit - inside the secured area. After puzzling over the situation, I came up with the specific solution that a remote control to close or lock a device shouldn't proceed to completion unless the control is held on by the operator. (That kind of safeguard is like not being able to lock something from outside without the key). For the software analogy, imagine the situation when new bootstrap or operating system code is loaded. If the new code fails to load or work for any reason, there needs to be a means of booting from the old code. In the software analogy the "key" is the bootstrap or operating system kernel and code that make a computer, modem or other device work: one doesn't want to let go of or throw away the old "key" until the new "key" is safely written to non-volatile storage media and known to work. To allow the user to delete the old code (especially inadvertently) without the new code working is undesirable, yet some modems with user-upgradable firmware don't protect the user against such behaviour. No doubt many RISKs readers have had similar experiences with software upgrades of many kinds... Arthur Marsh +61-8-370-2365 fax +61-8-223-5082 arthur@dircsa.org.au ------------------------------ Date: Sat, 9 Mar 96 18:13:05 CST From: [Identity withheld by request] Subject: Backdoors, bugs, and Oracle On 22 Jun 1995, I reported a "flaw" with Oracle7 and its ALTER USER instruction that enabled any userid beginning with "sys" to "ALTER USER SYS IDENTIFIED BY ", giving complete system permission to ordinary users. Amazingly, the command would fail for any user except "sys". I sent a notice to our Oracle contact and they fixed the problem in minutes (over the phone). I discovered the problem in release 7.1.4 and it is no longer present in 7.2.3. When I upgraded to 7.2.3, I noticed another "feature" (new to me anyway) "ALTER SESSION SET CURRENT_SCHEMA= ". It's a nifty little command that allows you to change ids without a password (the import utility uses it). Anyway, during a restore (disk failures), I noticed that any user could use the "ALTER SESSION" instruction regardless of whether they had been granted that privilege or not. I breathed a sigh of relief when it seemed that "actual" authorities were enforced based upon the real userid. Whew! But, it sure does make me wonder if I haven't looked hard enough. This reminded me of the Oracle6 export utility and how it placed passwords for database links in plaintext. Oracle 6 and 7 database files contain plaintext strings. All of this is ok if you simply change the permissions on files, directories, or file systems (as Oracle recommends). One other thing that was a neat idea on Oracle's part, using a userid "scott" with the password "tiger" to install the demos to. Unfortunately, I've seen too many systems that either did not disable the account when finished, or that actually gave total permissions to "scott". Ouch. There have even been a few cases of the "system" password still being "manager" from the install. I think Oracle has an excellent RDBMS. It performs quite well, and I've survived many failures (knock on wood). I I haven't used anything else in a while, so I relate only to Oracle. Anyway, the risks... With any large, complex sets of software "bugs" might silently hide, backdoors can remain undetected, and a whole lot is handled without any human intervention. Oracle has had its share of bugs and they have been good about correcting it in some way. The "backdoors" have implications that go beyond Oracle... ------------------------------ Date: 11 Mar 96 11:52:22 GMT From: mhp@netcraft.co.uk (Mike Prettejohn) Subject: Over 10,000 sites running nonsecure versions of NCSA web server [Long message abstracted for RISKS by PGN:] Netcraft collected the dataset for the March Web Server Survey over the period 1-2 March. Among the sites responding, 10678 hosts were running NCSA/1.3 or an earlier version of the NCSA server, known over a year ago to have serious security flaws for which a patch was offered at that time; .edu, .com, .gov, and .mil sites are among those using flawed versions. Details of the problem, demo program, and recommendations, are available . The current versions of both NCSA and Apache are freely available, have log file compatibility with NCSA/1.3, and -- so far as we are aware -- no one has published details of security weaknesses in either. Mike Prettejohn mhp@netcraft.co.uk Phone +44 1225 447500 Fax +44 1225 448600 Netcraft Rockfield House Granville Road Bath BA1 9BQ England ------------------------------ Date: Sat, 9 Mar 1996 14:23:10 +0000 From: Jack Campin Subject: Re: Teen convicted on mismatched metadata (Jewell, RISKS-17.87) The problem wasn't simply due to the compact representation, but also to the fact that the data required to interpret it was separated from the offence record. An awesomely large-scale foulup of the same nature was reported here a few years ago; the police in Paris did their routine mailing of citations for traffic offences, where the decoding information was kept on a separate magnetic tape. But this time someone had loaded the wrong tape; one containing codes for serious criminal offences. The result was that thousands of people charged with double parking or running red lights were sent documents accusing them of kidnapping or attempted murder; along with demands for payment of trivial fines. (One of the more popular charges was "illegal handling of veterinary products", if I remember right). Both examples are elementary failures of database design and management, and there's been no excuse for them for 30-odd years. "Lack of redundancy" is exactly what relational normalization is *for*, and if done right it can only be beneficial. jack@purr.demon.co.uk - Jack Campin, 2 Haddington Place, Edinburgh EH7 4AE ------------------------------ Date: Mon, 11 Mar 96 08:12:04 -0800 From: rossix!amber.dnet!joelga@openlink.one-o.com (Joel Garry) Subject: Re: Teen convicted: a similar example (Jewell, RISKS-17.87) Normalization is not bad design. It is good design, according to a substantial body of relational database design literature. Basically, you want to use the smallest non-ambiguous code set for internal storage, then use those codes to reference a human readable display code. The risk is not bad design, but rather inconsistent code definition across systems. I have suffered from this as well. I received a ticket for riding a bicycle in a no bike riding zone, that was explicitly _not_ supposed to affect my driving record. It did, however, because the motor vehicle department computers saw a non-recognized code propagated from the city computers, and assumed it was something bad, rather than something innocuous or null. I had to take several days off work and run around between various courthouses to fix the problem. This shows the added risk of lost productivity due to knowledgeable people being affected by stupid computer systems and quixotically wanting to make the data good. Chris also seems to have missed the obvious risk of fundamental systems change over time. Even only 13 years of school records is enough time for substantial change in record-keeping and perhaps even "good" systems design. I hope people don't expect $200 Gigabyte disks to last decades. Joel Garry joelga@rossinc.com ------------------------------ Date: Fri, 8 Mar 1996 20:52:54 -0800 From: eee@netcom.com (Mark Thorson) Subject: Signs of Intelligent Life The recent traffic about maintaining clock and calendar integrity led me to speculate that one of the astronomical attributes we could use to determine whether a distant solar system contained intelligent life would be if the planet most likely to support life had a rotational period that was related to its orbital period by an exact integer. I mentioned this to a friend of mine who has spent considerable time researching these issues, and he said it would be evidence of really stupid intelligent life. But I countered that maybe they just standardized on some stupid software early in their history, and that it was easier to change the rotational period of the planet than to change the software. :-) Mark Thorson (eee@netcom.com) ------------------------------ Date: Mon, 11 Mar 1996 07:33:19 -0800 From: mantei@bbs.ug.eds.com (Jeff Mantei) Subject: Causes of leap-year difficulties Step back for a moment from the host of confusion seen around the leap year issue. It seems that one root cause is the deceptive simplicity and regularity of the ordinary calendar. Human nature seems to take regular things for granted rather quickly. If it would be more complicated, more often, people would probably be more cautious and get it right. Generalizing, I see that many computer systems introduce the same kind of risk in other domains. That is, they simplify and make many activities and concepts more regular, but they can hide or postpone complexities and exceptions. When those exceptions occur, then people are typically not prepared to handle them. But what's the alternative? Maybe it's enough to acknowledge the possibly hidden costs of (over)simplifying a domain for computerization. -Jeff Mantei [Whoa! More-complicated algorithms also beget more disasters. Oversimplified algorithms beget disasters. Modest algorithms can beget disasters. That's why RISKS is here. PGN] ------------------------------ Date: 10 Mar 1996 23:12:31 -0500 From: desj@ccr-p.ida.org (David desJardins) Subject: Solving the year problem through 3979 [old style] Experts in ASCII already know how to solve the two-digit year problem: designate the years following "1999" as "19:0", "19:1", and so on. By the time we reach \255 in the `tens' position, 8-bit bytes will be a thing of the past and we can just keep going. All we've got to do is get the calendar makers on board, and we can save the world $500 billion (or whatever the latest ridiculous year-2000-reprogramming-price-quote is). Hmm, maybe I should have patented this scheme, then I could sell it for only $100 billion or so. David desJardins [David included a noncommercial reuse copyright notice in his posting. The generic risks.info file (which no longer accompanies every issue, to save space) says essentially the same thing, and so I normally truncate all such copyright notices. In this case, the only important thing is that no one else patents this wonderful idea and tries to charge David for using it. I suppose hex-based folks may have already come up with a scheme for postponing the problem for another 600 years by naming the century years 1A00, 1B00, 1C00, ..., 1H00 following 1900, but I hope not. PGN] ------------------------------ Date: Sat, 09 Mar 1996 03:17:57 -0600 (CDT) From: MULLIGAN@ACM.ORG (F. Barry Mulligan) Subject: Re: bleep-year (Tepper, RISKS-17.86) May I suggest that the underlying problem with millennial and leap-year software is a lack of incentive. Perhaps the major software firms could mutually agree that stock options awarded during the next two years be exercisable on, and only on, 29 Feb 2000. Care to guess what problem moves to the top of every project's punch-list? In the same vein, year-end bonuses should be payable only to employees of record on 01 Jan 2000. ------------------------------ Date: Fri, 8 Mar 1996 16:47:27 -0800 From: oram@unixg.ubc.ca (John Oram) Subject: Re: Bleep year (Tepper and Hadley, RISKS-17.86) >Let's just leap from December 31, 1999 straight to January 1, 2001. There is one bright spot concerning the misperceptions over the beginning of the twenty-first century: two chances for a big party. Why risk missing the true millenium? You had better hit both just to be sure. And Max Hadley wrote: >The rules for converting from a seconds count to a date and time are >arbitrary, complex, and subject to change at short notice! ... JavaScript uses a millisecond based system (since January 1, 1970). There are built-in methods for converting between dates and milliseconds, but there is an error in the Mac version - it is always a day ahead of the result yielded by the Unix and Windows JavaScript date functions. (I am fairly certain that this is a beta error and not a political statement. :) And regardless of your accuracy, you must still deal with different date formats. I am thinking of how today can be both 3/8/96 and 8/3/96, depending on your position on the globe. (That's one hell of a time zone...) John Oram ------------------------------ Date: Fri, 8 Mar 1996 18:04:59 -0800 (PST) From: "Chris J. Phoenix" Subject: Time, days, and water Fred Cohen wrote, >The solution to the leap- challenge may be to become less >obsessed with time ... Computers do many useful tasks where precise timing is crucial. We may not be obsessed with time, but deciding when to turn out a steel mold is still something we can't afford to get wrong. (A previous comp.risks told of daylight-savings time causing molten steel to be dumped on the floor.) As long as time stamps on files are used for building programs, it will be important for networked systems to be within a few seconds of each other. The solution is to store time, and do comparison and computation, using *only* the number of seconds from a fixed date. The length of a second is one of the few time of day-related things that doesn't change. "lucero" referred to Earth's rotation speeding up because of water stored in reservoirs, and mentioned an author in Geophysical Research Letters claiming that "reservoirs are the only human activity big enough to cause an appreciable change in these global phenomena." This author has apparently forgotten about global warming. If, as some predict, the ice caps melt enough to raise the sea level by several feet, this will surely make more difference than reservoirs. Chris Phoenix, cphoenix@leland.stanford.edu, 415-286-8581 ------------------------------ Date: Mon, 11 Mar 1996 11:37:01 -0800 From: Paul Eggert Subject: Year 2000 and Unix `struct tm' (Urlichs, RISKS-17.87) In Risks 17.87, Matthias Urlichs writes about the Unix `struct tm' date-time interface: IMHO, if the library is changed to return a four-digit date instead of modulo 100, not much will break Actually, it would break a lot of programs, including CVS, Emacs, gawk, expect, GCC, Ghostscript, INN, mh, perl, pine, RCS, and zoo (I just checked). There are in fact three things you can do: [1] drop the modulus nonsense and return the year in full, [2] just subtract 1900, so that the above algorithm continues to work, [3] return % 100, as before. There's only one thing to do for `struct tm', namely [2]. Unix has done [2] since the 1970s, and the C Standard and Posix both require [2]. No doubt the original Unix developers should have chosen [1] twenty years ago, but it would be unwise to change things at this late date. ------------------------------ Date: 27 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 unabridged version of RISKS 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 unabridged INFO file at RISKS-Request (send one-line message INFO to risks-request@CSL.sri.com as noted above). ------------------------------ End of RISKS-FORUM Digest 17.88 ************************