Text File

RISKS-LIST: RISKS-FORUM Digest Thursday, 17 December 1987 Volume 5 : Issue 77

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Lessons from a power failure (Jerome H. Saltzer) Squirrels and other pesky animals (Frank Houston) Security failures should have unlimited distributions (Andy Freeman) 2600 Magazine -- hackers, cracking systems, operating systems (Eric Corley) Re: can you sue an expert system? (Roger Mann) Re: Interchange of ATM cards (Douglas Jones)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:<RISKS>, GET RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

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

Date: Thu, 17 Dec 87 11:54:11 EST To: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@kl.sri.com> Subject: Lessons from a power failure From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>

About three times each year, the Cambridge Electric Company provides M.I.T. Project Athena an opportunity, at no extra charge, to check out its campus- wide power failure resiliency and cold start capability. The most recent opportunity came one week ago. We assume that Celco chose this particular time because the last week of the Fall semester has everyone (both students and Athena operations staff) stretched out about as thin as they ever get; if you are going to do a stress test why not make it really stressful?

At 11:02 a.m. on December 10 a power glitch of about a half-second duration took down 750 network workstations and 70 network servers of various types, all nominally connected in a client-server architecture, and up to that instant happily humming away doing last-minute homework assignments and final term papers. In the ensuing couple of hours we discovered two interesting things. (And of course we also learned--or I should say relearned--a half dozen less interesting things, in the same general class as remembering to keep your fire extinguishers charged.) One of the interesting things was bad (but repairable) news, the other one was good news. Both may be of interest to designers concerned with RISKS.

First, the bad news. Our most recently introduced service is a network name service that, among other things, provides automatic lookup to determine which of 33 independent network file servers is holding your files. Although it was intended to eventually run this network name service on a set of small machines dedicated to just that purpose, we initially deployed the name service as an extra process on three of our big file servers, choosing three that were known to be lightly loaded because they also provide file backup copying service. We knew, but didn't think about, the fact that the file backup copying servers were each configured with two extra, large disk drives when compared with the other file servers.

The problem became apparent as we watched the system struggle back to its feet after the power failure. The network gateways were back on the air within a few seconds; the 15 library file servers (since they export read-only file systems) were mostly back on the air within five or ten minutes, and then the 33 file servers that hold user files began to pop to life. Within 15 to 30 minutes most of them had checked out their file systems and were ready for customers. But no customers showed up, even though almost all of the 750 workstations had dutifully rebooted themselves. The reason is that the large-configuration backup servers were still picking nits out of their three-disk file systems, and hadn't gotten to the point where they could restart the name service that everyone else depended on to figure out which file server to use. About 45 minutes into the incident, the first name server woke up, and a majority of users were back on the air, after an unnecessary delay averaging perhaps 25 minutes.

Needless to say, we are expediting the installation of the small-configuration name service hosts. RISKS lesson: The independence of dedicated servers can be one of the major benefits of a distributed server/client architecture, but the benefit is only potential till you actually get around to doing it.

The good news was the discovery that there is an extra payoff in our configuration of 33 independent, modest-sized (0.5 GB) file servers as compared with, say, 4 giant file servers. When only 31 of the 33 came back up because a water cooling pump in one machine room didn't survive the power glitch, only about 7% of our 5000 student customers were affected. And most important, we had enough spare capacity that we could consider reloading the files from the latest backup tapes of those 2 servers elsewhere. Fortunately, the cooling pump got fixed before we had to do that, but the principle has stuck in our minds. It is similar to the principle in the electric power industry that your system needs (at a minimum) spare or reserve generating capacity of about the same magnitude as the largest single generating plant in the system. RISKS lesson: The smaller the largest server, the smaller the reserve capacity you need to absorb its failure. Jerry Saltzer

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

Date: Thu, 17 Dec 87 10:46:22 est From: houston@nrl-csr.arpa (Frank Houston) To: risks@kl.sri.com Subject: Squirrels and other pesky animals

It seems to me that the problem of pests infiltrating electrical and electronic equipment is not news anymore. Recall Grace Hopper's moth.

In my youth squirrels were a common cause of power interruptions when they would climb the utility pole and try to nest in the transformer outside of our house. When I grew up and went to work in a development laboratory I saw photos of a mouse that put some test equipment out of commission by crawling inside and electrocuting itself on the power connections. If it had happened to Eniac, we might we might be demousing, not debugging.

Frank Houston [houston@nrl-csr.arpa]

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

Date: Thu 17 Dec 87 01:38:22-PST From: Andy Freeman <ANDY@Sushi.Stanford.EDU> Subject: Security failures should have unlimited distributions To: RISKS@KL.SRI.COM, pgarnet@NSWC-WO.ARPA

Summary: Crackers already talk to each other - clearinghouses can't help them much. The only people who can benefit from clearinghouses are responsible system adminstrators. No matter how broadly clearinghouses distribute cracker techniques, it won't put systems run by irresponsible system adminstrators at any more risk than they already are.

Paul Garnet (pgarnet@csl.sri.com) writes: In Risks 5.71 Eugene Miya suggests

< If we are ever going to progress out of the software muck, we are < going to have to come up with mechanisms to replace all of our < anecdotal information with better information.

I agree. One part of the 'software muck' is illicit code, e.g., Trojan horses, viruses, etc. It is EXTREMELY difficult to obtain any examples of illicit code, as any organization which has been bitten by one of these bugs does not want to be responsible for exacerbating the situation by letting the illicit code out to possibly infect another system.

The software security community needs to study the diseases which we are trying to defend against, as potential defenses created in a vacuum of information will only work in a vacuum. A clearinghouse, repository, library, or whatever name one wants to give to such a function should be set up so that those of us who are trying to build defenses can have subjects to study.

There are, however, a number of sticky issues revolving about setting up such a clearinghouse.

1) How do you trust the repository? How does one know that information given to the repository will not be abused, nor will it be used against the giver?

If the information can be used again against the giver, it will be regardless of whether the breached site tells anyone. ("Fool me once, shame on you, fool me twice, shame on me.") The cracker still knows and crackers talk to each other.

2) How does the clearinghouse know who to disseminate which information to in order not to violate issue number 1? How does one decide on who has a legitimate need to see 'dangerous' information, e.g., details on viruses, trap doors, etc.

See above. The only defense comparable sites have is to find out as quickly as possible about their holes; clearinghouses should be available to everyone. A few crackers will use the clearinghouse to find out sooner than they would have otherwise, but immediate unlimited distribution gives every responsible system administrator a chance they don't have now to fix holes before cracker can slip through. Systems run by irresponsible sysadmins aren't in any more danger when everyone, not just the crackers, knows about their holes.

3) The clearinghouse must not be an information sink, sucking up information from anyone willing to donate their examples but never giving any information out. It must be clear that the purpose of the clearinghouse is to facilitate the sharing of information in a non- threatening way.

See above.

4) The clearinghouse must not be an organization that people are inherently scared of, "If I tell them what happened, what are they going to do to me?"

The clearinghouse should accept anonymous "here's how to crack operating system x", so this isn't a problem. Obviously, it shouldn't distribute anonymous solutions - the real problem is validating suggested fixes. Nevertheless, clearinghouses that do nothing but distribute "here's how to crack unix" information are valuable.

5) There must be some mechanism to validate the information coming to the clearinghouse to insure that it is correct. We do not want a repository of misleading, invalid data.

This is "easy" - all the clearinghouse has to do is try to crack a similar system that has is secure against all previously disclosed attacks. If it breaks, publish the new hole, otherwise let people know that if they aren't up to date, they're still vulnerable. Perhaps there should be two types of clearinghouses. One stores all holes while the second keeps track of holes that have been rereported in the past six months.

6) Who's going to pay for this service?

Responsible system administrators will pay for subscriptions; "evolution" will decrease the number who don't subscribe. The real problem is who is liable. Irresponsible system administrators will blame the clearinghouse even though it doesn't contribute to their insecurity. OS suppliers will be unthrilled too. Both will sue.

I think there should be competing clearinghouses. Some will specialize and may even sell fixes - they can be validated the same way any software vendor is. (Some OS vendors will run clearinghouses.) Independents will keep them honest - they'll let responsible system managers know there is a problem, and what it looks like, even if their vendor won't admit that there is one, let alone have a solution.

Many security failures are people failures. A clearinghouse will only highlight this. -andy

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

From: cmcl2!phri!dasys1!ecorley@RUTGERS.EDU (Eric Corley) Date: 16 Dec 87 08:55:30 GMT To: comp-risks@RUTGERS.EDU Subject: 2600 Magazine -- hackers, cracking systems, operating systems

There has been some talk of an article that we have published in 2600 Magazine and I wanted to make clear the reasons for our publishing such an article and what the purpose of our magazine is. The article in question is a very well documented guide to VM/CMS, run on IBM machines. It explains how the systems can be cracked, what the vulnerabilities are, and how a hacker can find what he/she is looking for. We have printed the article in two parts, the conclusion appearing in our latest issue.

2600 prints these articles because, quite frankly, people want to know these facts. Most computer hackers are not of the malicious caliber and simply explore systems to learn how they work. We find that a great many computer operators benefit greatly from the bugs and quirks that we point out.

So, in short, we aren't printing these articles on computer operating systems (UNIX, VAX, VM/CMS, VMS, etc.) and telephone systems (Sprint, MCI, AT&T, etc.) to help people break into them, NOR are we printing them to help trap computer hackers--we simply want the information to be known. Thanks for the opportunity to respond.

Eric Corley, Editor, 2600 Magazine, 2600@dasys1.UUCP, phri!dasys1!2600@nyu (NOTICE: For those interested, 2600 is published quarterly and costs $40 for a corporate sub, $15 for individual (delivered to your home) subs. Back issues are also available. Write: 2600, PO Box 752-A, Middle Island, NY 11953. (516) 751-2600.)

Eric Corley {allegra,philabs,cmcl2}!phri\ Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!ecorley New York, NY, USA {sun}!hoptoad/

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

Date: Wed, 16 Dec 87 13:09 MST From: Roger Mann <RMann@HIS-PHOENIX-MULTICS.ARPA> Subject: Re: can you sue an expert system? To: risks@csl.sri.com

No one has asked this question yet, so I will. In the original question, the expert system was a model of a financial advisory service that gives buy, sell, and hold recommendations. The question is: can you sue a financial advisory service ? If not, then how can you sue the expert system that represents that service. If you can sue, what do advisory services do to prevent themselves from paying out gobs of money to irate customers ? Then, from that, can expert system sellers protect themselves in the same fashion ?

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

Date: Wed, 16 Dec 87 09:02:52 CST From: Douglas Jones <jones%cs.uiowa.edu@RELAY.CS.NET> To: risks@csl.sri.com Subject: Re: Interchange of ATM cards

The original law requiring that all off-premise ATMs in the state accept ATM cards issued by any bank in the state was enacted in Iowa. It was immediately copied by North and South Dakota, and then by Wyoming. As a result, very soon after the introduction of ATMs, we had a 4 state uniform network (named Shazam; symbol: an S with a lightning bolt through it, making an interesting variant on the dollar sign).

Why other states have been slow to adopt this scheme is a puzzle, since the convenience to the public is so great, and the costs to the banks are so small.

The one problem with the Iowa law is that on-premise ATMs are still allowed to accept only their own brand of card, and with the public so used to free interchange of cards, mistakes at these machines can be annoying. Fortunately, the one time I was caught, the bank mailed my card to my home bank unmutilated, unlike the problems that Wexelblat described. The number of such machines that reject (or keep) foreign cards appears to be declining, probably because of the hassles they cause. Douglas Jones

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

End of RISKS-FORUM Digest ************************