9-Jul-87 23:08:50-PDT,15629;000000000000 Return-Path: Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Thu 9 Jul 87 23:05:51-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA05343 for RISKS-LIST@f4.csl.sri.com; Thu, 9 Jul 87 23:07:36 PDT Message-Id: <8707100607.AA05343@csl.csl.sri.com> Date: Thu 9 Jul 87 23:05:05-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 5.10 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday, 9 July 1987 Volume 5 : Issue 10 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Firebird computer story (Paul Kalapathy) COMPUTER CLUBS FOOT (Anthony A. Datri) Re: 7 Inmates Escape; Computer Blamed! (James Lujan) Sprint access code penetration (catching the baddie) (Darrell Long) US Sprint and free long distance (Eric N Starkman, Edward J Cetron) RE: BIG RED (Eugene Miya) Risks of battery disconnections (Steve Mahan) Japanese simulation design (Sean Malloy) Hardware failures and proofs of correctness (Rob Aitken, Michael K. Smith) 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. FTP back issues Vol i Issue j from F4.CSL.SRI.COM:RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: Thu, 9 Jul 87 09:30:23 cdt From: convex!paulk@a.cs.uiuc.edu (Paul Kalapathy) To: RISKS@csl.sri.com Subject: Firebird computer story I have a friend, Mike* (not his real name), who owns a 1983 Firebird. He does a great deal of work on cars in his spare time, but his education and job are in computer science. The work that he generally does is in microcomputers and microcontrollers. Mike was interested in improving the performance of his Firebird, and happened to have a friend John* (not his real name, either) who worked for GM and had access to the design and coding for the car computers. John was willing to provide this information to Mike as a personal favor, and did so. There is a PROM in the car computer that contains the basic parameters of the engine's operation, such as fuel mixture, ignition advance, temperature compensations, etc. If I remember correctly, the PROM is a type which is pin compatible with an industry standard EPROM (i.e., the EPROM can be programmed and inserted directly into the PROM position by changing only one or two power supply pins). The information in the PROM is not necessarily set for the highest engine performance, but rather to meet federal emissions control and fuel economy regulations. Therefore, changes in the parameters in the PROM could substantially improve the engine performance, to the detriment of compliance with federal regulations. Mike proceeded to replace the PROM with an EPROM of his own programming. This resulted in a considerable improvement in the performance of his Firebird. After making this modification and adding exhaust headers to the car, it had a top speed in excess of 150mph. (After reaching 150mph on an interstate highway, Mike decided he really didn't want to know what the top speed was.) I don't recall what the top speed was before these modifications, but it was a good deal closer to 100mph than 150mph. * "John" does not wish to be harrassed by his employer. "Mike" does not wish to be harrassed by the government for modifying polution control on his car. ------------------------------ Date: Thu, 9 Jul 87 19:10:34 edt From: aad+@andrew.cmu.edu (Anthony A. Datri) To: risks@csl.sri.com Subject: COMPUTER CLUBS FOOT [DIGITAL MASSAGE?] One risk of computers that I haven't seen addressed in this forum is the risk of having your cpu fall on you. This comes from a man who several months ago had the experience of an 11/45 falling on his foot. anthony a datri cmu computer club ------------------------------ Date: Thu, 9 Jul 87 10:17:49 MDT From: jwl@lanl.gov (Jewel) To: risks@csl.sri.com Subject: Re: 7 Inmates Escape; Computer Blamed! The information concering the kidnapping, shooting, and release of the 6 other inmates is correct, however the rest of the information is misleading. The guard tower was being staffed only during daylight due to financial restrictions at the time of the escape. Now it is being staffed 24 hours a day. Although the guard tower was unmanned at the time, it was not in the field of view where the prisoners scaled the fence. That area of the fence was being monitored by motion detector sensors which were attached to a computer system. Due to several false alarms, it was decided to disable that portion of the monitoring area until the problems were solved. Also, the fence was NOT topped with the normal razor that surrounds the rest of the fences. The escape area was still under construction. The 18 foot high chain-link fence was also not covered with a fine mesh fence which made climbing the chain-link fence trivial. Normally, the fine mesh makes it near impossible to get a good hand or foot hold on the fence. It has also been mentioned that there are some design flaws in the computer surveillance system as well as the fence enclosure. The combination of weaknesses is what made the escape possible. At present, only one inmate has been recaptured the other six are still at large, and are suspected of traveling south towards Mexico. Recent sitings have confirmed this suspicion. James Lujan (aka Jewel) ------------------------------ Date: Thu, 9 Jul 87 15:04:32 PST From: darrell@sdcsvax.ucsd.edu (Darrell Long) To: risks@csl.sri.com Subject: Sprint access code penetration (catching the baddie) I know (personally) of one case where one of my ex-students decided that he needed free long distance. He would use his Apple-II (it was some time ago) to dial up the local number and try some number as an access code. He called the school's computer, so he knew that if he got a carrier then he had gotten through. To make a short story even shorter, he used sequential probing to choose the access codes. The long distance company's computer (it wasn't Sprint, he'd gotten away using their's for a long time) picked up on the sequential probing. The next thing he knew there were police wandering around his house late at night. A week later he was arrested and his computer taken away (what a terrible punishment!). The funny thing was Pac-Bell was after him to give them his "source" and find out where he had gotten the sophisticated algorithm, etc. It seems they thought he was a big time phone cracker. Darrell Long UUCP: darrell@sdcsvax.uucp Department of Computer Science & Engineering, UC San Diego, La Jolla CA 92093 Operating Systems submissions to: mod-os@sdcsvax.uucp ------------------------------ From: Eric N Starkman Date: Thu, 9 Jul 87 12:06:47 EDT To: risks@csl.sri.com Subject: US Sprint and free long distance I was reading the Wall Street Journal last week, and noticed a full page ad for the new US Sprint "FON Card." The ad included a picture of a sample card. I tried making a US Sprint call using that card number, and it worked. Further investigation revealed that ANY fourteen digit number would allow calls to be completed. In this case, the problem was fixed by the next afternoon. But Sprint is not always so prompt. I once called them to request deactivation of a code, telling them that the security of the code had been compromised. They told me that it would take at least a week to deactivate the code. US Sprint and the other companies claim to lose a lot of money from theft, but they are evaluating those losses based upon the retail value of the unauthorized calls. It is only reasonable to use retail value for calls that people would have paid for otherwise. Most people I know who (would) use unauthorized long distance codes would use them only for calls which they would not have made otherwise. The real cost of the unauthorized codes, then, is simply the long distance company's marginal cost, which is negligible. ------------------------------ Date: Thu, 9 Jul 87 22:15:30 MDT From: cetron@cs.utah.edu (Edward J Cetron) Subject: Sprint access codes (Re: RISKS DIGEST 5.9) Reply-To: cs.utah.edu!cetron@cs.utah.edu (Edward J Cetron) Organization: Center for Engineering Design, Univ of Utah The fact that the Florida gentleman received such a large bill without warning is quite suprising. Recently, my sprint access code made its way to a similar hacker's BBoard. Within days, US Sprint called me, told me what had happened and that they were actively tracking (tracing?) the sources of the phone calls. Seems that they computer systems automagically picked up on calls being made very closely spaced in time from many different cities and that they did not fit out 'usage pattern'. When my bill came out (all 30 pages worth) there was a nice letter saying to 'just pick out the calls you KNOW are yours' which was easy since my calls all originated in Salt Lake City. They specifically wanted the access code left live until they could try to track down the callers who were using it. They just called the other day and informed me of the new number and that of the several thousand dollars, they had recovered a great deal of it....All in all, they did a good job of keeping the customer happy and well informed, and impressed me with the capabilities of their software to extract features that indicate abuse. -ed cetron ------------------------------ To: risks@csl.sri.com Subject: RE: BIG RED Date: 09 Jul 87 10:49:20 PDT (Thu) From: eugene@ames-nas.arpa >... has eluded foreign experts. The so-called virus has been held responsible >for a string of computer disasters in several countries since it was first >detected in a NASA system in the United States in 1985. This is news to me (unless it's a mix-up with another incident). I would appreciate any evidence to elaborate. [Location, system type, etc.] --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene ------------------------------ Date: Thu, 9 Jul 87 15:24:47 CDT From: steve@ncsc.ARPA (Mahan) To: risks@csl.sri.com Subject: Risks of battery disconnections In reference to the reason for disconnecting the negative terminal of a car battery: Have you ever touched (accidentally) the frame or sheet metal with a wrench while disconnecting the positive terminal? Disconnecting the negative (ground) terminal first is a safety precaution for the mechanic to avoid inadvertantly shorting the battery to ground. After the negative terminal is disconnected the positive terminal may be brought into contact with the frame without ill effects. steve Steve Mahan, Naval Coastal Systems Center, (904) 234-4224. Standard disclaimer applies. ------------------------------ Date: Thu, 9 Jul 87 11:53:36 PDT From: malloy@nprdc.arpa (Sean Malloy) To: PRITCHAR%CUA.BITNET@wiscvm.wisc.edu Subject: Japanese simulation design Cc: RISKS@csl.sri.com > From: > Subject: BALANCE OF POWER > Note that 45 years ago, the Japanese war-gamed their intended attack... There were several Japanese simulations of the attack on Midway. The first simulation took into account the Japanese forces, the American forces, relative skill levels, and the like. The simulation was played, and the result of the simulation was that the Japanese lost. This was unacceptable to the admirals, since they knew that they had a superiority in force strength, better intelligence, and the advantage of surprise, so they ordered the rules of the game to be redesigned. After a couple of iterations, playing the simulation produced a Japanese victory in line with what the admirals expected from their plans. The attack was carried out according to the final simulation, whereupon the accuracy of the initial simulation was proved, with the Japanese losing most of their carrier force and being unable to conduct a landing on Midway. Sean Malloy, Naval Personnel Research & Development Center, San Diego, CA, 92152-6800 (VOICE) (619)225-6434 (soon to be malloy@nprdc.mil) ------------------------------ Date: 9 Jul 87 5:58 -0800 From: Rob Aitken To: risks@csl.sri.com Subject: Re: Hardware failures and proofs of correctness In Risks 5.8 Don Chiasson notes the problem of hardware bugs, and makes the statement "it is not possible to prove the correctness of hardware". This is only partially true. A group at the University of Calgary has recently proven the correctness of a chip design and is continuing research in the area. (Anyone interested in the references can send me mail, although I add that I am not associated with this group). As for the testing of chips once the design has been verified, Mr. Chiasson is on target, as the majority of testing schemes attempt to minimize the number of defective chips released, rather than ensure that all are fault-free. Rob Aitken Alberta Research Council, Calgary AB UUCP: ...{utai,alberta,ubc-vision}!calgary!arcsun!rob ------------------------------ Date: Thu 9 Jul 87 13:30:33-CDT From: Michael K. Smith Subject: Hardware failures and proofs of correctness To: risks@csl.sri.com In response to Don Chiasson's 6 July 87 comment "it is not possible to prove the correctness of hardware". Clearly exhaustive testing is not a practical means to accomplish this. But see: Hunt, Warren A. Jr., "FM8501: A Verified Microprocessor", Tech. Report 47, Institute for Computing Science, University of Texas, Austin 78712, February 1986. This is Warren's dissertation and describes the formal specification and definition of a microprocessor (similar in size and complexity to a PDP-11) and provides a proof that the formal definition satisfies the specifications. Essentially a set of mathematical operation are defined that describe the specification of the machine and these operations are shown to be equivalent to a graph of hardware gates. The mathematical operations are characterized by commonly used functions, such as addition, subtraction, and shifting. The implementation (gate graph) is characterized by Boolean functions applied to components of bit-vectors. The machine was specified and defined in the Boyer-Moore Logic and the proof was done using the Boyer-Moore Theorem Prover. A brief, but more readily available description can be found in Bevier, Hunt, and Young, "Toward Verified Execution Environments", in Proceedings 1987 IEEE Symposium on Security and Privacy, April 1987. This work is currently being continued at Computational Logic Inc. - Michael K. Smith ------------------------------ End of RISKS-FORUM Digest ************************ -------