precedence: bulk Subject: Risks Digest 21.01 RISKS-LIST: Risks-Forum Digest Tuesday 15 August 2000 Volume 21 : Issue 01 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at and by anonymous ftp at ftp.sri.com, cd risks . Contents: Russian nuclear sub trapped on bottom of Barents Sea (Keith A Rhodes) Risks of train doors: Sydney (Simon Carter) Admissions mixup leaves Northeastern University struggling (Daniel P. B. Smith) Not so smart weapons in Kosovo (Lord Wodehouse) Private phone records on Web (Kevin L. Poulsen) Barclays Internet-banking security-glitch following software upgrade (Pete Morgan-Lucas) Security hole in Netscape (NewsScan) The Pentagon worries that spies can see its computer screens (Gregory F. March) Online gambler goes to prison (NewsScan) County blew $38 million on canceled payroll system! (Joan Brewer) Delays in the new UK Air traffic control system (Ursula Martin) Microsoft vulnerabilities, publicity, and virus-based fixes (Bruce Schneier) REVIEW: "NT 4 Network Security", Strebe/Perkins/Moncur (Rob Slade) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 14 Aug 2000 07:22:26 -0400 From: "Keith A Rhodes" Subject: Russian nuclear sub trapped on bottom of Barents Sea A Russian nuclear submarine malfunctioned while on exercises, and was trapped on 13 Aug 2000 on the bottom with a crew of more than 100 aboard. [There was not much hope for the crew.] [*Izvestia* reported recently that, according to the most conservative estimate, 507 submarine crew members have died during the 40-year history of Russian nuclear submarines, not counting this one.] [Source: Article by Barry Renfrew, Associated Press, 14 Aug 2000; PGN-ed] [I think the most telling line in this report is that the Russian Navy is in a shambles with their vessels getting no regular maintenance. Seems that in this case the tables have turned -- usually everyone is complaining about not keeping up with their software maintenance, although I guess that if they did not maintain the vessel's mechanical systems, they did not maintain its computer systems. Keith] ------------------------------ Date: Tue, 01 Aug 2000 13:57:36 +1000 From: Simon Carter Subject: Risks of train doors: Sydney This is the latest in a series of disasters and irritants on the Sydney train system: > As a commuter, Mr Dee almost became a victim of the system he supported > when his leg became trapped in a train door as it left Meadowbank Station > on Sunday afternoon. http://www.smh.com.au/news/0008/01/text/national3.html A colleague suggested: > This one's almost worth sending to RISKS forum. Train doors have a long > history of hazardous action (or inaction, as in this case). > > Off the top of my head: > > For a long time, Brussels metro had no automatic opening mechanism, so > that anything trapped in a closing door stayed trapped. It sounds like > Sydney used the same contractor. > > Calgary did install an opening mechanism, but the sensors failed when > the rubber door seals hardened at -30C. > > More amusingly, a woman jumped onto the London U/G, except the doors > shut on her handbag. "No worries, I'm getting off next stop, I'll get it > back then." The doors opened on the other side of the carriage. > > There's a story somewhere about a computer-controlled train > persistently stopping out of alignment with doors on the platform edge. > > 'Fraid I can't give a reference for any of these. > > David [David Tombs ] I recall there were numerous problems with the Bay Area BART system when it first went into service (mid '70's?). All sorts of things including doors opening while traveling between stations. Simon Carter [Lots of rail problems in the RISKS archives. See http://www.csl.sri.com/neumann/illustrativerisks.html and click on Rail, Bus, and Other Public Transit in the index. PGN] ------------------------------ Date: Thu, 10 Aug 2000 05:56:43 -0400 From: "Daniel P. B. Smith" Subject: Admissions mixup leaves Northeastern University struggling After problems with its new computer system, Northeastern University unintentionally admitted 25 percent too many freshmen -- 600 extra students -- for this fall. Earlier, the names of hundreds of potential applicants had been lost when the system was first installed, which resulted in an aggressive campaign to enroll the students who had been accepted. [Source: *The Boston Globe*, 10 Aug 2000; PGN-ed] Daniel P. B. Smith, 35 Mountain Ave, Norwood, MA 02062 dpbsmith@bellatlantic.net (Lifetime address: dpbsmith@mit.alum.edu) [Also noted by Dave Bank. PGN] ------------------------------ Date: Mon, 14 Aug 2000 13:23:02 +0100 From: Lord Wodehouse Subject: Not so smart weapons in Kosovo Yet again there is any report on smart weapons, actually not being as smart as portrayed by the military. It is so like the hype of the Patriot missile (various issues of RISKS [and the illustrativerisks.html archive]). This survey was carried out by Flight International and the BBC radio Today programme. http://news.bbc.co.uk/hi/english/uk/newsid_879000/879560.stm The risks are again obvious. The computer game warfare style does not deliver what it is meant to do so, but the military continues to pursue it, because they can get more money that way. The prospects for the NMDS (son of Star Wars) looks even more unrealistic in this light. I strongly believe that we all need a good dose of reality in relation to what technology and computers can do, and where other factors, such as the weather limits the optimistic expectations. Global Research Information Systems, Glaxo Wellcome, Stevenage SG1 2NY UK +44 1438 76 3222 w0400@ggr.co.uk http://ds.dial.pipex.com/lordjohn/ ------------------------------ Date: Mon, 14 Aug 2000 11:11:07 -0700 (PDT) From: "Kevin L. Poulsen" Subject: Private phone records on Web http://www.securityfocus.com/news/074 Verizon's twenty-eight million residential and business telephone subscribers from Maine to Virginia had portions of their private telephone records exposed on a company web site, SecurityFocus has learned. The telephone giant, already struggling in a strike by union workers, was scrambling Sunday night to shut down the offending web application: a system designed to allow customers to file new repair reports, and track existing reports, over the Internet. Because of a basic design flaw, users could put in any phone number in Verizon's northeastern U.S. service area, and, by viewing the source of the resulting page, see the owner's name and address, as well as other information. "We're going to have to go to a fix, obviously," said company spokesperson Larry Plumb, who learned of the flaw through SecurityFocus's inquiry. "We won't open up that application again until we have the problem solved." Kevin L. Poulsen, Editorial Director, SecurityFocus.com, Washington D.C. (202)232-5200 ------------------------------ Date: Tue, 1 Aug 2000 09:30:44 +0100 (BST) From: Pete Morgan-Lucas Subject: Barclays Internet-banking security-glitch following software upgrade Barclays Bank yesterday had a problem with their online banking service - at least four customers found they could access details of other customers. Barclays are claiming this to be an unforeseen side-effect of a software upgrade over the weekend. See http://news.bbc.co.uk/hi/english/business/newsid_860000/860104.stm for more details. //Pete Morgan-Lucas// NERC_ITSS Network Security, NERC Swindon. [Also noted by AllyM at http://www.theregister.co.uk/content/1/12287.html and Andrew Brydon in a BBC item that mentioned 7 complaints. PGN] ------------------------------ Date: Tue, 08 Aug 2000 07:32:18 -0700 From: "NewsScan" Subject: Security hole in Netscape Because of a security hole in the Netscape browser, about a thousand computers have been infected in a way that would allow a network vandal to see, run, and delete files on the victim's computer. Netscape is working rapidly to solve the problem, but network security experts are suggesting that, until the solution is found, Netscape users should disable the Java programming languages in their browsers. [AP/*Los Angeles Times*, 6 Aug 2000, http://www.latimes.com/business/cutting/20000808/t000074055.html; NewsScan Daily, 8 August 2000] ------------------------------ Date: Thu, 10 Aug 2000 08:59:11 -0400 From: "Gregory F. March" Subject: The Pentagon worries that spies can see its computer screens There was a front page article in the *Wall Street Journal* (7 Aug 2000) discussing the technology and risks of video-screen snooping by scanning the EMF radiated by the monitor. I'm not an engineer, but I can put two and two together. I have a wireless keyboard and mouse. If someone could view my monitor remotely and then send the appropriate commands to my Logitech mouse/keyboard, it could be a *huge* potential risk for leaving my machine on and unattended. Gregory F. March -=- http://www.gfm.net/~march -=- AIM:GfmNet ------------------------------ Date: Fri, 11 Aug 2000 09:53:55 -0700 From: "NewsScan" Subject: Online gambler goes to prison A co-owner of an online offshore gambling business based on the Caribbean island of Antigua has been sentenced to 21 months in a U.S. prison for violating this country's federal Wire Wager Act, which makes it illegal to use telephone lines in interstate or foreign commerce to place sports bets. The prosecutor noted: "An Internet communication is no different than a telephone call for purpose of liability under the Wire Wager Act." [Reuters/*The New York Times*, 11 Aug 2000; NewsScan Daily, 11 August 2000; http://partners.nytimes.com/library/tech/00/08/biztech/articles/11gambling.html] ------------------------------ Date: Mon, 31 Jul 2000 07:44:08 -0700 From: "Joan Brewer" Subject: County blew $38 million on canceled payroll system! The managers of King County's unfinished $38 million Financial Systems Replacement Program (FSRP) computer system did not use basic computer and business procedures, forcing part of the system online before it was ready, spending the rest of their budget trying to fix the resulting problems, and leading to the cancellation of the project, largely because of delays and cost overruns in the payroll system for the county's 19,000 employees. The resulting system reportedly can handle only one-third of the load. [Source: Article by Roberto Sanchez, County blew $38 million: Here's what went wrong, *The Seattle Times*, 28 July 2000; PGN-ed] ------------------------------ Date: Thu, 10 Aug 2000 10:41:39 -0700 From: Ursula Martin Subject: Delays in the new UK Air traffic control system (Re: RISKS-20.93,94) 400 technicians (software engineers perhaps?) have reduced the number of [known] bugs from 500 to 200 in recent weeks. [See http://news.bbc.co.uk/hi/english/uk/newsid_873000/873765.stm] ------------------------------ Date: Mon, 07 Aug 2000 09:07:45 -0500 From: Bruce Schneier Subject: Microsoft vulnerabilities, publicity, and virus-based fixes The latest tale of security gaps in Microsoft Corp.'s software is a complicated story, and there are a lot of lessons to take away ... so let's take it chronologically. On June 27th, Georgi Gunniski discovered a new vulnerability in Internet Explorer (4.0 or higher) and Microsoft Access (97 or 2000), running on Windows (95, 98, NT 4.0, 2000). An attacker can compromise a user's system by getting the user to read an HTML e-mail message (not an attachment) or visit a website. This is a serious problem, and has the potential to result in new and virulent malware. But it requires Microsoft Access to be installed on the victim's computer, which, while common, is by no means universal. A virus that exploits this vulnerability will not spread as widely as, say, Melissa. In any case, Microsoft published a fix on July 14th, and I urge everyone to install it. On July 17th, SANS promulgated an e-mail warning people of the "most dangerous flaw found in Windows workstations." I can't really figure this e-mail out; it seems to be primarily a grab for press coverage. Some of it is suspiciously vague: "We developed this exploit further and realized that this is one of the most serious exploits of Windows workstations in the last several years" "Developed"? How? No one says. Some of it brags: "Microsoft asked us not to release the details until they had a fix." "Release the details"? But the original Bugtraq posting was pretty explanatory, and SANS has not released anything new. Still, the SANS e-mail received a lot more publicity than the Bugtraq announcement or the Microsoft patch, so it's hard to complain too much. But the SANS announcement had a much more disturbing section: "It may be possible to fix this vulnerability automatically, via an email without asking every user to take action. The concept is similar to using a slightly modified version of a virus to provide immunity against infection. SANS is offering a $500 prize (and a few minutes of fame) to the first person who sends us a practical automated solution that companies can use, quickly, easily, and (relatively) painlessly to protect all vulnerable systems." (This paragraph is no longer on the website, which claims that "winning entries have been received.") This is a really, really dumb idea, and we should put a stop to this kind of thinking immediately. Every once in a while someone comes up with the idea of using viruses for good. Writing a virus that exploits a particular security vulnerability in order to close that vulnerability sounds particularly poetic. First, there's no audit trail of the patch. No system administrator wants to say: "Well, I did try and infect our systems with a virus to fix the problem, but I don't know if it worked in every case." Second, there's no way to test that the virus will work properly on the Internet. Would it clog up mail servers and shut down networks? Would it properly self-destruct when all mail clients were patched? How would it deal with multiple copies of itself? And third, it would be easy to get wrong and hard to recover from. Experimentation, most of it involuntary, proves that viruses are very hard to debug successfully. Some viruses were written to propagate harmlessly, but did damage because of bugs in their code. Perfectly intentional experimentation proves that in your average office environment, the code that successfully patches one machine won't work on another, sometimes with fatal results. Combining the two is fraught with danger. Every system administrator who's ever automated software distribution has had the "I just automatically, with the press of a button, destroyed the software on hundreds of machines at once!" experience. And that's with systems that you can *stop*; self-propagating systems don't even let you shut them down when you find the problem. In any case, the SANS announcement was made even more confusing by the announcement of another Microsoft vulnerability at the same time...one that I think is even more serious than the one SANS publicized. (The vulnerability was first discovered on July 2nd, but was independently discovered and published on Bugtraq on July 18th.) A buffer overflow in Microsoft Outlook or Outlook Express allow an attacker to execute arbitrary code on a victim's machine just by sending him an email. In Outlook Express, the victim doesn't even have to open the email, or preview it. All he has to do is download it. In Outlook, he has to read it. That's the bad news. The good news is that it only is a vulnerability for users who have POP or IMAP installed; those using Outlook's default corporate configuration are not vulnerable. (Home users who link to commercial ISPs are much more likely to be vulnerable.) So again, a virus that exploits this vulnerability would be dangerous and unpleasant, but would not spread unchecked. Microsoft has a fix. Originally (on July 18th) it required you to upgrade your version of Outlook or Outlook express, but two days later Microsoft did the right thing and issued a patch for all versions. SANS issued another e-mail on July 21st, with more dire warnings: "Please fix this before you go home today. And if you have gone home, go back to the office and fix it." In my opinion, this warning blew the threat completely out of proportion, and was irresponsible to send. SANS made it sound like a virus attack already in progress, not a new vulnerability that someday might be exploited. And right on the heels of the previous warning, it got lost in the noise. When I received the second SANS e-mail, I thought it was another reminder for the first vulnerability. I'll bet that many users were similarly confused, and ignored it as well. There are several lessons here. 1. Computer programs have two sorts of vulnerabilities, nicely illustrated by these two attacks. First, they have vulnerabilities connected to the basic design of the operating system they run on and the way it chooses to interlink programs; the Access attack demonstrates this. Second, they have vulnerabilities based on coding mistakes; the buffer overflow problem is an example. 2. It's not enough to release a patch. The press often gets this wrong. They think the sequence is: vulnerability publicized, patch released, security restored. In reality, it doesn't work that way. You don't regain security until you install the patch. Even though both of these vulnerabilities have been patched, I predict attack tools that use them. Many users just won't bother installing these patches. For publicizing the two vulnerabilities, SANS is to be commended. 3. Sensationalizing vulnerabilities will backfire. Both of these vulnerabilities are serious, but neither is monumental. Calling something "the most dangerous flaw" leads people to trivialize other flaws. I worry about the public being completely unable to determine what is important. We've seen viruses that fizzle, and others that run rampant. We've seen vulnerabilities that look serious but don't amount to anything, and ones that are trivial and exploited again and again. SANS needs to be a voice of reason, not of hyperbole. 4. Writing a virus to exploit a vulnerability is a bad idea, even if the goal of that virus is to close that vulnerability. Viruses, by their very nature, spread in a chaotic and unchecked manner; good system administration is anything but. 5. There are still lots of serious vulnerabilities in Microsoft products, and the interactions between products, waiting to be discovered. The Access/IE vulnerability: The SANS announcement: Microsoft's "work around": The Outlook vulnerability: Reports on the vulnerability: Microsoft's fix: This article originally appeared in: Bruce Schneier, CTO, Counterpane Internet Security, Inc. Ph: 408-556-2401 3031 Tisch Way, 100 Plaza East, San Jose, CA 95128 Fax: 408-556-0889 ------------------------------ Date: Mon, 14 Aug 2000 09:14:54 -0800 From: Rob Slade Subject: REVIEW: "NT 4 Network Security", Strebe/Perkins/Moncur BKNT4NSC.RVW 20000609 "NT 4 Network Security", Matthew Strebe/Charles Perkins/ Michael G. Moncur, 1999, 0-7821-2425-9, U$49.99 %A Matthew Strebe ntsecurity@starlingtech.com %A Charles Perkins ntsecurity@starlingtech.com %A Michael G. Moncur mgm@starlingtech.com %C 1151 Marina Village Parkway, Alameda, CA 94501 %D 1999 %G 0-7821-2425-9 %I Sybex Computer Books %O U$49.99 800-227-2346 Fax: 510-523-2373 info@sybex.com %P 940 p. + CD-ROM %T "NT 4 Network Security, Second Edition" While dauntingly thick, this is a generally readable, and fairly comprehensive, introduction to security in general, and particularly to Windows NT in a networked environment. On the other hand, it sometimes has less material than you would expect. Chapter one presents a general overview of security, touching lightly on a range of topics and indicating areas the book is going to cover. It is interesting to note that one subject seems to be left out: data and business recovery is only mentioned tangentially. For example, the NTFS disk format is noted to fully support security, but the possible problems in recovering when the disk goes bad are not mentioned. Human security, in chapter two, covers a wide range of social factors, including an extensive discussion of password choice, and the importance of treating your employees fairly and well. The explanation of encryption, in chapter three, deals with a number of important aspects, but is poorly structured. It also brings in a number of unrealistic factors, such as the use of quantum computers, and neglects some fairly important current developments. A general plan for administering security is proposed in chapter four. Chapter five presents the Windows NT security model, and, while it does a better job than many other such works, it does not really provide a clear working picture. User account functions, with another look at passwords, is reviewed in chapter six. System policy is introduced in chapter seven, but the overall operation and effect is not explained well, and the material almost immediately degenerates into a terse listing of policy options. Although chapter eight purports to examine file systems, most of it deals with setting security permissions with NTFS. Chapter nine starts to look at networking issues with workgroups and shares. Unfortunately, while the mechanics of sharing operations are clear enough, the concepts are not. Domains and trust relationships are introduced, but not very functionally, in chapter ten. Fault tolerance, in chapter eleven, gives some basic information on various types of disk redundance, and a few tips on backup. Chapter twelve talks about virus protection. I am used to security texts that have numerous mistakes in this area, but I was astonished to see, at the beginning of this section, mention of a "CMOS virus" (no such thing) that infects the CMOS BIOS code. A computer's "CMOS" is the term used to refer to the small chip containing battery supported memory, holding a small table of information. This information is used by the BIOS programming, which programming is generally stored in read-only memory. (The next page actually mentions this.) CMOS memory is generally too small to hold any effective virus. In addition, it is only called as data, and no program that you did manage to store in the CMOS area would ever run. In any case, the text goes on to say that these viruses can obtain complete control over a computer, and cannot be removed by most antiviral software. (I suppose the statement about removal is true enough: since they don't exist, who would bother to write removal programs?) There is also an erroneous account of the Brain virus, a two page exegesis on Java that finally admits Java can't be used to create viral applets, a statement that NT is "immune" to file viruses (it's not), a list of antiviral types that only mentions different types of scanners (never mentioning activity monitors or change detection software), and a section on trojan software. Remote access actually starts with a brief mention, at the end of chapter twelve, of the dangers of pcAnywhere. (Both here and in the following, there are stories of scanning local networks from home ISP service. The authors do not mention that this operation is restricted to those with cable modems.) Chapter thirteen starts off with some opining on phone phreaking, but then does move on to some reasonable information on securing dial-in situations. The material on multi- vendor networks, in chapter fourteen, does little more than assert that other operating systems have security holes, too, you know! Chapter fifteen is an introduction to the Internet, but, because of a rather loose structure, does not present security concepts in a coherent manner. Similarly, the overview of TCP/IP, in chapter sixteen, lists a number of potential problems with the protocols but not much instruction on what to do about them. Chapter seventeen describes a rather random bag of advice on security aspects on client (non-server, or, in other words, user) machines. Then we move back into network territory with a blend of firewall and virtual private network (VPN) technology in chapter eighteen. Chapter nineteen tells us about VPNs, with a few mentions of firewalls. Microsoft BackOffice is reviewed in chapter twenty, but without much specific information about security. Chapter twenty one lists a variety of user (application) level security loopholes. A number of attacks available at the network level are listed in chapter twenty two. "The Secure Server," in chapter twenty three, looks primarily at physical security and concerns (and finally admits that NTFS can be bypassed after all). Chapter twenty four looks at physical matters again, mostly in the TEMPEST realm (and with a little misinformation about fibre optics and fish tanks). The authors have tried to lighten up a rather heavy topic by including humour in the text. While the remarks don't really get in the way of the content, they don't really support it, either. There is also an attempt to keep readers from getting lost in the jargon by providing "terminology" boxes throughout the book. This is helpful, but is not used as consistently as it could be. Acronyms, in particular, frequently start to appear in the text without ever having been specifically defined. This work has better conceptual coverage than "Microsoft Windows NT 4.0 Security, Audit, and Control" by James G. Jumes et al, (cf. BKWNTSAC.RVW), and is about equal to "Windows NT Server 4 Security Handbook" by Hadfield, Hatter, and Bixler (cf. BKNT4SHB.RVW). There is better structure and more willingness to discuss flaws than is apparent in the "Windows NT Security Guide" by Stephen A. Sutton (cf. BKWNTSCG.RVW). It has perhaps the same level of quality, and is certainly larger than "Windows NT Security" by Charles B. Rutstein (cf. BKWNTSEC.RVW), but there is not as much depth in places. "PCWeek Microsoft Windows NT Security," by Lambert and Patel (cf. BKPWNTSG.RVW), has better material in significantly less space. In terms of Internet material, it is about the same as "Internet Security with Windows NT," by Mark Joseph Edwards (cf. BKINSCNT.RVW), although it could hardly be worse. In general it is a good, useful guide, but there are still a number of holes to patch. copyright Robert M. Slade, 2000 BKNT4NSC.RVW 20000609 rslade@vcn.bc.ca rslade@sprint.ca slade@victoria.tc.ca p1@canada.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: 13 Dec 1999 (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/textfiles/risks-digest/ . ==> PostScript copy of PGN's comprehensive historical summary of one liners: illustrative.PS at ftp.sri.com/risks . ------------------------------ End of RISKS-FORUM Digest 21.01 ************************