precedence: bulk Subject: Risks Digest 21.19 RISKS-LIST: Risks-Forum Digest Tuesday 9 January 2001 Volume 21 : Issue 19 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. ***** This issue is archived at and by anonymous ftp at ftp.sri.com, cd risks . Contents: Security at UK nuclear power stations (Brian Randell) Re: Revenge of Y2K, Norwegian trains halted 31 Dec 2000 (Bob Dubery) Motorola flex non-non-non-leap year (Dan Jacobson) Millennium error in Postscript calendar (Eric Lindsay) Two satellite failures (Peter B. Ladkin) Teen intercepts MD's pages, makes medical orders (Terry Carroll) Dutch Railways to introduce electronic access/ID card (Marcus de Geus) Risks of "upgrades" and network-centric applications (Jay R. Ashworth) Re: Chinook (Phil Payne, Ryan O'Connell) Re: CIOs: "What, Me Worry?" (Mark Hull-Richter) Re: Egghead.com (Jonathan Kamens, Mark Hull-Richter) Re: Y2K+1 bug in Sharp Organizer (Philip Berman, Jonathan Kamens) Re: IBM and Intel push copy protection (David Collier-Brown) Security white paper (Gene Spafford) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 9 Jan 2001 10:16:27 +0000 From: Brian Randell Subject: Security at UK nuclear power stations There is an article in today's Guardian starting: "Tough new security checks are to be imposed at nuclear power stations after a guard employed to protect the station attempted to sabotage the site's computers . . ." Apparently he was caught hacking the power station's system in June 1999 "to alter sensitive information". The full text is at http://www.guardianunlimited.co.uk/nuclear Brian Randell Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk +44 191 222 7923 [Seen by Dave Stringer-Calvert at http://news.bbc.co.uk/hi/english/uk/newsid_1107000/1107353.stm -- which notes that the guard had never been vetted and had two undisclosed criminal convictions. The Bradwell magnox reactor in Essex is the nearest nuclear power generator to London. PGN] ------------------------------ Date: Fri, 5 Jan 2001 09:13:12 +0200 From: "Bob Dubery" Subject: Re: Revenge of Y2K, Norwegian trains halted 31 Dec 2000 (RISKS-21.18) One possible cause of the inability to handle 31 Dec 2000 is a potential bug that year2000.com warned about some time ago: http://www.year2000.com/y2kcurrent1.html Usually a year spans 53 calendar weeks or part weeks. But 2000 spanned 54 weeks or part weeks. This occurs every 28 years. In 1972, computer systems and embedded code were not as pervasive as they are now. If a system has software that uses the number of the calendar week, then it may have problems on 31 Dec 2000 which is the start day (and only day) of week 54. [The year 2000 began on a Saturday and ended on a Sunday; ergo, 54 calendar weeks. PGN] ------------------------------ Date: 07 Jan 2001 06:26:43 +0800 From: Dan Jacobson Subject: Motorola flex non-non-non-leap year My Motorola flex page knows about leap years, and that every 100 years is a non leap year, and every 400 years is a non-non-leap year, but it didn't know every 1000 years is a non-non-non-leap year, well, something like that, anyways, had to set it to 1996 at the millennium. http://www.geocities.com/jidanni Tel886-4-25854780 e-mail:restore .com. ¿n¤¦¥§ ------------------------------ Date: Sat, 06 Jan 2001 20:26:22 GMT From: eric@wrevenge.com.au (Eric Lindsay) Subject: Millennium error in Postscript calendar For the decade and more I have been printing myself a monthly calendar using a free Postscript program. %! % PostScript program to draw calendar % Copyright (C) 1987 by Pipeline Associates, Inc. % Permission is granted to modify and distribute this free of charge. I checked for Y2K errors, and had no problem with the output. However it turned out the first calendar for 2001 was in error by several days. /startday { % starting day-of-week for this month /off year 3000 sub def % offset from start of "epoch" off off 4 idiv add % number of leap years off 100 idiv sub % number of centuries off 1000 idiv add % number of millennia 1 add 7 mod 7 add % offset from Jan 1 3000 /off exch def 1 1 month 1 sub { 1 copy days_month exch 1 sub get exch 2 eq isleap and { 1 add } if /off exch off add def } for off 7 mod % 0--Sunday, 1--monday, etc. } def The code was originally starting from 2000. As you can see, you can be pretty arbitrary about starting dates. However, I wonder how many other calendar programs out there are also working their way backwards from some fairly arbitrary date, rather than forwards from some date in the past? Eric Lindsay http://psiphi.server101.com/airlie Airlie Beach Qld Australia - Great Barrier Reef entry ------------------------------ Date: Sun, 07 Jan 2001 18:37:55 +0100 From: "Peter B. Ladkin" Subject: Two satellite failures "The Boeing Satellite Systems (formerly Hughes Space and Communications)- built Galaxy VII communications satellite operated by PanAmSat has stopped functioning in geostationary orbit following a spacecraft control processor (SCP) fault that has hit several sister satellites." (Flight International, 5-11 December 2000, p34, article "Control fault knocks out Galaxy" by Tim Furniss. The capitalised "G" is important.) This wasn't the first. The craft lost its first SCP in June 1998. The second SCP stopped functioning on 25 November 2000; the craft lost attitude control and its solar panels lost track of the sun. Apparently, tiny crystalline structures can grow and bridge the terminals of tin-plated relay latching switches to their case, causing a short circuit. People have known about it since a Hughes analysis in 1995 from telemetry data, but there isn't much one can do about it on satellites launched years before. "It is believed" that the builder switched to nickel plating from tin in 1997. The EarthWatch Quick Bird 1 satellite may have suffered from a computer error, causing its solar arrays to deploy while still attached to the ascending Cosmos 3M booster rocket, launched from Plesetsk on 21 November 2000, according to a report in Flight International (12-18 December 2000, p36) citing "Russian officials". The satellite was lost, which resulted in "48 employees or 24% of the work force of EarthWatch being laid off". Peter Ladkin ------------------------------ Date: Mon, 8 Jan 2001 16:13:13 -0800 (PST) From: Terry Carroll Subject: Teen intercepts MD's pages, makes medical orders AP reports that a Virginia teenager obtained a pager used by the Inova Fairfax Hospital, in Fairfax Virginia. According to the article, he then "gained access to the hospital's paging system" (the article is not clear on whether this was a hack, or what) and forwarded a physician's number to his pager. When the physician was paged, the allegedly boy returned the calls and gave the nurses medical orders, including authorizing prescriptions and minor medical procedures (such as blood tests and oxygen administration). According to the Washington Post, he is believed to have issued "about a dozen orders." Yikes. ; also, . An earlier report by the Post notes that: The court papers and hospital say that on the overnight shift of Dec. 7-8, the youth ordered 12 treatments for six patients. His orders allegedly included prescribing the blood thinner heparin and asking for blood tests and oxygen for patients. In each case, the orders were medically "appropriate under the circumstances," said Russell Seneca, chief of surgery at the hospital. Terry Carroll, Santa Clara, CA carroll@tjc.com ------------------------------ Date: Sun, 31 Dec 2000 13:31:14 GMT From: Marcus de Geus Subject: Dutch Railways to introduce electronic access/ID card On 28 Dec 2000, *De Volkskrant*, one of the leading Dutch morning papers, reported on its front page that NS, the Dutch Railways, are set to invest 3,000 million guilders (approx. 1,400 million euro) over the next decade "to improve the quality of service". The article reads like a "for your convenience" notice. One of the main items (at 1,100 million guilders) scheduled for improvement is public safety on platforms. Improved safety is to be achieved through the introduction of CCTV cameras and electronic access barriers. In time (the year 2002 is mentioned), the latter are to restrict platform access to persons carrying (and presumably, swiping) a Public Transport Chipcard, which will also act as a means of identification. The chipcard scheme alone is budgeted at 500 million guilders. One obvious risk to the public is of course the connection the scheme will provide between two hitherto distinct sets of demographics. The real-time linking of personal data to transport information will no doubt prove to be irresistible to marketeers should the scheme ever come to fruition. Another, perhaps less obvious, risk concerns the loss of quality of service resulting from such a scheme. Will incidental travelers be forced into separate queues to have their photographs taken and their personal details checked? How will incoming cross-border rail passengers be expected to cope? What happens to flight passengers arriving at Schiphol airport, one of the main transit points in the Dutch railway system? The mind boggles. Marcus de Geus http://www.degeus.com ------------------------------ Date: Tue, 9 Jan 2001 15:21:59 -0500 From: "Jay R. Ashworth" Subject: Risks of "upgrades" and network-centric applications Regular readers of RISKS will of course be familiar with the syndrome described here, but the lesson bears repeating because, apparently, some people still haven't gotten with the program. The State of Florida, in the last 3 years or so, has a) turned over all it's tele- and data-communications business to a single vendor (that this vendor is Intermedia Communications, for whom I have a personal and professional distaste isn't especially germane to this discussion) and b) replaced their vehicle registration management computer software system. (What they replaced it with was one of those horribly inefficient "make a 3270 look like Windows" things that are all the vogue these days -- with everyone except the poor front-end operators, but *that's* not directly germane, either. :-{ ) What *is* on point here is that new system (b) doesn't allow off-line transactions to be made in any fashion except by hand, on legal pads, and, of course, the network (a) failed yesterday for between 4 hours and all day, depending on which office you were in, because of "an incomplete overnight attempt to upgrade the fiber-optic communications network", according to a story in today's St Petersburg Times, at http://www.sptimes.com/News/010901/TampaBay/Technical_glitch_stal.shtml No matter *who* the carrier is, if you've only got one, you'd better have your backup plans in order. If you've only got one carrier, and you *don't* have a manual fallback option, you'd better have the number for Office Depot's delivery desk. Have *you* looked at your "emergency preparedness" binder lately? Jay R. Ashworth Baylink The Suncoast Freenet Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 ------------------------------ Date: Sat, 06 Jan 2001 12:04:39+0000 From: phil@isham-research.freeserve.co.uk Subject: Re: Chinook (RISKS-21.18) The debate about the Chinook accident continues and progress is slow. I suggest using http://www.computerweekly.co.uk and entering 'CHINOOK' as a search argument. There are many aspects of RISK. One is undoubtedly that of putting all your eggs in one basket - flying such a concentration of critical expertise in a single aircraft was reckless; the more so because they were engaged in activities so vital to anti-terrorist efforts. Another is flying a significant number of passengers in an aircraft equipped with neither a flight data recorder nor a cockpit voice recorder. This is the computing-related risk - we simply do not know what actually happened on the flight, except that 29 people died. The third was previously unknown - that serving officers of the British armed forces could be posthumously condemned for gross negligence, even though the Queen's Regulations under which they operate specifically forbid this in the absence of conclusive proof. Yes - the apparent actions of the pilots appear to contravene their training and orders. But we don't know for certain what happened on the flight, and that's the key risk the Royal Air Force ran. Many people (including a substantial number of Members of Parliament) agree that the dead officers' families should not be used as scapegoats for the authorities' use of a single aircraft and their failure to provide data and voice recording on a passenger flight, especially where specific safety concerns existed about both the particular aircraft and the type in general. Phil Payne http://www.isham-research.freeserve.co.uk ------------------------------ Date: Fri, 5 Jan 2001 08:30:25 +0000 From: "Ryan O'Connell" Subject: Re: Chinook (RISKS-21.18) The distinction between VFR and IFR is purely a civil aviation one. Military pilots are not constrained in such a way, and have a number of systems at their disposal that civil pilots do not have. > ... the crew were required to make a 180 degree turn and fly out of the > cloud. That is what they were trained to do. That is what the law required > them to do and that is what the RAF rules required them to do. This is what civil flight rules required them to do, not what RAF rules required them to do. The RAF pilots broke civil flight rules, which they are quite entitled to do. Military pilots are required to follow civil flight rules only when it does not interfere with operations. Given that the aircraft was carrying a number of prominent anti-terrorist figures and that Northern Ireland is generally regarded as a war zone as far as the military is concerned, the pilots would have been following war-time military rules and not civil flight rules. RAF jet and helicopter pilots are highly trained in "Nap of Earth" flying, which involves flying as close to the ground as possible even in adverse weather conditions and was used to great effect in the Gulf War. The Chinook would have been fitted with a terrain-following radar for exactly this purpose, which the pilots would have been using. (This is not the same system as Civil radar altimeters, military systems show the pilot the "shape" of the terrain in front of the aircraft) Flying at 1,500m (about 4000ft) above the high point would expose the aircraft to anti-aircraft fire, and is probably not within the capability of the aircraft in any event. (Chinook aircraft have a service ceiling of about 2500m, and Scotland has quite a number of large hills) It seems in this case that the RISK of flying under civil rules and being shot down was deemed greater than the RISK of flying under military rules - the military are trained to take risks, and if that judgment was incorrect it should be the officers in charge that are responsible, not the pilots. Ryan O'Connell - - http://www.complicity.co.uk ------------------------------ Date: Fri, 5 Jan 2001 17:19:19 -0800 From: Mark Hull-Richter Subject: Re: CIOs: "What, Me Worry?" (RISKS-21.18) > ... Meanwhile, a 1999 survey found that Fortune 1000 companies lost > more than $45 billion in thefts of proprietary information that > year. [*InfoWorld*, 3 Jan 2001; NewsScan Daily, 4 Jan 2001] I am HIGHLY skeptical of all claims of losses by large corporations. The Virus Myths web page (http:www.vmyths.com) is replete with examples of hyperbole and exaggerated claims of losses due to viruses and virus hoaxes without one shred of substantive evidence to back up those numbers. How does this $45 billion number come about? How does a company arrive at the amount of money they actually lost due to theft of proprietary information? (How does one quantify such a loss anyway? Was the theft before or after the information gained value by market success of the product? Either way, these numbers are all estimates since they can't be physically quantified unless a lawsuit is involved, in which case the "loss" is recoverable.) Notice at least that they didn't have the audacity to blame the losses on hacking incidents, just "theft of proprietary information." ------------------------------ Date: Mon, 8 Jan 2001 22:52:03 -0500 From: Jonathan Kamens Subject: Re: Egghead.com (Murphy, RISKS-21.18) Such a scheme would almost certainly be detected quite easily. If only 1% of the 500,000 credit card users check their statements every month and report charges they didn't make (and I imagine that in fact the percentage is higher than that; you do, don't you? I certainly do), the various credit card companies will be hit with 5,000 complaints in short order. Each credit-card company has legions of people and computers looking for patterns to detect cases of extensive fraud. Furthermore, I imagine that the various credit-card companies work together in some way to combat fraud, so their information would be pooled. Even if the number of customers reporting the bogus charges is low, surely the credit-card companies' fraud prevention algorithms will be suspicious of a new merchant suddenly ringing up tens of thousands of dollars in purchases, at least suspicious enough to flag the merchant's account for a human being to examine more closely? Merchants do *not* get their money from the credit-card companies immediately, you know. Once the fraud is detected, its pattern is usually easy to determine (the credit-card companies do, after all, have auditable trails of all charges going back for quite a long time; if the trail isn't auditable, then how does the "organized crime boss" get his money?) and the credit-card companies can recover the money from the company which placed the illegal charges on the cards. The usual strategy for preventing the bilked customers from complaining is to give the front company a name that makes it look like a pornographic Web site or telephone hotline. This is supposed to make most people too embarrassed to complain about the errant charge. I find it hard to believe that this is particularly effective, considering that we read about these failed schemes over and over in the newspapers. To pull off this kind of fraud successfully, you need to have control over a large number of mostly legitimate merchants who are willing to launder the bogus charges for you, you need to make the amounts of the bogus charges small, and you need to spread them out over time rather than charging them all at once. All of these restrictions obviously limit the amount of profit you can successfully reap from such a scheme. And even if you are successful for a time, there's always a chance that one of the credit-card companies will catch up with one of the merchants, and there's always a chance that the merchant will sing like a canary when he's supposed to be clamming up about where he got those credit-card numbers from. >[Simson Garfinkel commented: > I simply do not understand why companies insist on keeping the old > VISA/MC numbers in their computers.] Because what the focus groups tell them, over and over again, is that shopping on-line has to be fast and painless, and the faster and more painless it is, the more likely it is that customers will keep using your site. If two sites are equal in all ways except that one of them stores your credit-card number so you don't have to reenter it and the other one doesn't, the one with the stored numbers has a competitive advantage. People care more about saving thirty seconds every once in a while than they do about the remote chance that their credit-card numbers might be stolen by a hacker. I can't say that I particularly blame them. How many people, really, are damaged by fraudulent charges on their credit cards which can be traced to numbers stolen from Web sites? How often do such fraudulent charges go uncaught by the credit-card companies? I confirm every item on every credit-card statement I receive. Anyone who does so has nothing to fear from hackers breaking into Web sites and stealing lists of credit-card numbers. In my opinion, anyone who does *not* do so is being foolish, regardless of whether they allow their credit-card numbers to be stored on Web sites. Jonathan Kamens ------------------------------ Date: Fri, 5 Jan 2001 17:19:19 -0800 From: Mark Hull-Richter Subject: Re: Egghead.com (Murphy, RISKS-21.18) > Suppose you have 500,000 VISA/MC numbers in your computer, [...] > and have the means and desire to rack up just $20 worth [...] for a > cool fast million dollar profit [...] what is to stop me from offering > your system administrator some tidy sum (even 10%!) to just slip in > a floppy disk and grab me a copy of the data? Last I checked, $20 x 500,000 is $10,000,000 - that 10% just got a LOT bigger... ------------------------------ Date: Mon, 8 Jan 2001 07:39:51 -0500 From: "Berman, Philip" Subject: Re: Y2K+1 bug in Sharp Organizer (RISKS-21.18) This is an update of my previous posting. I was able to reach Sharp Customer Service and the problem has been verified by them. It seems to be isolated to only the model YO-550. In addition my report that it seemed to be a 2001 problem is not entirely accurate. The condition (loss of all memory) occurs when the two least significant digits of the date fall between 01 and 49. Thus setting the calculator to 1901 will cause the problem. If I just wait for 2050 the problem will go away. Not only has Sharp confirmed the problem, but they have indicated that they will exchange my organizer for a new model. Philip Berman ------------------------------ Date: Mon, 8 Jan 2001 22:28:56 -0500 From: Jonathan Kamens Subject: Re: Y2K+1 bug in Sharp Organizer? (Berman, RISKS 21.18) >About 4 years of notes and phone numbers lost (yes you can back it up >to a computer - The backup kit cost about the same as the organizer). And what is the "cost" of reconstructing the four years of notes and phone numbers? I can't imagine that it's less than it would have cost to buy and use the backup kit. In my opinion, this point is as important as Mr. Berman's main point about the failure of his Sharp organizer (and presumably many others) when confronted with dates in 2001: If your data is worth keeping, it's probably worth backing up. According to the Sharp Web site, the cable for connecting Mr. Berman's organizer to a PC costs $49.99 and the software to use with it costs $99.99. Admittedly, that's a bit pricey, but is $150, amortized over four years, really more expensive than the aggravation caused by the loss of the data? When my brother gave me an organizer as a gift years ago, the first thing I did was figure out how I could transfer its data to/from my computer. I refused to store *any* data on it until I was confident that I would not lose anything when it died. And indeed, when I finally dropped it one too many times and it gave up the ghost, all of its data was backed up intact on my PC and I didn't lose anything. Incidentally, the Sharp Electronics Web site () says that Sharp is aware of this problem and will replace any affected YO-550, free of charge. It also confirms that, "UNFORTUNATELY, ANY CUSTOMER ENTERED DATA FROM THE DEVICE NOT BACKED UP TO A PERSONAL COMPUTER WILL NOT BE RECOVERABLE." Jonathan Kamens ------------------------------ Date: Fri, 05 Jan 2001 09:40:09 -0500 From: David Collier-Brown Subject: Re: IBM and Intel push copy protection (Gelsinger, RISKS-21.18) This explanation may be erroneous: a member of the ATA committee is cited at http://www.ihateapple.com/ "Hard Drive Copy Protection Update" as saying that IBM has in fact proposed a set of ATA commands to do so. The Register has followed up by posting a set of frequently asked questions, including a counter-argument to the claim that the extension is only for removable media. Read the article at http://www.theregister.co.uk/content/2/15718.html and make up your own mind. dave David Collier-Brown, Performance & Engineering Team, Americas Customer Engineering (905) 415-2849 davecb@canada.sun.com ------------------------------ Date: Fri, 29 Dec 2000 20:50:19 -0500 From: Gene Spafford Subject: Security white paper Risks readers may be interested in the report at this link: From that page: Extraordinary changes in the way we do business and lead our lives in the ever-connected world of the future will create tremendous security challenges. These challenges will be shaped by many of today's emerging trends: the rapid acceleration of network speed, connectivity and the overall number of devices; the removal of the human element from many everyday transactions; and easier and cheaper collection of public and private information. More than ever before, we will demand security solutions that enable businesses to thrive and private information to be protected. Accenture has just released the Security Call to Action and executive summary, from the 15 security experts who participated in the CERIAS Security Vision Roundtable. This two-day event, jointly sponsored by Accenture and the Purdue University CERIAS (Center for Education and Research in Information Assurance and Security), brought together both industry pioneers as well as information security leaders experts at some of the largest and most influential companies in the world. The report includes a Call to Action and a list of the key trends affecting security over the next decade. The bottom-line is that doing security right requires the greater community of business leaders, technologists, educators and political leaders to look seriously at this Call to Action and to commit resources and energy to help lead us all to a more secure world. Accenture is the new name for Andersen Consulting as of January 1, 2001. ------------------------------ Date: 26 Dec 2000 (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. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, 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 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. http://the.wiretapped.net/security/info/textfiles/risks-digest/ . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.19 ************************