The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 17 Issue 37

Thurs 28 September 1995

Contents

o SpaceCom technician disables pagers massively
PGN
o Fault-Tolerant Computer System Survives Heat Wave
Paul Green
o Vote by mail
David Olsen
o Re: The latest maths bug in a Microsoft product
David M. Palmer
o Re: Identifying Numbers and E-mail
Michael L.W. Jones
o Re: Abandoned oil tank phones...
Scott Drown
o Call for Industry Papers on Information Technology Security Policy Process
Charles Brownstein
o CERT Summary CS-95:02
CERT Advisory
o ABRIDGED info on RISKS (comp.risks)

SpaceCom technician disables pagers massively

"Peter G. Neumann" <neumann@csl.sri.com>
Wed, 27 Sep 95 8:43:49 PDT

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


Fault-Tolerant Computer System Survives Heat Wave

<Paul_Green@vos.stratus.com>
Tue, 26 Sep 95 12:21 EDT

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

Vote by mail

David Olsen <olsen@Rational.COM>
Tue, 26 Sep 1995 13:57:53 -0700

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

Re: The latest maths bug in a Microsoft product (RISKS-17.36)

"David M. Palmer" <dmpalmer@clark.net>
Tue, 26 Sep 1995 17:33:19 -0400

>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

Re: Identifying Numbers and E-mail (Parnas, RISKS-17.36)

"Michael L.W. Jones" <mljones@sfu.ca>
Tue, 26 Sep 1995 14:47:49 -0700 (PDT)

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

Re: Abandoned oil tank phones... (Reifschneider, RISKS-17.36)

Scott Drown <drown@xylogics.com>
Tue, 26 Sep 95 15:59:58 EDT

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 <drown@xylogics.com> +1-617-272-8140X390 +1-800-225-3317

Call for Industry Papers on Information Technology Security Policy Process

Charles Brownstein <cbrownst@CNRI.Reston.VA.US>
Thu, 28 Sep 1995 09:37:57 +0100

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


CERT Summary CS-95:02

CERT Advisory <cert-advisory@cert.org>
Tue, 26 Sep 1995 16:26:56 -0400
[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

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

Please report problems with the web pages to the maintainer

Top