precedence: bulk Subject: RISKS DIGEST 19.61 RISKS-LIST: Risks-Forum Digest Tuesday 3 March 1998 Volume 19 : Issue 61 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: Auckland city center shut down due to lack of power (Peter Gutmann) Cybotage Risks, Information Warfare-Defense, CyberWar (Robert J. Perillo) Re: CyberAttack on the Pentagon (William Hugh Murray, Fred Cohen) Another way to take down the mail system (Rob Slade) DES-II-1 correction (Billy Harris) Vladimir Levin sentenced for Citibank Y2K Problem Hits Graveyards (Dave Graf) Re: Year 2100 compliance? (Leonard Erickson, Terje Mathisen) COMPAQ usability problem (Edward Chernoff et al.) Reminder on Privacy Digests Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 23 Feb 1998 09:12:05 +1300 (NZDT) From: Peter Gutmann Subject: Auckland city center shut down due to lack of power [Note: The message could not be sent from the above FROM: address, because of the problem described below. I have substituted the proper one. PGN] The city of Auckland has its power provided by Mercury Energy, who have three 110kV lines (two main ones and a backup) and a 27kV line (another backup) feeding the central business district. Most of these cables have copper conductors inside a pressurized nitrogen jacket (apparently we're one of the few countries which use these), one of them is oil-filled. The cables are supposedly around 40 years old with an overall life expectancy of 60 years, the suspicion is that the El Nino summer has dried out and heated the ground so that vibration and ground movement (shrinkage) have damaged the cables. Because of this, all the cables have failed, leaving the central city without power. So far this has affected (at various times) a number of banking data centres (the first day the power went out was on the Thursday when everyones pay is supposed to be processed - the data centres themselves have generators, but the sources feeding them information don't), the stock exchange, the Auckland central post office buildings, customs and immigration, some sections of inland revenue, Aucklands main hospital and medical school complex (they have generators, but one of them failed, leaving the childrens hospital without power), the university, and God knows what else (many of these places have generators, but there were apparently glitches in switching over and one or two breakdowns which have caused problems). One comment I've heard is that the power company may not survive the lawsuits which follow this (taking out some suburb is serious enough, but taking out the central business district with its cluster of multinational accounting and legal firms, banks, government departments, and whatnot is really bad). There's a web site http://www.mercury.co.nz/cable/index.html with updates on the situation, this is a Mercury Energy site so be aware that it's subject to the usual degree of spin control (there have been discrepancies to date between their statements to the media and what's actually happening). Various data points: - The mayor has told businesses in the central city to either close down or relocate for at least a week. - At first the estimated time to repair was a week, now the official estimate being fed to the media is 1-3 weeks but the estimate from power company workers is a month at least (these figures change constantly, they seem to be getting worse). - In the last five years, Mercury Energy have followed the present economic wisdom of aiming for efficiency and a good return to their shareholders (the Mercury Trust) and have reduced their field workforce by half. In addition for the last three years their energy has been poured mostly into an (ultimately fruitless) struggle to take over their neighbouring power supplier, Power NZ. - Workers from other power companies are being brought in and working in civvies to hide the extent of the problem. Workers were flown in from Sydney, Australia to fix the cables, the estimate is that it'll take about a week without power to redo these, and if the load placed on them is too high they'll fail again. - Apparently the idea of moving ships from the naval base on the other side of the harbour across to the Auckland waterfront to act as floating generators was considered, but there are problems with feeding the power from the ships to the city. There's also the problem that there's nothing around which can generate enough power to supply even a fraction of the power requirements. - Because the central city was without power, there was a civil defence callout to avoid a potential crime wave. Police were called in from other parts of the city to patrol the city center. The lack of power is affecting building access control systems and alarms, buildings have to have doors propped open so people can get in or out, so there's no real protection for the building contents. The services of private security firms are in great demand. - Since water and sewage rely on electrically-driven pumps to get them into office blocks and towers, these services weren't supposed to be available either, however one cable is now repaired and, while it lasts is (barely) providing power which is being used by emergency and civil services as far as possible, with other services like traffic lights being run if there's anything to spare. - In one 10-15 story office block, sprinklers were activated by the power outages and continued spraying water into the building for quite some time. A comment from someone who saw the aftermath was "They may as well demolish the building and start again". - One company flew in a generator from Poland to try and keep things running. The lack of power is a UPS vendors dream, they're almost impossible to obtain. One company asked that their order of UPS's be shipped with a full charge. - From talking to people in various affected central city buildings, as soon as the power comes back on the affected law firms will be handling enough lawsuits to keep them in clover for years. In theory the current commercial monopolies inherited the privileged positions of the old Power Boards from which they're descended, making it impossible to sue them for failing to provide a service, however it's not unlikely that the combined legal resources of everyone they've annoyed will find some way to get to them (there are probably armies of lawyers sitting around candles right now scrutinising the relevant legislation). The Prime Minister has already made a plea for people not to engage in a witch-hunt against Mercury Energy. - The power outages did bring out some good things though. After the power had been out for about half an hour on the first day, someone mentioned that the fridges downstairs wouldn't be powered. In the spirit of true cooperation and self-sacrifice, everyone immediately rushed downstairs and saved all the beer from getting warm. The risks here are fairly obvious: Everything is concentrated into the central business district, there's no way to feed in power from anywhere else even if it were available, there's no way to allocate power based on how critical the services are beyond a very crude level (the few buildings which have generators or some other way to get power have air conditioning, lights, and whatever else running full tilt as usual, while less privileged buildings have no power or power-related services), and going for efficiency and profit rather than reliability for an essential service like this is very risky. The only real benefit I can see from this is that it'll serve as a great case study for the Infowar crowd, although the fact that it's due to simple cable faults rather than assorted Rube Goldberg devices may make it slightly less appealing for them. Peter ------------------------------ Date: Fri, 20 Feb 98 00:22 EST From: Perillo@DOCKMASTER.NCSC.MIL Subject: Cybotage Risks, Information Warfare-Defense, CyberWar Cybotage - Wilfully and/or maliciously to destroy or impede the automatic control processes of computers, and/or deliberate disruption of an "interconnected communications system" (Network). Imagine the "DieHard 2" scenario, Airplanes crash, loss of life, because the software in the maintenance system for the navigational aids of the Air Traffic Control System malfunctioned. "The other key opening for a terrorist act in the near future is the Sydney Olympics in 2000. While law enforcement organizations are concentrating on physical security they have not canvassed cybersecurity issues ... What if a 747's GPS and ILS systems were infiltrated to cause it to crash at Sydney's already limited capacity international airport? The political and psychological effect of an act of that kind in the Australian context is hard to calculate.", Australia's Vulnerability to Information Attack: Towards a National Information Policy, Dr. Adam Cobb, Strategic and Defence Studies Centre, Australian National University, Fall 1997. Imagine nationwide Telephone and Power disruptions, not because of downed lines, but because of malfunctioning software. Financial markets shut down and bank accounts not accessible, due to computer/network database problems. Imagine Information Systems Technology (IST) malfunctions cause Emergency Services (E911) Unavailability, Police/FBI phones jammed, Internet Service Provider's (ISP's) to be out of service. Environmental damage due to IST problems that caused a Pipeline disruption, a Chemical Plant fire, and/or a radioactive release from a nuclear power plant. "The U.S. is vulnerable and currently unprepared to defend crucial parts of its digital infrastructure." [Presidents Commission on Critical Infrastructure Protection (PCCIP), Critical Foundations, Protecting America's Infrastructures, October 1997, Chapter 5, Figure 5 http://www.pccip.gov ] And DrawBridges are "taken out" by introducing a computer virus to their microprocessors. [Information Warfare - Delphi, June 1996, Roger Dean Thrasher, Thesis page 30, http://stl.nps.navy.mil/~c4ipro/thesis.html ] Or the American, British, or Australian Political System manipulated by the "Ender's Game" scenario in which fringe groups or terrorists use anonymity, false identities, unlimited access, and the national nets to spread disinformation and propaganda which alters the government. [Ender's Game, Orson Scott Card, SF, 1977] In July of 1996, Dr. John Deutch Ph.D., former CIA Director, told a Senate Governmental Affairs subcommittee that the risks of cyber attack was one of the top threats to U.S. national security. Are these Threats and/or Vulnerabilities Real or Imaginary, with or without foundation? The problem with the October 1997 President's Commission on Critical Infrastructure Protection (PCCIP) Report, was not "the avoidance of the strong encryption issue - and the insistence that the government have access to corporate encryption keys." But its failure to provide a credible and comprehensive threat and vulnerability analysis, a list of specific problems, statistics, and detailed case histories. This information will be needed to understand the scope of the problem, make knowledgeable recommendations, and determine how to solve the problems and fix the systems. According to the 1997 InfoSecurity News Industry Survey - Deloitte & Touche LLP, of 1225 organizations surveyed, 26-30% of the respondents blamed "the Lack of Centralized Authority" as an obstacle to Computer and Telecommunications Security. And 40% blamed "Unclear Responsibilities". This goes beyond reporting or "information sharing", or a consulting company to analyze or assess data? What is needed is a National Focal Point for Computer and Network Security, Information Warfare - Defense (IW-D) to set Standards, provide Resources and Funding, Coordinate an incident response, Help repair the damage, Help fix the security vulnerabilities, Catch and prosecute the attacker? While computer/communications security "defense in depth" is a good idea, there must be funds and resources available to pay for it. In the 1997 InfoSecurity News Industry Survey, 63-68% of the respondents stated that "Budget Constraints" were their biggest obstacle to computer and telecommunications security. "Slim budgets still inhibit many IST departments from protecting the security of their systems. Nearly 60% of the U.S. respondents to the survey cite lack of money as an obstacle in addressing security concerns. Without money, implementing security is difficult at best.", 5th annual InformationWeek/Ernst & Young Information Security Survey. If we must super-ruggedize our IST infrastructures, then increased amounts of resources, incentives, and funding are needed to implement Computer/Communications Security in both the Government and Private sectors? "Computer & Communications Industry Association (CCIA) believes that requiring American industry to bear the cost of building such super-rugged infrastructure security upgrades would constitute an excessive burden that would blunt the edge of American industry", CCIA congressional testimony, 6-Nov-1997. Footnote: "defense in depth", refers to use of multiple protection tools, Virus detection, Access Control, Firewalls, Intrusion Detection software, Secure Modems, Token-based passwords, Cryptography, Biometrics, Security Assessment tools, etc. . References: * InfoSecurity News - Deloitte & Touche LLP, David S. Bernstein, 1997 Industry Survey, May 1997, cover story page 20. * InformationWeek, "Trends, 5th annual InformationWeek/Ernst & Young Information Security Survey", Beth Davis, 08-Sep-1997. * RAND, "CyberWar is Coming!", John Arquilla and David Ronfeldt, 1993, Comparative Strategy, Vol. 12, 1993, pp 141-165. http://gopher.well.sf.ca.us:70/0/Military/cyberwar * RAND, Richard O. Hundley and Robert H. Anderson, "Security in Cyberspace: An Emerging Challenge for Society", RAND P-7893, December 1994. * RAND, Roger C. Molander, Andrew S. Riddile, Peter A. Wilson, "Strategic information warfare: a new face of war", MR-661-OSD, 1996. http://www.rand.org/publications/electronic Robert J. Perillo, CCP Richmond, VA Perillo@dockmaster.ncsc.mil [Usual disclaimers omitted] ------------------------------ Date: Mon, 02 Mar 98 17:45:11 -0500 From: William Hugh Murray Subject: Re: CyberAttack on the Pentagon (PGN, RISKS-19.60) There is no evidence available to me that says that the recent successful hacker attacks were the result of a software problem. While it may well have been aggravated by product problems, their roots were in the continued use of user-selected reusable passwords. [Blaming the vendors in a world in which government actively punishes vendors for including encryption in their products is absurd on its face.] There is a great deal of evidence available to me: That not only will secure products not be favored in the market place, they are often punished. Security features, functions, and properties often get on the list but they are never peer with performance and function. They are not as highly valued as generality and flexibility. That legitimate controls provided to management will be used to cripple security on many, if not most, systems. That most of the problems result from how we use products and how we put them together. These are things that are outside vendor control. That The hacker enjoys a target-rich environment in which success is guaranteed. Security is a balancing act in which successful attacks do not mean that we did it badly. That the government has managed to get most of its systems off the target of opportunity list and many off of the target of choice list. That technology can help good management but that no amount of it can compensate for bad management. Security is first, last, and always a management problem, not a product problem. Bill [Bill has long been an advocate of the position that security is a management problem. I have long been an advocate of the position that it is ALSO a technology problem. If systems are riddled with security flaws, there is little incentive to use serious user authentication. Management's options are limited thereby. In addition, there are issues with respect to which security is ALSO a user problem, an education problem, and a legal problem. It is all of those. Believing that it is only one of those is a huge oversimplification, and an enormous risk in itself. PGN] ------------------------------ Date: Fri, 27 Feb 1998 17:45:18 -0800 (PST) From: Fred Cohen Subject: Re: CyberAttack on the Pentagon (PGN, RISKS-19.60) Indeed, it may well have been the ``the most organized and systematic the Pentagon has SEEN to date'' - the operative word being "SEEN". Many larger scale attacks against Pentagon systems have been widely published, but none of them were "SEEN" until far later - and none were seen by the Pentagon at all. They were generally detected in audits by non-Pentagon folks. When a previously blind person sees something, it's something to stand up and notice. Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:510-454-0171 ------------------------------ Date: Fri, 27 Feb 1998 15:19:21 -0800 From: "Rob Slade" Subject: Another way to take down the mail system I got a mail bounce from a friend locally, so I called to find out what was up. Seems that, over the weekend, someone broke in and stole a computer. Turns out it was the MS Exchange server. For the whole company. rslade@vcn.bc.ca rslade@sprint.ca slade@freenet.victoria.bc.ca virus, book info at http://www.freenet.victoria.bc.ca/techrev/rms.html ------------------------------ Date: Fri, 27 Feb 1998 17:10:06 -0600 From: wharris@mail.airmail.net (Billy Harris) Subject: DES-II-1 correction (Re: McNett, RISKS-19.60) [The stats for the Power PC were wrong in the previous posting. Here is a follow-up posting made by Distributed net. Billy Harris] I need to clear up some confusion about the statistics that were posted on Nugget's "[ADMIN]" post last night. I made the stats at the end of the post including the "Perspectives" and "Computing Equivalents," and they seem to have a mistake. The keys-per-second rankings were gathered from AldE's speed page at http://www.alde.com/speed.html. I did not realize that those pages listed the speed for the early DES PPC clients, which were much slower than the ones at the end. The speed I used to create the "Computing Equivalents" was about 500kk/s for the PPC 604e/200. The more recent and correct speed was more like 1250kk/s. That would make the figure "27544 Macintosh PowerPC 604e/200s" instead of "68859 Macintosh PowerPC 604e/200s." Motorola PowerPC machines have made a significant contribution to all of the distributed.net efforts. The previous post was not intended to upset and Macintosh or PPC users and we mean no disrespect. I apologize for the confusion. Daniel Baker, distributed.net ------------------------------ Date: Wed, 25 Feb 1998 09:25:46 -0800 From: PGN Subject: Vladimir Levin sentenced for Citibank Vladimir Levin was sentenced to three years in prison for his role in the 1994 Citibank escapade (RISKS-17.27,28,29,61), and must pay Citibank $240,015 in restitution. (He as already spent 30 months in a British jail and 6 months in a U.S. jail.) Four of his accomplices had previously pleaded guilty to conspiracy to commit bank fraud. [PGN Abstracting from Internet robber sentenced, http://cnnfn.com/digitaljam/9802/24/robber/ with thanks to stevan@netscape.com (Stevan Milunovic).] ------------------------------ Date: Mon, 2 Mar 1998 21:24:46 EST From: Dave Graf Subject: Y2K Problem Hits Graveyards Regarding Y2K projects, we often forget that other applications besides those involving computers are also affected by the millennium change. For example, I saw an item in a local paper about problems involving preinscribed tombstones. Apparently, it is not uncommon to preinscribe the first two digits of the year of death. I've seen this in graveyards where there is one tombstone for a husband and wife, but one of the spouses is still alive. Not surprisingly, "19" has been the popular choice, but what are they going to do with those tombstones when the year 2000 rolls around? [With old COBOL programmers dying off, perhaps we will begin to see tombstones with HEX dates such as 199A, 199B, etc. until the supply dwindles. PGN] ------------------------------ Date: Sun, 1 Mar 1998 05:37:46 PST From: shadow@krypton.rain.com (Leonard Erickson) Subject: Re: Year 2100 compliance? (Shimomura, RISKS-19.60) The MS-DOS file system's date format does support dates outside the range 1980-2107. And every MS-DOS/PC-DOS that I've ever checked it on balks at dates past 2099-12-31 as inputs. So there's not really a lot of point in putting in support for higher dates until someone figures out what the OS is going to do about this "design flaw". At least not from a profit standpoint. I agree that they shouldn't have limited the fix this way, but given the dominance of Microsoft OSes on the platform in question, I'm not surprised. Leonard Erickson (aka Shadow) ------------------------------ Date: Sun, 01 Mar 1998 15:04:10 +0100 From: Terje Mathisen Subject: Re: Year 2100 compliance? (Shimomura, RISKS-19.60) I believe 2100 is a "harder" limit than Y2K for most applications using 2-digit years. The AMI BIOS noted in RISKS-19.60 is just one example. The CMOS chip introduced on the 1984 model IBM AT has 2 BCD digits each for year, month, day, hour, minute and second. On top of this, IBM decided to store the current century in one of the CMOS bytes not directly updated by the clock circuitry. This will work correctly past 2000 because Y2K is a leap year, but after 2100-02-28 lots of software/hardware using two-digit years will have a hard time figuring out that 2100-02-29 does not exist. It is interesting to note that even Network Time Protocol (NTP), up to the latest test releases (V4.X), will have problems at this time, due to the way NTP handles reference clocks: NTP ignores the (usually two-digit) year info from a reference clock, and will instead ask the OS for the correct year number. From the OS-supplied year plus reference clock month/day info, the software calculates the day number in the current year, a calculation which will of course fail after 2100-02-28. Terje.Mathisen@hda.hydro.com ------------------------------ Date: Tue, 03 Mar 1998 07:53:36 -0500 From: Edward Chernoff Subject: COMPAQ usability problem (Mellor, RISKS-19.60) No "Any key"? My keyboard does not have any key identified as 'return'. This may not solve their problem. [Similar comments about PC keyboards having "enter" keys, from grady@mdc.net (Dick Grady), Thomas Dzubin , Jay Crowley (jjc@cdrh.fda.gov), and "Chris Cartledge" who noted that "ANY KEY" is wrong: Shift and Control don't count.] ------------------------------ Date: 17 Apr 1997 From: RISKS moderator Subject: Reminder on Privacy Digests Periodically I remind you of TWO useful digests related to privacy, both of which are siphoning off some of the material that would otherwise appear in RISKS, but which should be read by those of you vitally interested in privacy problems. RISKS will continue to carry general discussions in which risks to privacy are a concern. * The PRIVACY Forum is run by Lauren Weinstein. It includes a digest (which he moderates quite selectively), archive, and other features, such as PRIVACY Forum Radio interviews. It is somewhat akin to RISKS; it spans the full range of both technological and nontechnological privacy-related issues (with an emphasis on the former). For information regarding the PRIVACY Forum, please send the exact line: information privacy as the BODY of a message to "privacy-request@vortex.com"; you will receive a response from an automated listserv system. To submit contributions, send to "privacy@vortex.com". PRIVACY Forum materials, including archive access/searching, additional information, and all other facets, are available on the Web via: http://www.vortex.com * The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is run by Leonard P. Levine. It is gatewayed to the USENET newsgroup comp.society.privacy. It is a relatively open (i.e., less tightly moderated) forum, and was established to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. Submissions should go to comp-privacy@uwm.edu and administrative requests to comp-privacy-request@uwm.edu. There is clearly much potential for overlap between the two digests, although contributions tend not to appear in both places. If you are very short of time and can scan only one, you might want to try the former. If you are interested in ongoing discussions, try the latter. Otherwise, it may well be appropriate for you to read both, depending on the strength of your interests and time available. PGN ------------------------------ 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.61 ************************