Subject: RISKS DIGEST 17.37

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" <[email protected]>
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: [email protected]
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 [email protected] (508) 460-2557 FAX: (508) 460-0397

------------------------------

Date: Tue, 26 Sep 1995 13:57:53 -0700
From: David Olsen <[email protected]>
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 [email protected]

------------------------------

Date: Tue, 26 Sep 1995 17:33:19 -0400
From: "David M. Palmer" <[email protected]>
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 [email protected]

------------------------------

Date: Tue, 26 Sep 1995 14:47:49 -0700 (PDT)
From: "Michael L.W. Jones" <[email protected]>
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 [email protected]

------------------------------

Date: Tue, 26 Sep 95 15:59:58 EDT
From: Scott Drown <[email protected]>
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 <[email protected]> +1-617-272-8140X390 +1-800-225-3317

------------------------------

Date: Thu, 28 Sep 1995 09:37:57 +0100
From: Charles Brownstein <[email protected]>
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 <[email protected]>
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 [email protected]

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

[email protected]

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: [email protected]
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 <[email protected]> (majordomo) with one-line,
SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:]
INFO [for further information]

CONTRIBUTIONS: to [email protected], 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.com<CR>login anonymous<CR>[YourNetAddress]<CR>
cd risks<CR> or cwd risks<CR>, 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
************************