Text File

Subject: RISKS DIGEST 15.18 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Weds 27 October 1993 Volume 15 : Issue 18

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

Contents: Saab Story: Cars rolling off the assembly line (Vernon L. Chi) Yet another date overflow bug (David Lamb) OZDISK - Big Brother Down Under? (Mike Bell) Russian Hacker Activity (David Fowler) Thank you (Lauren Wiener) Re: CERT and "security incident" handling (Doug Moran, A. Padgett Peterson, Scott Schwartz, Bruce R. Lewis, Nick Rothwell) Re: The FAA discovers HERF (Dennis Chamberlin)

The RISKS Forum is a moderated digest discussing risks; comp.risks is its USENET counterpart. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. PLEASE SEND REQUESTS FOR SUBSCRIPTIONS, archive problems, and other information to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. There are also alternative repositories, such as bitftp@pucc.Princeton.EDU .

If you are interested in receiving RISKS via fax, please send E-mail to risks-fax@vortex.com, phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for information regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; instead, as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM .

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.

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

Date: Mon, 25 Oct 93 07:39:07 -0400 From: Vernon L. Chi <chi@cs.unc.edu> Subject: Saab Story: Cars rolling off the assembly line

>From Road & Track, November 1993:

In Sweden, an empty automated Saab factory jump-started itself and assembled 24 cars and rolled them off the assembly line into the factory wall. A worker finally discovered the mishap and found an impressive pile of chrome and steel. A Saab official noted the damage was minimal. `Our assembly lines run slowly, and we have big bumpers,' he said." I like it. The robustness here was mechanical, and obviously was able to accommodate an unintended run of at least 24 cars without major damage...

[Before most of you were born, a radio comedian named Henry Morgan once had a shtick commercial for a fictitious car manufacturer:

BUSKIRKS are now rolling off the assembly line. We will start delivering them as soon as we can get them BACK ON THE ASSEMBLY LINE.

Ergo, the SUBJECT line, with PGN is delving back into his youth.]

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

Date: Wed, 27 Oct 1993 13:44:37 GMT From: dalamb@qucis.queensu.ca (David Lamb) Subject: Yet another date overflow bug

This appeared in comp.os.linux.announce today. It's surely "old hat" to risks readers, who probably remember tales of more egregious date overflows in banking systems in 1969/70 and 1975/6. I suppose that in a "free" operating system like linux, one gets what one pays for -- but I'm a bit discouraged that such simple conventional wisdom as is needed to avoid this escapes most of our practicing programmers.

If you don't use term, read no futher. If you don't know what term is, read no further.

[term is a package which allows you to open multiple sessions over a single modem dialup connection; like a rudimentary SLIP. --mdw]

Well, it had to happen. Sometime on Oct 26th, term died, probably all around the world. The problem is that a variable was defined to be 'int' instead of 'unsigned int', and so, as a result, it overflowed. This caused all the packets to stop being sent. Fun, huh?

Software Technology Laboratory, Computing and Information Science Queen's University, Kingston, Ontario, Canada K7L 3N6 (613) 545-6067

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

Date: Fri, 22 Oct 93 10:04 EDT From: bell@promis.com (Mike Bell) Subject: OZDISK - Big Brother Down Under?

This week TV Ontario re-broadcast an Australian documentary "GUMSHOE" which depicted - in fly-on-the-wall format - the work of Australian private detectives.

One of the detectives explained that the greatest changes in recent years have been the mobile phone, and "OZDISK" - a CD-ROM which he then demonstrated.

It allows the user to search and cross-reference by telephone number, street address, and name. It was implied that all the names of people living at an address were indexed.

Among the uses demonstrated: it allows the investigator to identify people living at an address from a phone number; to pretend to be a friend of the neighbours to gain a persons's confidence; to explain a presence in an area.

Presumably it allows con-men, burglars and kidnappers to do the same.

Is this a restricted publication, or can anyone get one? And what organisation is "responsible" for publishing it?

Mike Bell, Leapfrog Software Technology Inc. <71062.3656@compuserve.com> Tel: +1 905 857 4326 Snail: 172 Ridge Rd, Bolton, Ontario L7E 4V4 Canada

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

Date: Sat, 23 Oct 93 23:35:30 PDT From: fowler@oes.ca.gov (David Fowler) Subject: Russian Hacker Activity

According to the Associated Press last week, computer hackers nearly succeeded in stealing 68 billion rubles, or about $57 million, from Russia's Central Bank in August.

The unidentified hackers got into the bank's computer using a random combination of access codes, then tried to transfer the money into accounts at commercial banks. The attempt failed because the thieves lost too much time transferring the vast sums, and the bank detected the computer leak.

Since the beginning of the year, according to the AP, the Russian Central Bank has discovered attempted thefts and fraud totaling about 300 billion rubles, or $250 million.

This was only the latest in a string of thefts and attempted frauds at the state-run bank since the breakup of the Soviet Union, bank officials said. Bank officials told AP that, last year, thieves stole billions of rubles from the bank using false "avisos," or documents transferring money from one bank to another.

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

Date: Sat, 23 Oct 93 12:07:34 -0700 From: Lauren Wiener <lauren@reed.edu> Subject: Thank you

_Digital Woes: Why We Should Not Depend on Software_ has been published by Addison-Wesley, and I just wanted to thank everyone who has been posting to comp.risks since 1990. Listening in on this discussion has been a real education for me, and I don't think I could have gotten such an education anywhere else. Thanks to all of you for the honesty, the insight, the frankness, and the intelligence.

-- Lauren Ruth Wiener

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

Date: Wed, 27 Oct 93 12:28:03 PDT From: Doug Moran <moran@ai.sri.com> Subject: "security incident" handling -- comments on CERT's policy

The subject of what and how information about computer security problems should and should not be made available has been discussed here and in a variety of other forums. Typically these discussions are in abstract terms, and focusing on the difficulties of balancing competing problems. I have been encouraged to submit the below description of my interactions with CERT (Computer Emergency Response Team) because people who don't deal directly with CERT have been surprised at the extreme position that CERT takes on these matters: it is not much of an exaggeration to say that CERT's position is that they are an input-only channel. Since CERT is being used as a model for similar groups, their approach takes on even wider significance.

My background: I handle part of the management of a cluster of approx 50 Suns. Because my group collaborates with various companies and universities, I wind up getting involved in dealing with breakins at some of those other sites ("collective insecurity" :-) ). My site is well-known (we were one of the first sites on the original ARPAnet), and I am known to people at CERT -- I should have no problem getting vetted as trustworthy if CERT were to do that. The following are my personal opinions (not my employers) based on my experiences plus those of the system managers and administrators that I interact with.

Previous Incidents

__________________

Over the years, I have dealt with a variety of breakins and attempts. When it was possible to trace the cracker forward or backward, I would send the M.O. (modus operandi = profile) of the cracker (not just the holes that he tried to exploit, but also a list of symptoms that a site should look for). After the creation of CERT, I would also send this MO to them.

I now regard the minuscule effort needed to send CERT a copy of this MO a waste of time because CERT refuses to provide this information to sites that have been broken into. I have personal experience with this on both sides: 1. I have contacted CERT about a particular cracker and given a substantial profile and asked if CERT could tell me anything more about this particular cracker. All CERT has been willing to provide is their generic documents. In backtracking the cracker, I found a site that had identified the cracker's MO and reported it to CERT. 2. Similarly, I have been the one to report an MO and later be contacted by a site that had gotten nothing from CERT, but had learned of me by backtracking the cracker to a site that I had contacted.

Current Incident ________________

A site with which mine has substantial interactions was broken into by a cracker in mid-September, and consequently I got involved in helping with the problem. We very quickly found several of his tools and enough other things to constitute a reasonable signature. We contacted CERT and they claimed to have no knowledge of this particular cracker.

The cracker was using captured passwords to daisy-chain from site to site. Unfortunately, we didn't immediately find all the holes and backdoors that he had planted. Consequently, the cracker persisted in having access to that site for some time, thereby having a chance to capture additional passwords. In the followup, we found multiple other sites that had been broken into by the same cracker (coming or going). None of these had gotten any useful information from CERT.

Two days before the recent CERT announcement that there was a hole in sendmail, I got a message from the admins for that site: "he's back". They found a backdoor that he had installed, but were unable to figure out how he had gotten in to install it. Suddenly, with the announcement of the hole, several things we had seen (and reported) seemed to fall into place.

Because this cracker had earlier probed my site from various other places on the net (we had already closed the holes he was exploiting), I was concerned that he might have used this newly found hole to compromise my site (remember, he had broken into a number of the universities and companies with which we collaborate). I called CERT and asked if they could tell me what symptoms to look for to determine whether or not this hole had been used. I was told that there were definite symptoms, but that CERT couldn't tell what they were because that would give away what the hole was. I reminded them that their advisory said "** This vulnerability is being actively exploited and we strongly recommend that sites take immediate and corrective action. **" and that we had already reported a breakin-in-progress (at the site I was helping), but to no avail. I subsequently got the information I needed from another source, but only at the cost of not being able to pass it on.

One of the many other sites that had been broken into by this same cracker posted to various relevant newsgroups a list of the sites that it had determined to have been compromised (the list was several screens long). CERT posted the following response to those newsgroups: > Newsgroups: comp.security.unix,comp.sys.sun.admin,alt.security, > comp.security.misc > From: cert@cert.org (CERT Coordination Center) > Subject: Re: Security Incident -- many sites exposed. > Reply-To: cert@cert.org > Organization: CERT Coordination Center > Date: Tue, 19 Oct 1993 15:51:54 EDT > > > CERT is aware of the incident reported earlier today and we are > working to help resolve it. It is CERT policy not to publicly > disclose sensitive incident information, particularly names > of sites that are, or may have been, involved. Therefore, we will not > post the list of affected sites here or on any other netnews group. > > We are reviewing the information concerning this incident and we will > endeavor to contact all sites known to be affected within the next > 24 hours. We would appreciate your patience and ask that you not > contact us about the earlier posting, via either e-mail or telephone, > so that we can concentrate our resources on contacting and helping the > affected sites. > > CERT Coordination Center

>From what I can determine, what CERT means by "help" is that they tell the site that they have been broken into and then provide the generic documents on security patches and practices. The sites I have talked to never have gotten information specific to a particular incident. Note also that this "response" comes more than a month after the first reports to CERT of this cracker (or a very similar one).

Comments ________

Caveat: since CERT is almost exclusively an input-only channel, it is hard to determine what they knew and when they knew it.

While I agree with the sentiment in CERT's posting above (that it is undesirable to publicly identify sites that have been broken into), I cannot disagree with the action of the site that posted the list of compromised sites -- the cracker seemed to be spreading faster than he was being found and excluded. (Note that I am not identifying the site that I went to help, nor am I free to publicly discuss details).

In my opinion, CERT's policy contributed substantially to the number of sites broken into and the persistence of this cracker on the network. First, when a system administrator contacts CERT and is told that CERT doesn't recognize the pattern of a given breakin, the SysAdmin is likely to believe that he is dealing with an isolated case, either involving a local user or just one or two other sites. The MO of this cracker left little evidence to contradict this view. Consequently, a SysAdmin could easily focus on the wrong containment measures, allowing the cracker to continue to use his site as a base to attack other sites.

Second, because CERT is unwilling to release info on the various tricks and tools that the cracker was using, a SysAdmin could easily stop short in his cleanup, after finding only some of the holes the cracker was using or had installed. This is what happened at the site I was helping. This gave the cracker time to capture passwords needed to daisy-chain to other sites. Similarly, since CERT refuses to give any advice on what holes the cracker might be using, the SysAdmin may well spend his time and efforts closing holes that aren't currently being exploited, giving the cracker time to further compromise that site and others.

CERT would seem to be a classic RISKy system -- because it doesn't behave the way people think it does/should, it causes people to take the wrong actions, especially during crises. And the classic way to deal with such a system is to teach people to ignore it.

-- Douglas B. Moran

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

Date: Fri, 22 Oct 93 08:44:44 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: CERT Reports and system breakins (PGN in RISKS-15.17)

>... but this one >seemed particularly relevant to the bigger picture, which is that system and >network security stinks in most systems, particularly those on the Internet.

I tend to agree. System security which is based on a username/password evidences a single point failure, partially caused by the Internet mail scheme which, unless certain simple steps are taken, passes a fully formed account username/address in the mail header.

Over the last several months, I have been examining the situation and have come to the conclusion that there is a relatively simple means to add another layer of security that, for some reason, no one seems to use.

Back in antediluvian times, we had mainframes with terminals connected directly to ports. By which port was accessed, we knew exactly where the user was. Then cam networks and "virtual terminals". Suddenly we no longer knew where the terminal was that the access request was coming from.

With Ethernet however, every packet contains two basic addresses (TCP/IP adds two more IP addresses but that is a software fiction). These six-byte hardware addresses are burned into firmware and every card has a unique address. Originally administered by Xerox, this address consists of a three byte manufacturer's field followed by a three byte serial number. It would be very difficult (well, nothing is impossible but this would be close) for software to forge an address using commercial equipment and collisions should be obvious.

Given this number and a database to correlate the ethernet address to a particular system/location, it is possible to identify not only the user with conventional means, but also determine whether the access is from a known terminal. Further, since manufacturer IDs are unique also, if the address starts with 00:00:C0, one can tell that the terminal is PC based since those cards (Western Digital now SMC) are only used in PCs.

If then, the IP address in use was assigned to a SUN workstation, the system can then determine that something funny is going on.

More common applications would be for designation of "secure" and "insecure" terminals, refusal of certain information classes to PCs, automatic software updates by system number. The list goes on.

The unfortunate situation is that it was like pulling teeth to find first a good listing of addresses/owners (Michael A. Patton's listing from MIT - available from FTP.LCS.MIT.EDU with the name pub/map/EtherNet-codes - is the best I found), and secondly how to extract that information in a reasonable manner (Ralf Brown's "Interrupt List" will have some new entries in the next issue), but it can be done - and not just by a sniffer.

As a Proof of Principle, I put together a small .COM file that can be used as part of the login script for a Novell server to retrieve the hardware address of a PC client (well, I have PCs at home so...). This can be exported into a database lookup of known systems to identify exactly which system the client is logging in from. The synergy available from having this information should be obvious.

The program is ETHCRD and is FreeWare. It will return the following information:

1) Six-byte hardware address of the client's Ethernet card 2) Whether a packet (TCP/IP) or Novell (IPX/IPXODI) driver is in use 3) The card manufacturer's name

The important news is that It Can Be Done.

Padgett

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

Date: Fri, 22 Oct 1993 00:21:09 -0400 From: Scott Schwartz <schwartz@groucho.cse.psu.edu> Subject: Re: CERT Advisory - SunOS and Solaris vulnerabilities

I'm surprised to see the /dev/audio thing: It's been discussed on the net for years now. Since the fbtab mechanism is so simple, it's odd that SunOS doesn't ship with it taken care of, and amazing that Solaris has apparently dropped (!!) the mechanism altogether.

Two obvious risks: Sometimes an OS upgrade is actually a downgrade. Lots of other vendors probably have the same vulnerability, but no CERT advisory to nudge them to do something about it.

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

Date: Fri, 22 Oct 93 10:25:14 -0400 From: brlewis@MIT.EDU Subject: Re: CERT Advisory - SunOS and Solaris vulnerabilities

>Any user with access to the system can eavesdrop on conversations >held in the vicinity of the microphone.

Maybe this has been noted in RISKS before, but ISDN speakerphones are said to have a similar vulnerability.

Bruce R. Lewis Analyst Programmer MIT Information Systems Distributed Computing & Network Services

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

Date: Mon, 25 Oct 1993 18:17:08 +0000 From: cassiel@cassiel.demon.co.uk (Nick Rothwell) Subject: Re: CERT Advisory - SunOS and Solaris vulnerabilities

> 1. Obtain and install the appropriate patch following the > instructions included with the patch.

Hmm. If I wanted to hack into a large number of SunOS machines throughout the US, perhaps all I'd have to do is set myself up an FTP site with a reasonably official looking name (I can purchase such through a local Internet provider), disassemble and alter my copy of sendmail, and then forge some mail from CERT to various security newsgroups, saying "there is a problem with all your mail systems, we aren't going to tell you what it is, but install this binary patch anyway because we say so."

My point being that this official-looking CERT Advisory message is implicitly preaching security through obscurity. If someone will tell me what this sendmail vulnerability is, then I can test for it, install a patch, and see if it's fixed (which would give me some confidence that the patch isn't a trojan, since it addresses a discovered weakness). Without such information, I'm not going to do anything to sendmail on my SPARC just because some SWAT team says so.

Nick Rothwell | cassiel@cassiel.demon.co.uk CASSIEL Contemporary Music/Dance | cassiel@cix.compulink.co.uk

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

Date: Thu, 21 Oct 93 17:14:28 PDT From: drchambe@tekig5.pen.tek.com (Dennis Chamberlin) Subject: Re: The FAA discovers HERF (RISKS-15.14)

Winn Schwartau's article "The FAA and HERF" could be summarized: "There may be a problem. We don't know anything about it, therefore we'd better act now."

He introduces a fragment of relevant theory that, though truthful, is only sufficient to cause confusion about electromagnetic interference.

"A fundamental axiom of electronics...An electric current creates a magnetic field, which travels at the speed of light in all directions. This is the principle of radio and TV and cell phones. If you stick a wire in the air, and connect it a completed circuit, a magnetic field will induce a current flow." (more Dr. Science stuff deleted)

True enough, but the resulting induced signals are easily cancelled, shorted, or swamped out by common engineering practices that have been developed for the very reasons that, for example:

"We live in an electromagnetic sewer, and God knows we shouldn't be playing 'let's not worry about it' with computers flying planes at 37,000 feet."

For example, a coax cable within a magnetic signal field will have about the same signal induced in both in the center conductor and in the shield. Therefore, the interfering signal is almost perfectly cancelled out at the destination. This is one important function of cables. (The article makes no mention of this critical difference between wires and cables.) Other, more powerful techniques are often combined with careful attention to transmission paths.

"Antenna" is not a word that applies to cables. Antennas are not meant to amplify signals but to radiate them. In fact, real antennas are often fed by cables in order to prevent any radiation from taking place other than from the antenna itself. I have never seen a mouse on any computer connected with a wire or antenna.

I got a real laugh out of the description of the mouse and "wire" acting as antenna, and the concern about the shield not ever actually reaching True Earth/Power Company ground. Hm. Seems like the aircraft itself might also have a serious problem here. Perhaps it establishes ground through some sort of satellite link? :) (If anyone cares about the answer to this, please e-mail me.)

The techniques for controlling interference have been advanced right along with the rest of electronic engineering. Had solutions not been developed, interference would have long ago put a stop to further advances in speed, power, sensitivity, and complexity. But now we have everyday examples like car radios (very sensitive receivers) delivering pure and faithful audio within the same vehicle that is powered with an ignition system that delivers wideband 40 000 volt discharges to the plugs. Or, MRI medical imaging systems that utilize probably the strongest magnetic fields in common use, yet are controlled by computers using electronics similar to those in laptop machines.

And, the airplane itself is a mixed and intradependent package of fairly high-power emitters (radio, transponder, radar), together with computers, cables, and sensitive receivers. Airplanes may be susceptible if they are not properly designed, constructed and tested. But no convincing case for susceptibility has been made. (The quoted Newsweek article does not establish susceptibility.)

The statement "from a source close to the FAA" about installation of shielded glass suggests a conspiracy to keep it quiet. It further suggests that money is being spent to protect the FAA employees and their work environment, while ignoring the associated "risk" to airliners and passengers.

His sinister implication completes the stereotype of cheap, fast, cute, word-processed, scare journalism. It would have required only a trivial investigative effort to reveal the unexciting fact that the FAA is aware of the question, but they have not been able to demonstrate or reproduce the symptom. Mr. Schwartau concludes that this is due to deficiencies in the FAA, the equipment, or the investigators themselves.

But the designers of aircraft have anticipated that ground and airborne radar would be a routine part of the operating environment, and took care of that in design and test. FAA towers are not required to fly, and their design constraints are not the same as those of aircraft. Nor do they go through certification testing.

Perhaps the problem is so small, it is not easily seen through the grass. The reason the engineers are having trouble "trying to figure out what's happening" may be that any effect is so slight or rare, there is nothing to observe or measure. And, electromagnetic emission and interference is not exactly a new or faintly-understood science.

The scenarios of RF-terrorists are silly. A terrorist that was both crazy enough and clever enough to build a jammer would almost inevitably be frustrated as his target aircraft just flew off and ignored him.

At any rate, Schwartau's recommendation is to take drastic restrictive action based on non-knowledge. This is insufficient reason for the FAA to take "stronger protective measures" against passenger electronics.

One reason is that more serious things happen nearly every day in commercial air transport, but they generally don't fit into the fear-of-things-that- can't-be-seen category, so we don't hear of them. Instrument failures, autopilot disconnects, software errors, navigation failures and human error are among the many things that happen with more or less regularity in the huge fleet. Even very adverse failures, such as runaway trim, are part of every crewmembers' recurrent training, but are rarer because they get special attention in design.

A second reason is that way up in the front of the craft is the truly critical but redundant system called the flight crew. A very large proportion of their past and continuing training is directed not at knowing how to fly, but in knowing how (and being able) to fly when lots of things are broken. And almost as important, at recognizing that they *are* broken. So rare, speculative, and non-repeatable cases of of interference are generally not going to cause the crew to freeze and gape wide-eyed as their multiple computers drive them helplessly into the earth.

Air travel and airports are enough of an ordeal already, without further stifling passengers with restrictions that deal with such ghostly "risks". Nonetheless, the FAA has done this when there is a question of catastrophic failure, e.g. loss of control. But Schwartau sees no difference between low-level electrical interference and the integrity of the wing-attach bolts.

And, given the rare and non-repeatable nature of the symptom:

If such a blanket prohibition were effective, how would anyone know?

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

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