precedence: bulk Subject: Risks Digest 19.95 RISKS-LIST: Risks-Forum Digest Friday 11 September 1998 Volume 19 : Issue 95 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 http://catless.ncl.ac.uk/Risks/19.95.html and at ftp.sri.com/risks/ . Contents: Russian rocket blows 12 Globalstar satellites (PGN) Starr Lite, Starr Bite, First Starr, We Scene Tonight (PGN) San Francisco Muni removes streetcars to increase service (PGN) Another Y2K bug revealed (Martin Minow) It's good to have a cable modem when the phone system goes down (Fred Cohen) Re: De-Rail Canada: A risk of Train-ing ignorance? (Rob Slade) Re: "Windows NT Security", Charles B. Rutstein (Bob Frankston) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Fri, 11 Sep 98 9:43:47 PDT From: "Peter G. Neumann" Subject: Russian rocket blows 12 Globalstar satellites Globalstar (42% owned by Loral Space and Communications) used a Russian Yuzhnoye rocket for the launch of 12 Globalstar satellites intended to be part of a world-wide wireless phone network. Two separate computer faults 4.5 minutes after launch reportedly resulted in the complete loss of the rocket and the satellites. [Source: Dan Fost, *San Francisco Chronicle*, 11 Sept 1998, A1] Missing bounds check? This one certainly had leaps and bounds. Off-by-one error? Hardware? I hope we can get some details. All your eggs in one basket? Not really. Globalstar is shooting for 52 low-orbit satellites. Cheaper by the dozen? This one cost $270M for the satellites ($190M expected to be covered by insurance!), and about $100M for the rocket. [This sounded like a Loral and Hardy launch when I heard a radio announcer mispronounce the company name as "Laurel".] ------------------------------ Date: Fri, 11 Sep 98 11:44:12 PDT [corrected time stamp] From: "Peter G. Neumann" Subject: Starr Lite, Starr Bite, First Starr, We Scene Tonight The 145-page executive summary of the Independent Counsel's report is now on-line at various sites (including house.gov, cnn.com, time.com, msnbc.com, nytimes.com, etc.). Many media wags are telling a tale that massive attempts at Web access will dog the performance of the Internet and participating various servers, with the possibility that significant parts of the Internet could crash. Don't hold your breath while attempting access. [This expectation is of course quite consistent with all the evidence that the most-searched-for string on the Internet is "sex". For example, a very modest item in RISKS-19.11 alluded to what an MS Word spelling checker did with the strings "zzzz" and "ZZZZ" -- without telling, the item pointed to a file (http://www.csl.sri.com/~risko/zzzz.html) that has repeatedly been found by subsequent web searches -- although undoubtedly to the disappointment of prurient searchers who are not RISKS readers.] [A note by Tom Abate in the *San Francisco Chronicle*, 10 Sep 1998, B1, notes that Mark Mooradian (who works with digital music for Jupiter Communications in New York) surveyed top search engines and rather startlingly claims that the *second-most-searched-for* string is "MP3", the International Standards Organization open standard that compresses three-minute songs into 3Mbytes instead of 45Mbytes; the fact that MP3 has no anti-piracy protection is seriously worrying the music publishers, who obviously have alternative proposals. As a complete aside not to be pursued in future issues of RISKS, I wonder how many folks are interested in *both* sex and pirated (or pirating) music!] ------------------------------ Date: Thu, 10 Sep 1998 07:47:220 -0700 From: "Peter G. Neumann" Subject: San Francisco Muni removes streetcars to increase service The San Francisco Muni folks have installed a $70M Alcatel Transport Automation US computerized control system in an attempt to improve service often plagued by mishaps. This turns out to work well for the newer Breda streetcars, which can communicate with one another. Unfortunately, communications were blocked when the 17-year-old Boeing-Vertol cars were simultaneously in use, which was particularly annoying when the old cars got stuck in the downtown tunnel. The short-term fix was to remove 20 Boeing cars from service (out of a fleet of 136), until they can be converted. This fix reduced the computer-related problems, but also seriously reduced capacity. Operating in passenger overload is also a problem, because if a Breda car door fails to close after several attempts because of passengers blocking the door, the computer system interprets this as a mechanical failure, and shuts down the entire Metro! "Alcatel contends that its system is working fine and that Muni's problems are with its equipment and personnel. Muni is fining Alcatel $25,000 a day until the software system works properly and allows Muni to increase the number of trains it operates under Market Street. The city and Alcatel are already involved in a legal fight." [Source: Edward Epstein, Muni's solution -- take 20 cars out of service, *San Francisco Chronicle*, 4 Sep 1998, A1; PGN Stark Abstracting; Terry Clifton augmented my morning newspaper reading by sending me the article on-line.] In a subsequent event, a driver stepped out of his streetcar to get a drink of water, apparently forgetting that it was on automatic control; the good news is that the automatic system worked just fine and the streetcar went several stops unattended without incident. (Ken Garcia in the 10 Sep *Chron* noted that some people were upset by the driverless run, but suggested that the real reason might have been that "there was no Muni person around to yell at.") ------------------------------ Date: Fri, 4 Sep 1998 13:22:49 -0700 From: Martin Minow Subject: Another Y2K bug revealed One of my colleagues got a letter from (name changed to protect the guilty) confirming an order he'd placed. The letter was dated August 3, 2098. It turns out that a friend of mine is Y2K manager for that company, When I mentioned it, he asked for a copy of the letter and tracked the problem down (and was very pro-active in communicating what had happened). As you might expect, new software went online in late July with Y2K windowing turned on, and there was a minor bug in one of the modules. The bug was fixed ten days later but, before the fix went into production, "a half-million" confirmation letters were sent out with wrong date. Fewer than a dozen people noticed and called , and it appears that my colleague and I were the only people to actually recognize this as a Y2K bug. Moral for Risks? Get your fixes in early, expect problems, don't expect too much help from the public. Martin Minow, minow@pobox.com ------------------------------ Date: Tue, 1 Sep 1998 20:53:04 -0700 (PDT) From: Fred Cohen Subject: It's good to have a cable modem when the phone system goes down In the 925 area code - just today officially severed from the 510 area code - you might be well advised to have a cable modem to get to the Internet. My cell phone works (which has been 925 area code only for some time) but every number in the 925 area code that was also in the 510 area code till today seems to be out of service. IF we can't handle September 1, 1998, how we we ever be able to handle 2000/01/01? Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171 Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225 ------------------------------ Date: Fri, 4 Sep 1998 23:25:09 -0800 From: "Rob Slade, doting grandpa of Ryan and Trevor" Subject: Re: De-Rail Canada: A risk of Train-ing ignorance? (Martin, R-19.94) > ... but inadequate knowledge and training, coupled with miscommunication ... The inadequate training part seems to be rather an understatement. Only one of the news stories I've heard has mentioned, and that very briefly, that none of the train crew, and none of the maintenance crew in the West, had any training on the warning system. The nearest trained staff were over 3000 km distant in Ontario. rslade@vcn.bc.ca rslade@sprint.ca slade@freenet.victoria.bc.ca ------------------------------ Date: Thu, 6 Aug 1998 20:12 -0400 From: Bob_Frankston@frankston.com Subject: Re: "Windows NT Security", Charles B. Rutstein (Slade, RISKS-19.89) The discussion about the lack of NT security books seems to miss the larger issue. Much of the thinking of computer security seems to hark back to the good old days when we knew how to build secure systems. And to simple systems such as Unix that provide simple security models for simple problems. I too am nostalgic for the old days of Multics when security was defined in terms of usability. The requirement was the users be able to trust the system. This was less an issue of military security than being able to specify what access was to be given and to whom. The system was honed with just Read/Execute/Write (and Append, but that's already a messy one) on files (and directories). The Access list could explicitly list users or projects (administrative groupings of users). If the user didn't know about the security system, by default, there weren't any further exposures. Unix had a different design point. The system was assumed to be like a friendly work group with papers left on desks for easy access. Unix default was to allow the world to read all of your files. Not safe for the naive but unlike Multics the assumption was that you really didn't want to keep anything confidential on your computer. (I know I'll be flamed for this but defaulting to read means that only fools would trust the system security. Alas, the default is to be a fool.) The initial access system with groups made any attempt to really control access problematic. And then SU was thrown in to get around all of this. Perhaps some of this has been address but to think of Unix as the model for security seems silly. Then there were PC's and other small systems that simply lacked any notions of access control. That was fine since they were never ever going to be on a network. So now we have gripes about NT. In fact, NT has a very sophisticated security model with the ability to specify access control for all sorts of objects. And it has been C2 certified (at least, in a vacuum, networks tend to be problematic in the world of security). The problem with NT is that there is no effective UI for security. More to the point, thanks to the sophistication (AKA complexity), it is difficult to understand what is really going on in terms of security. Especially with mechanisms such a path access (security on shares) mixed in. Of course, these systems have common problems like security being specified in terms of local certification authorities (i.e., the local system directory or the NT domain). But the REAL problem is that de jure (or military) model of security has little to do with the real world: => The attributes associated with files have little to do with the access appropriate for programs (agents) acting on behalf of users. The result is that programs get wide access (in Unix via SU, in NT there might be a finer grain) and then must make sure they don't "abuse" this authority due to bugs. => Mapping identity into a login ID is naive since users might have different authority based on roles. But the most important issue goes back to the Multics' principle that all is moot if the user doesn't understand the system and is not comfortable with this understanding. And the defaults must be safe. The current systems require vigilance. Perhaps that's OK in a world of de jure where the user is blamed for mistakes. But in the real world this is called an insensitive bureaucracy for good reasons. If this weren't bad enough wrapping firewalls and other bad ideas around all this and call it a solution just adds to the complexity. If I need to read a manual to be secure, I don't have security. Furthermore, systems security is a minor part of the problem. The real issue is security of the applications. What authority am I giving to what user with what intent under what circumstance. How do the operating system mechanisms serve these needs? In the old days of time-sharing systems where we just wanted to protect files online things were simpler. The world is more interesting now and so is the question of what we mean by security. ------------------------------ Date: 31 Mar 1998 (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 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.95 ************************