Subject: RISKS DIGEST 17.37 RISKS-LIST: Risks-Forum Digest Thurs 28 September 1995 Volume 17 : Issue 37 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, etc. ***** Contents: SpaceCom technician disables pagers massively (PGN) Fault-Tolerant Computer System Survives Heat Wave (Paul Green) Vote by mail (David Olsen) Re: The latest maths bug in a Microsoft product (David M. Palmer) Re: Identifying Numbers and E-mail (Michael L.W. Jones) Re: Abandoned oil tank phones... (Scott Drown) Call for Industry Papers on Information Technology Security Policy Process (Charles Brownstein) CERT Summary CS-95:02 (CERT Advisory) [long] ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 27 Sep 95 8:43:49 PDT From: "Peter G. Neumann" Subject: SpaceCom technician disables pagers massively A SpaceCom technician at their uplink facility in Tulsa, Oklahoma accidentally send out a spacey command shutting down the satellite receivers used by pager systems throughout the country, affecting millions of pagers. SpaceCom supports 5 of the largest 10 paging outfits. This happened at 1 a.m. yesterday, and each receiver had to be manually reprogrammed -- which took all day until most of the service could be restored. Al Stem, VP and GM of SC said, "This hasn't ever happened before. And we're putting additional systems in place to make sure it never happens again." [Source: AP report, seen in the San Francisco Chronicle, 27 Sep 1995, p. A2.] I guess they haven't been reading RISKS. Wow, what a user interface! Sort of like being able to type rm * without any confirmation required. Accident? Malicious act? Whooops? PGN] ------------------------------ Date: Tue, 26 Sep 95 12:21 EDT From: Paul_Green@vos.stratus.com Subject: Fault-Tolerant Computer System Survives Heat Wave I recently received the following story from one of our customer engineers. I am submitting it to the Risks Forum as a "good news" story. Here is a case were the system worked as designed (indeed, may have exceeded its design limits) and saved a customer from a serious outage. I have omitted the name and location of the customer for obvious reasons. This Stratus system manages a robotically-automated repair parts depot for a major US railroad. If the system is down equipment cannot be repaired. On Friday, July 14, 1995 at approximately 6:00 pm, the computer room air conditioning unit at the Maintenance Facility of the Railroad registered an over-temperature condition. This alarm is set to trip at 80 degrees F. The computer room is generally unmanned at this time so there were no operators or any other personnel onsite to receive the alarm. This information has been extracted from the alarm logs and has been confirmed. The a/c compressor was failing and now the fans were circulating the same air and the temperature was rising steadily. At Friday at 20:44:57 EDT the Railroad's Stratus system telephoned a failure notification to the Stratus Customer Assistance Center (CAC) in Marlboro reporting that the CPU in slot 30 had failed and had been removed from service. This failure may have been caused by the increased temperature. On Sunday at 12:58:00 EDT the system reported a second problem: a D604 disk drive had failed and had been removed from service, possibly as a result of the increased temperature. The system had been operating in a over-temperature condition now for 42 hours. During this time the Stratus CAC personnel had been trying to bring the system back to normal and were attempting to contact the Railroad. The Railroad personnel could not be reached. The CE for the site was aware of the problem Sunday evening having been notified by the Stratus e-mail system. At 7:00 am Monday the CE arrived at the Stratus office and attempted to contact the Railroad. The customer returned the call at 9:00 am. The CE advised the customer that he would be on-site shortly to restore the system to normal. The parts, a CPU and a D604, were already onsite when the CE arrived. The D604 was from a previous call not related to this problem. The computer room was still 110 degrees when the CE arrived onsite. This was 10 degrees cooler from the time the customer arrived. He managed this reduction by using desktop fan units from offices of Railroad employees. The Stratus module was operating with users even when several other Railroad computers, including two systems from a different vendor, had failed. Further complicating the Railroad's problems was the fact that the other vendor did not have any personnel on-site and no phone support was evident. The CE replaced the failed CPU in slot 30. Two drives were out of service. One drive was setup and recovered and is still fully operational, and one was replaced and recovered. Both the CPU and disk drive repairs were performed with the application online. During the entire time from 6:00 pm Friday to 9:00 am Monday, 63 hours, the Stratus System performed in a environment which had reached temperatures of 120 degrees and functioned without interrruption. The system was fully duplexed in less than one hour. The two Brand X systems which had shutdown completely were restored by 2:15 pm by the customer. He did not have the assistance of Brand X personnel either onsite or by phone. Stratus systems are designed to work at temperatures from 10 to 40 degrees Celsius environment (50 to 104 degrees Fahrenheit), with humidity from 20 to 80% noncondensing. We actually test them from 0 to 40 degrees C. For our Telephone "Central Office" models, we specify and test up to 50 degrees C -- 122 degrees F. The CO models are not significantly different from the non-CO models. The specification relates to the ambient temperature of the room; it is not unusual for internal temperatures within the cabinet to be 20 to 30 degrees C higher. The locations that run at this higher temperature are designed to withstand it. Unlike the other brand of equipment that this customer was using, we elect to keep running, rather than shutdown, because we are aiming for continuous availability. In other words, we are trade off reduced equipment lifetimes for higher levels of availability. We're betting that, as in this case, a few failures won't bring down the entire system and that the overall situation can be discovered and repaired in time to prevent an application outage. Thus, I believe that our design and testing standards carried us thru this heat wave, not luck or accident. Paul Green, Senior Technical Consultant, Stratus Computer, Inc., Marlboro, MA 01752 Paul_Green@vos.stratus.com (508) 460-2557 FAX: (508) 460-0397 ------------------------------ Date: Tue, 26 Sep 1995 13:57:53 -0700 From: David Olsen Subject: Vote by mail New methods of voting designed to replace the traditional polling place and ballot box are a regular topic of discussion on RISKS. The method being discussed usually involves voting by phone or by computer. The state of Oregon is experimenting with a new voting method, but is using a technology that may be older that the voting booth itself: the mail. Sen. Packwood's replacement, to be elected on January 30, will be the first member of the U.S. Congress ever elected in an all-mail election. Ballots will be mailed out to all registered voters a few weeks before the election date. Voters fill out the ballots in their own home at their leisure. They can then either send them back through the mail, or take them in person to a designated drop-off point. All completed ballots must arrive by January 30. Oregon has used all-mail elections before for local elections, with pretty good success. But this will be the first time it has been tried in a state-wide election. No one claims to fully understand the risks involved, so people will be watching this election very carefully. Election officials like all-mail elections because they don't have to set up any polling places or find people to run them. Most think that voter participation, long a problem in the United States, will increase. The potential for fraud is greater, but most officials seem to have enough faith in the general public that they are not worrying about it very much. The timing of campaigns will definitely change. Any last-minute media blitz is useless because most people will have already voted. David Olsen olsen@rational.com ------------------------------ Date: Tue, 26 Sep 1995 17:33:19 -0400 From: "David M. Palmer" Subject: Re: The latest maths bug in a Microsoft product (RISKS-17.36) >When does 1.40737488355328 = 0.64? When you're a user of Microsoft's Excel >spreadsheet. If you do this on a Macintosh (Excel v5.0a on a PowerMac 8100/110) you get a result of 1.40737488355328 = 1.28, proving that the Macintosh is 6 times more accurate than Windows machines. The (non-Microsoft) Macintosh calculator desk accessory does not have this problem. David Palmer dmpalmer@clark.net ------------------------------ Date: Tue, 26 Sep 1995 14:47:49 -0700 (PDT) From: "Michael L.W. Jones" Subject: Re: Identifying Numbers and E-mail (Parnas, RISKS-17.36) McMaster's use of student numbers in email is indeed odd (not to mention making it very difficult to remember undergrad email addresses!) Is it even legal? I was under the impression that, under Canada's access to information and privacy laws, the open publication of university student numbers (i.e. providing grades on office doors) is not allowed, but is continued simply due to the fact that there has been little resistance to this long-standing practice. If it is not illegal, perhaps it should be: posting a printed list on a professor's door is one thing; having it correlated electronically to one's name is another issue entirely. Michael Jones, M.A. Program, School of Communication, Simon Fraser Univ. Burnaby, B.C. V5A 1S6 Tel: (604) 291-3687 Fax: (604) 291-4024 mljones@sfu.ca ------------------------------ Date: Tue, 26 Sep 95 15:59:58 EDT From: Scott Drown Subject: Re: Abandoned oil tank phones... (Reifschneider, RISKS-17.36) The woman being haunted by the mystery calls lives near me. The local newspaper had a much more thorough coverage of the story. Here are the facts: The "oil tank" was a home heating oil tank in a private residence. It was not a million-gallon monster owned by an oil company. The tank had an auto-dialer attached, and was programmed to call the heating oil service company when the oil level fell. They would then dispatch a truck to top the tank off. Years ago the heating oil service company went out of business. The phone company reclaimed the 800-service telephone number that the auto-dialers used. (Do you see where this is going?) The 800 number was assigned to a _business_ in Massachusetts. It was set up for nation-wide availability, and connected to a FAX machine. The business is quite small, and is run by its owner from her home office. An electrical storm happened in Maryland. Apparently a nearby strike somehow woke up the auto-dialer. The business in Massachusetts starts to get late night "hang-up" calls. The calls were finally traced. The retiree that owned the tank knew nothing about the auto-dialer, and said she was very sorry that her oil tank was making crank calls. The real risk seems to be assuming that the public news organizations understand anything technological. A secondary risk, as Sean pointed out, is that no one was responsible for making sure that _all_ the auto-dialers were disconnected, when the oil company went bankrupt. I wonder how many more of them, still programmed to that 800-number, are still waiting for their "wakeup" call? Scott Drown, Annex Software Quality Assurance, Xylogics Inc, 53 Third Ave. Burlington, MA 01803 +1-617-272-8140X390 +1-800-225-3317 ------------------------------ Date: Thu, 28 Sep 1995 09:37:57 +0100 From: Charles Brownstein Subject: Call for Industry Papers on Information Technology Security Policy Process Please take a look at this Call for White Papers and consider advising your community. The Call was announced on the Web at our homepage, and at a new, alternate url: http://www.xiwt.org/homepage I look forward to your contribution as this is a real opportunity to have a very direct impact in a critical area. Please forward the Call to all in your organization who have an interest and to others in the industry and to the interested public. Charles N. Brownstein Executive Director Cross-Industry Working Team Suite 100 1895 Preston White Drive Reston, VA 22091-8990 tel (703) 620-8990 fax (703) 620-8990 http://www.cnri.reston.va.us/xiwt ------------------------------ Date: Tue, 26 Sep 1995 16:26:56 -0400 From: CERT Advisory Subject: CERT Summary CS-95:02 [The CERT bulletins are generally too long and too frequent to include in RISKS. However, they represent a valuable collection of information regarding vulnerabilities (albeit primarily those for which fixes are known). This is a metamessage that may be useful to you. PGN] CERT Summary CS-95:02 September 26, 1995 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. Starting with this summary, we will also list new or updated files that are available for anonymous FTP from ftp://info.cert.org Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries --------------------------------------------------------------------------- Recent Activity --------------- Since the July CERT Summary, we have seen these continuing trends in incidents reported to us: 1. Sendmail Attacks We receive several reports each week of attacks through sendmail, with intruders using a variety of techniques. Most of the attacks are aimed at gaining privileged access to the victim machine. To combat these threats, we encourage sites to take the appropriate steps outlined in the following: ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README A number of sites have reported some confusion on the need to continue using the sendmail restricted shell program (smrsh). You need to run the smrsh tool in conjunction with the most recently patched version of sendmail for your system. Information on the smrsh tool can be obtained from these places in ftp://info.cert.org/pub/ tools/sendmail/smrsh/ cert_advisories/CA-93:16.sendmail.vulnerability cert_advisories/CA-93:16a.sendmail.vulnerability.supplement cert_advisories/CA-93:16a.README cert_advisories/CA-95:11.sun.sendmail-oR.vul cert_advisories/CA-95:11.README The smrsh program can be obtained from ftp://info.cert.org/pub/tools/smrsh/ It is included in the sendmail 8.7 distribution. 2. Network Scanning Several incidents have recently been reported in which intruders scan a large address range using the Internet Security Scanner (ISS). As described in CERT advisory CA-93:14, this tool interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders have used the information gathered from these scans to compromise sites. We are aware of many systems that have suffered a root compromise as a result of information intruders obtained from ISS scans. You may wish to run ISS against your own site in accordance with your organization's policies and procedures. ISS is available from ftp://info.cert.org/pub/tools/iss/iss13.tar We encourage you to take relevant steps outlined in these documents: ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner ftp://info.cert.org/pub/cert_advisories/CA-93:14.README ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/packet_filtering 3. Exploitation of rlogin and rsh We have received some reports about the continued exploitation of a vulnerability in rlogin and rsh affecting IBM AIX 3 systems and Linux systems. This is not a new vulnerability, but it continues to exist. Sites have reported encountering some Linux distributions that contain this vulnerability. Information on this vulnerability and available solutions can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-94:09.bin.login.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-94:09.README 4. Packet Sniffers We continue to receive new incident reports daily about sniffers on compromised hosts. These sniffers, used to collect account names and passwords, are frequently installed using a kit. In some cases, the packet sniffer was found to have been running for months. Occasionally, sites had been explicitly warned of the possibility of such a compromise, but the sniffer activity continued because the site did not address the problem in the comprehensive manner that we suggest in our security documents. Further information on packet sniffers is available from ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README Information about detecting sniffers using cpm is in the CA-94:01.README file. What's New in the CERT FTP Archive ---------------------------------- We have made the following changes since June 1, 1995. * New Additions: ftp://info.cert.org/pub/ incident.reporting.form (the form you should fill out when reporting an incident to our staff) ftp://info.cert.org/pub/cert_advisories/ CA-95:08.sendmail.v.5.vulnerability CA-95:09.Solaris.ps.vul CA-95:10.ghostscript CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_bulletins/ VB-95:05.osf (OSF/DCE security hole) VB-95:06.cisco (vulnerability in Cisco's IOS software) ftp://info.cert.org/pub/tech_tips/ AUSCERT_checklist_1.0 (UNIX checklist developed by the Australian Emergency Response Team) * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-93:14.README (Internet Security Scanner) CA-94:01.README (network monitoring) CA-94:02.README (SunOS rpc mountd vulnerability) CA-94:05.README (md5) CA-94:11.README (majordomo) CA-95:01.README (IP spoofing and hijacked terminal connections) CA-95:02.README (binmail vulnerabilities) CA-95:05.README (sendmail - several vulnerabilities) CA-95:08.README (sendmail version 5 and IDA sendmail) CA-95:09.README (Solaris ps) CA-95:11.README (Sun sendmail -oR vulnerability) We have begun adding a note to advisory README files reminding readers to check with vendors for current checksum values. After we publish checksums in advisories and READMEs, files and checksums are sometimes updated at individual locations. * Other Changes: As we will no longer be keeping the lsof directory current, the directory and its files have been removed from our FTP site. The current version of lsof is available from ftp://vic.cc.purdue.edu/pub/tools/unix/lsof --------------------------------------------------------------------------- How to Contact the CERT Coordination Center Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details). Location of CERT PGP key ftp://info.cert.org/pub/CERT.PGP_key --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon Univ. ------------------------------ Date: 6 September 1995 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED info on RISKS (comp.risks) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for further information] CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. RISKS can also be read on the web at URL http://catless.ncl.ac.uk/Risks RISKS ARCHIVES: "ftp unix.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://unix.sri.com/risks [if your browser accepts URLs.] ------------------------------ End of RISKS-FORUM Digest 17.37 ************************