> [notes on autopilot connection to tanker spill.....] Another newsgroup has an article today in which the author claims to have seen the following Valdez-related tale: The installation of Coast Guard radar equipment which could have been sophisticated enough to track the errant vessel before it was too late had been deferred in order to provide more budget money for our ersatz war on drugs. Risks Digest is not the place for major social discussion on this subject, but I do find it interesting that the ebb and flow of socially-oriented politics may have ultimately had an impact on the ability of accident prevention systems to function at maximum effectiveness... [Heated discussion on budget priorities, social effects, and morality should probably be directed to misc.headlines, alt.drugs, alt.flame, or some other social newsgroup.......:-)] Dean Riddlebarger, Systems Consultant - AT&T,  348-6863 Disclaimer: Any opinions expressed are mine. I'm sometimes quite proud of them, so I won't try to give credit to my employer or anyone else...
Forget computer risks - it should be clear by now that Phobos is inhabited and that they are willing and able to neutralize large threatening objects that are aimed at them. Just wait till they send something in return - that's when we'll really need SDI.
There have been many messages in RISKS about people believing computers before people. They generally end with something like the following (taken from a recent message): > This says volumes about > the propensity to believe the computer at all costs: the customer "couldn't > be right - the computer says so." One thing to bear in mind is that the computer can be mistaken, but it can't be malicious. The computer program won't deliberately try to defraud a (bank/travel agency/government department/whatever). I would certainly hope that the bank would believe the computer over a customer with no documentation, at least until they can perform an audit. On the other hand, of course, if you CAN document your case and they still stand by the computer... that's a whole different kettle of fiche. Peter da Silva, Xenix Support, Ferranti International Controls Corporation.
I don't think there's been any more in Risks about Toronto's first foray into machine-counted votes. To recap the earlier items: many ballots were silently rejected by the (optical-recognition) machines because they were not cut accurately, and a demand for a manual recount was blocked because the election law required any recount to use the same methods as the original count. The courts must have given this some precedence, because we have already had an appellate court ruling. The ruling was that it was not reasonable to enforce that provision of the law when the method itself was clearly defective. Consequently, manual recounts were held where necessary, and in one district the result actually did change. Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, email@example.com
In RISKS 8.50, Brian Kanto (via Skip Montanaro) writes about California's attempt to make sending junk mail by facsimile illegal. I wonder how legal this is. Suppose someone here in Washington sends a junk fax to someone else in California (I know, I'm assuming negligible costs for the phone call). How does California expect to prosecute someone in the District of Columbia for violating a California law while the person is in the District of Columbia? If the law says that "a person WITHIN THE BORDERS OF THE STATE OF CALIFORNIA who uses..." it should be alright, but otherwise, there are some serious questions about infringement of interstate commerce (which is properly under the jurisdiction of the Federal Government) that need to be addressed. Of course, this whole message begs the question "How is this a risk to society?" David M. Gursky, Member of the Technical Staff, W-143, Special Projects Dept. The MITRE Corporation
This week's issue of Computerworld contains an article on page 10 that may be of interest to RISKS readers. The article is titled "Humane Society collars a chip off the old hound dog." Beginning the first week in May, the Marin (CA) County Humane Society will begin injecting microchips the size of a grain of rice into animals up for adoption. The chip can be activated by waving a scanner over the animal's back and it results in a unique 10-digit number being displayed. The number is used to query a database that contains the owner's name. The purpose of the system is returning lost pets to their owners. These implants have been available for a fee in clinics throughout Canada since last July. They have been used by some shelters and veterinarians on an optional basis in the U.S. since the last quarter of 1988. The vendor of this system is International Infopet System of Agoura Hills, CA. The relevance for RISKS? What if someone wants to use this technology as the basis for a national identity card for people.
FORWARDING OF A MESSAGE FROM JOHN LUCE: I was a Software Engineer on the Elevonic 401 project (but not on the cab software that controls the features discussed). Item 1: The sensors that are malfunctioning on the doors were viewed as unsafe by the engineers involved. However, mgt. felt the risk was small compared to the COST savings obtained by using them. 1 problem was that they needed adjustment often, but not replacement, while the older versions had to be replaced more often but were vastly more reliable while in service. Item 2: The doors are forced close to prevent the tie-up of the elevator. Poor maintenance will cause the door bumpers to not retract the door. This is an easy upkeep and will fail only if the building has decided against a periodic maintenance plan and just calls when something breaks down. The holding open of the doors causes the car to go into 'Delayed Car' mode which takes the car out of service. When the doors are finally allowed to close, the car has to intialize itself. If it is in the lower half of the building, it will run up to initialize, and run down if in the upper half regardless of buttons pushed. Item 3: The length of door open time is decided by the building owner and is put in to a Contract Table. The only thing for sure is that a door that opens answering a Hall Call will stay open longer than a door that opens for a Car Button. Item 4: The number of floor buttons pushed doesn't cause the confusion of the elevator, it's the number of buttons tempered by the weight inside the car. If the weight sensors do not show enough weight (arbitrary, but effective) for the number of buttons pushed, it cancels the buttons. To understand the implementation, the name of the module that does that is called 'KIDS'. It prevents the floor to floor runs kids like to have occur by pushing buttons and getting out of the car before the doors close. Item 5: Design intent. If someone can't read the arrow to know which way the car is running, he shouldn't be allowed to put in a car call away from the direction it's moving. Item 6: Unless this is OLD software, i.e. the building has not upgraded it, this is impossible to do. The scan and latch of buttons was placed in a 96 millisecond task. Item 7: All the engineers agree with you on this, but since Otis sells to many foreign countries (including the oriental ones), this was the only recourse left open. I'm sure better icons could have been devised. Finally, displays and voice are customer designated and maintained by the customer. If he fails to read the manual, these items will appear to malfunction. I hope this clears it up. I firmly believe, even though I no longer work there, that Otis Elevator North America R&D had the best set of s/w people I've seen overall. Any opinions expressed above are my own and not to be attributed to my present or previous employer. John Luce
From "Electronics", April 1989, page 18, news briefs: NEED DRAMS? HERE'S ONE WAY TO GET THEM If the shortage of dynamic random-access memories is abating, a band of armed robbers in California's Orange County hasn't heard about it. Over the past six months, at least five companies have been hit in late-night robberies, with the memory chips as the main target. The biggest haul was at Western Digital Corp. in Irvine, where two bandits forced an unarmed security guard to open a storage area and took some $100,000 worth of DRAMs, according to authorities. The armed robberies are a new development in the DRAM shortage, they say, with previous thefts largely being inside jobs.
From the 4/7/89 Boston Globe: "Some Bostonians are having the time of their lives eavesdropping onNynex Mobile Communications cellular phones. With the help of their trusty Radio Shack Portavision 55s, designed to pick up the audio portion of UHF television signals, these naughty people claim to have heard Secretary of Finance and Administration Edward Lashman discussing a press conference with his wife and Boston Mayor Ray Flynn checking in with his office. "It makes for a great day," says one listener who calls in sick at his job to spend the day with his ear pressed against the radio. "At 7 a.m. you hear the construction people complaining that their suppliers delivered the wrong stuff. At 9, it's the lawyers telling their clients how to lie in court. After noon the risque stuff starts..." The article goes on to say that Radio Shack no longer sells that model, and that the FCC says such eavesdropping is illegal. Steven C. Den Beste, BBN Communications Corp., Cambridge MA
CDC has a (relatively) new operating system for its Cybers, called NOS/VE (it has been around for a few years). While browsing through the tutorial manual, I came upon the section on batch jobs. It contains the following paragraphs: To submit a batch job from your terminal, you first create a file that contains the job and then specify the name of the file in the SUBMIT_JOB command. The first line of the file must contain the LOGIN command. This command specifies the user name, password and family name to be used for the job, as in the following example: login login_user=pat password=secret login_family=nve So the user name and password will be sitting there together in a disk file, in plain text. I don't think I need to elaborate on the RISKs of this. Note that the keeping of user name and password is not necessary, as the file is submitted from a terminal, where the user is already logged in. CDC apparently noticed this at some point, and in a footnote they state: "If, for security reasons, you do not want to include your password in a file, you can use [some other command]." Nevertheless, this is just a footnote, and the first thing the users are taught about batch jobs is to put their user name and password in a file! Gerard Stafleu, (519) 661 - 2151 Extension 6043 General E-mail address: firstname.lastname@example.org [Of course this should not surprise you. It is unfortunately still quite common. to find embedded passwords. In many IBM mainframe systems, for example, FILE passwords are routinely stored, shared, and multiply used -- for different files. PGN]
The Cornell Chronicle is the Administration's propaganda organ. As such, their coverage of the [Robert] Morris report is relatively one-sided, but since they got the report in advance, they summarized it. I'll put the last paragraph right here: Copies of the report are available from the Office of the Vice President for Information Technologies, 308 Day Hall, [area code 607] 255-3324. CORNELL PANEL CONCLUDES MORRIS RESPONSIBLE FOR COMPUTER WORM (By Dennis Meredith, Cornell Chronicle, 4/6/89) Graduate student Robert Tappan Morris Jr., working alone, created and spread the "worm" computer program that infected computers nationwide last November, concluded an internal investigative commission appointed by Provost Robert Barker. The commission said the program was not technically a "virus"--a program that inserts itself into a host program to propagate--as it has been referred to in popular reports. The commission described the program as a "worm," an independent program that propagates itself throughout a computer system. In its report, "The Computer Worm," the commission termed Morris's behavior "a juvenile act that ignored the clear potential consequences." This failure constituted "reckless disregard of those probable consequences," the commission stated. Barker, who had delayed release of the report for six weeks at the request of both federal prosecutors and Morris's defense attorney, said, "We feel an overriding obligation to our colleagues and to the public to reveal what we know about this profoundly distrubing incident." The commission had sought to determine the involvement of Morris or other members of the Cornell community in the worm attack. It also studied the motivation and ethical issues underlying the release of the worm. Evidence was gathered by interviewing Cornell faculty, staff, and graduate students and staff and former students at Harvard University, where Morris had done undergraduate work. Morris declined to be interviewed on advice of counsel. Morris had requested and has received a leave of absence from Cornell, and the university is prohibited by federal law from commenting further on his status as a student. The commission also was unable to reach Paul Graham, a Harvard graduate student who knew Morris well. Morris repotedly contacted Graham on Nov. 2., the day the worm was released, and several times before and after that. Relying on files from Morris's computer account, Cornell Computer Science Department documents, telephone records, media reports, and technical reports from other universities, the commission found that: - Morris violated the Computer Sciences Department's expressed policies against computer abuse. Although he apparently chose not to attend orientation meetings at which the policies were explained, Morris had been given a copy of them. Also, Cornell's policies are similar to those at Harvard, with which he should have been familiar. - No member of the Cornell community knew Morris was working on the worm. Although he had discussed computer security with fellow graduate students, he did not confide his plans to them. Cornell first became aware of Morris's involvement through a telephone call from the Washington Post to the science editor at Cornell's News Service. - Morris made only minimal efforts to halt the worm once it had propagated, and did not inform any person in a position of responsibility about the existence or content of the worm. - Morris probably did not indent for the worm to destroy data or files, but he probably did intend for it to spread widely. There is no evidence that he intended for the worm to replicate uncontrollably. - Media reports that 6,000 computers had been infected were based on an initial rough estimate that could not be confirmed. "The total number of affected computers was surely in the thousands," the commission concluded. - A computer security industry association's estimate that the worm caused about $96 million in damage is "grossly exaggerated" and "self-serving." - Although it was technically sophisticated, "the worm could have been created by many students, graduate or undergraduate ... particularly if forearmed with knowledge of the security flaws exploited or of similar flaws." The commission was led by Cornell's vice president for information technologies, M. Stuart Lynn. Other members were law professor Theodore Eisenberg, computer science Professor David Gries, engineering and computer science Professor Juris Hartmanis, physics professor Donald Holcomb, and Associate University Counsel Thomas Santoro. Release of the worm was not "an heroic event that pointed up the weaknesses of operating systems," the report said. "The fact that UNIX ... has many security flaws has been generally well known, as indeed are the potential dangers of viruses and worms." The worm attacked only computers that were attatched to Internet, a national research computer network and that used certain versions of the UNIX operating system. An operating system is the basic program that controls the operation of a computer. "It is no act of genius or heroism to exploit such weaknesses," the commission said. The commission also did not accept arguments that one intended benefit of the worm was a heightened public awareness of computer security. "This was an accidental byproduct of the evant and the resulting display of media interest," the report asserted. "Society does not condone burglary on the grounds that it heightens concern about safety and security." In characterizing the action, the commission said, "It may simply have been the unfocused intellectual meanderings of a hacker completely absorbed with his creation and unharnessed by considerations of explicit purpose or potential effect." Because the commission was unable to contact Graham, it could not determine whether Graham discussed the worm with Morris when Morris visited Harvard about two weeks before the worm was launched. "It would be interesting to know, for example, to what Graham was referring to in an Oct. 26 electronic mail message to Morris when he inquired as to whether there was 'Any news on the brilliant progject?'" said the report. Many in the computer science community seem to favor disciplinary measures for Morris, the commission reported. "However, the general sentiment also seems to be prevalent that such disciplinary measures should allow for redemption and as such not be so harsh as to permanently damage the perpetrator's career," the report said. The commission emphasized, that this conclusion was only an impression from its investigations and not the result of a systematic poll of computer scientists. "Although the act was reckless and impetuous, it appears to have been an uncharacteristic act for Morris" because of his past efforts at Harvard and elsewhere to improve computer security, the commission report said. Of the need for increased security on research computers, the commission wrote, "A community of scholars should not have to build walls as high as the sky to protect a reasonable expectation of privacy, particularly when such walls will equally impede the free flow of information." The trust between scholars has yielded benefits to computer science and to the world at large, the commission report pointed out. "Violations of that trust cannot be condoned. Even if there are unintended side benefits, which is arguable, there is a greater loss to the community as a whole." The commission did not suggest any specific changes in the policies of the Cornell Department of Computer Science and noted that policies against computer abuse are in place for centralized computer facilities. However, the commission urged the appointment of a committee to develop a university- wide policy on computer abuse that would recognize the pervasive use of computers distributed throughout the campus. The commission also noted the "ambivalent attitude towards reporting UNIX security flaws" among universities and commercial vendors. While some computer users advocate reporting flaws, others worry that such information might highlight the vulernatiblity of the system. "Morris explored UNIX security amid this atmosphere of uncertainty, where there were no clear ground rules and where his peers and mentors gave no clear guidance," the report said. "It is hard to fault him for not reporting flaws that he discovered. From his viewpoint, that may have been the most responsible course of action, and one that was supported by his colleagues." The commission report also included a brief account of the worm's course through Internet. After its release shortly after 7:26 p.m. on Nov 2, the worm spread to computers at the Massachusetts Institute of Technology, the Rand Corporation, the University of California at Berkeley and others, the commission report said. The worm consisted of two parts--a short "probe" and a much larger "corpus." The problem would attempt to penetrate a computer, and if successful, send for the corpus. The program had four main methods of attack and several methods of defense to avoid discovery and elimination. The attack methods exploited various flaws and features int he UNIX operating systems of the target computers. The worm also attempted entry by "guessing" at passwords by such techniques as exploiting computer users' predilections for using common words as passwords. The study's authors acknowledged computer scientists at the University of California at Berkeley for providing a "decompiled" version of the worm and other technical information. The Cornell commission also drew on analyses of the worm by Eugene H. Spafford of Purdue University and Donn Seeley of the University of Utah. [This item also was sent to RISKS by Spaf and by Geoff Goodfellow.]
Please report problems with the web pages to the maintainer