Subject: RISKS DIGEST 11.38 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Thursday 4 April 1991 Volume 11 : Issue 38 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Risks of "recycled" phone numbers (Barry Wright) Tricky application of Caller ID (Jeff Johnson) Land your MD-11 at 15000 feet? (Eric K. Olson) Automatic Vehicle Identification (was: driving and privacy) (Ed Ravin) Dealing with billing errors (Scott Schwartz) Computer Ballot Tally (Richard Wexelblat) Open forum on computer voting system standards (PGN) Re: Len Rose [and login.c] (Andrew Tannenbaum) Another computer time/date processing problem (Michael Cook) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 11, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. 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: Thu, 4 Apr 91 13:04:02 EST From: ronin@ronin.sbi.com (Barry Wright) Subject: Risks of "recycled" phone numbers >From clari.nb.telecom: SAN LUIS OBISPO, CALIFORNIA, U.S.A., 1991 APR 3 (NB) --Ron Hopson got a call at work from his neighbor who informed him police broke down his front door, and were confiscating his computer equipment. The report, in the San Luis Obispo (SLO) Telegram-Tribune, quoted Hopson as saying, "They took my stuff, they rummaged through my house, and all the time I was trying to figure out what I did, what this was about. I didn't have any idea." According to the Telegram-Tribune, Hopson and three others were accused by police of attempting to break into the bulletin board system (BBS) containing patient records of SLO dermatologists Longabaugh and Herton. District Attorney Stephen Brown told Newsbytes that even though the suspects (two of which are Cal Poly students) did not know each other, search warrants were issued after their phone numbers were traced by police as numbers attempting access to the dermatologists' system by modem "more than three times in a single day." Brown told Newsbytes the police wouldn't have been as concerned if it had been the BBS of a non-medical related company, but faced with people trying to obtaining illegal narcotics by calling pharmacies with fraudulent information... What the suspects had in common was the dermatologists' BBS phone number programmed into their telecommunications software as the Cygnus XI BBS. According to John Ewing, secretary of the SLO Personal Computer Users Group (SLO PC UG), the Cygnus XI BBS was a public BBS that operated in SLO, but the system operator (sysop) moved less than a year ago and discontinued the board. It appears the dermatologists inherited the number. John Ewing, SLO PCUG editor, commented in the SLO PC UG ewsletter, "My personal opinion is that the phone number [for the Cygnus XI BBS] is still listed in personal dialing directories as Cygnus XI, and people are innocently calling to exchange information and download files. These so-called hackers know that the password they used worked in the past and attempt to connect several times. The password may even be recorded as a script file [an automatic log-on file]. If this is the case, my sympathies go out to those who have had their hardware and software confiscated." Bob Ward, secretary of the SLO PC UG, told Newsbytes, "The number [for Cygnus XI] could have been passed around the world. And, as a new user, it would be easy to make three mistaken calls. The board has no opening screen, it just asks for a password. So, you call once with your password, once more trying the word NEW, and again to try GUEST." ------------------------------ Date: Fri, 29 Mar 91 13:15:54 PST From: Jeff Johnson Subject: Tricky application of Caller ID At the "Computers, Freedom, and Privacy" conference this week, one of the speakers, MIT sociologist Gary Marx, described an interesting use of Caller ID: A children's TV show host told kids to hold their phones up to the TV speaker. The TV station played touch tones to dial a certain number. Phone equipment at the receiving end of all those calls used Caller ID and reverse-directories to create a data-base of people who watch the show, which were then used to send junk-mail to those households. Does anyone have any documentation on this supposedly-true story? Thanks, JJ ------------------------------ Date: Thu, 4 Apr 91 02:28:11 EST From: olson@endor.harvard.edu (Eric K. Olson) Subject: Land your MD-11 at 15000 feet? My favorite part of the PBS program "Living Against the Odds" occurs during the demonstration of the MD-11's computer's ability to correct for unsafe flying situations. I've tried to quote enough to be fair to the obviously capable testing crew. Note the single verbal suggestion made by the computer: Narrator: Chief Test Pilot John Miller has to fight the computer as he tries to put his plane into a dangerous stall. Pilot: When I roll out on this heading, I'll disconnect the throttles and try and make it fly an unsafe speed. You'll notice the throttles will re-engage, and then take [maintain?] me at a safe speed. I'll do it right now. OK? You Ready? I'm disconnecting the throttles, and I'm reducing the speed. And the speed is going down, and the throttles are going forward on their own now. Because they say "You're going too slowly". Now I'm going to close them and hold them closed. I have to hold them because if I let them go they'll go forward and increase the speed. If I continue to reduce the speed, notice the bank angle limiter is decreasing. The bank angle is saying "You mustn't bank now". It's down to 5 degrees. The pitch limit indicator is going amber, at 213, telling me that's [enough?]. [Close examination of the cockpit tape reveals the plane is at 15000 feet] Pilot: I'm getting an increase in stick force. Computer: *Beep* Landing Gear. [!!!] Pilot: Stick force is telling me "Move the nose down". I'm having to pull quite hard to stop the nose going down. So I'm now holding the throttles back, and I'm having to pull very hard on the stick. And I'm having to pull harder and harder on the stick. Computer: *Alarm* [Presumably the Stall Warning] Pilot: Alright and the stick's shaking. [The plane is shown to stall] [The pilot lets go of the throttles] Pilot: And the ASC [?] goes out. [The plane recovers] No mention was made by the pilot or the narrator of the computer request for the Landing Gear. If you believe that the outside footage was truly from the same flight, the gear was up. So the computer wanted it down? Is this a good idea when your MD-11 is about to stall? The pilot seemed to completely ignore the computer request. Eric K. Olson, Editor, Lexington Software Design, 72A Lowell St., Lexington, MA 02173 (617) 863-9624 OLSON@HARVARD.BITNET harvard!endor!olson ------------------------------ Date: Thu, 4 Apr 91 16:41:06 GMT From: eravin@panix.UUCP (Ed Ravin) Subject: Automatic Vehicle Identification (was driving and privacy) At a recent meeting of the Comittee for an Auto-Free New York, a fellow from TRANSCOM, a consortium of NY/NJ regional transportation authorities described how they hope to use an Automatic Vehicle Identifaction system (AVI) that is going to be implemented in the New/Jersey-Staten Island- Brooklyn corridor to keep track of traffic speeds and alert them of possible traffic jams forming. As I understand it, here's how it will work: The local toll authorities are going to install an AVI system at existing toll points, namely the bridges that link up New Jersey and Brooklyn to Staten Island. These readers will identify vehicles that are participating in the AVI system and bill them for using the bridge. TRANSCOM wants to install more AVI readers every few miles along the highways feeding the bridges. Then they want to take the vehicle ID's from the bridges and notice when they encounter the same vehicle ID's at various points along the highways. Their computer will then be able to calculate the average speed of the tagged vehicles and set off an alarm if the average speed is below some threshold, indicating that there is a traffic incident of some kind slowing things down. It seems that this technology could also be used to generate automatic speeding tickets, perhaps even billed to the same account that's being used for the toll payments. One point to make is that TRANSCOM expects that the vast majority of vehicles participating in the AVI system will be commercial vehicles, especially trucks and busses. One could argue that privacy is less of a concern for commercial operators, especially if all their routes and itineraries are logged by other means already. It seems that as soon as someone comes up with a new way of getting computerized information about something, someone else will come up with another application for the data that wasn't in the original plan. Those of you in the Northeast will also be happy to hear that all the toll authorities from Harrisburg, PA to Buffalo, NY have all agreed to use the same AVI system for their future automatic toll collections. Ed Ravin cmcl2!panix!eravin philabs!trintex!elr ------------------------------ Date: Wed, 3 Apr 91 20:45:08 EST From: schwartz@groucho.cs.psu.edu (Scott Schwartz) Subject: dealing with billing errors I heard an interesting story on a local radio station (WPSU) today. It was about a family that had recently moved into a new house; when they got their phone bill for that month, the charge was more than 18 million dollars. They realized there was a mistake, but decided to pay the bill anyway. They wrote a check for that amount, dated it "April Fool's", voided it, and mailed it to the phone company. Bell of PA was reportedly "very helpful" in clearing up the erroneous charge. Two obvious risks include the usual problems with computer generated bills, and the ever present danger that someone on the collecting end may not have a sense of humor. ------------------------------ Date: Thu, 4 Apr 91 15:01:12 EST From: rlw@ida.org (Richard Wexelblat) Subject: Computer Ballot Tally Later this year, I'll be helping to validate the computer tally of ballots in the ACM election. In brief it works like this: Before the Validators get there, the company has opened any ballots with signatures on the outside and run the ballots through the readers. Any that fail are put aside. So when we arrive, we get four things: ballots that passed, ballots that failed, ballots that weren't opened, tally. (Another category, ballots returned for bad address, are a separate matter.) We then select at random about 1% of the "passed" group and tally them manually. Then they are run through the computer and the computer output compared with the manual tally. If 100% match skip next step If discrepancy, resolve it (manual tally error). (No machine discrepancy has yet been discovered; don't know what to do if one occurs) We then open all unsigned ballots. If a signature inside, manually add to tally; if none, ignore ballot. Certify (possibly amended) tally. Question: is this felt to be a reasonable method? If you have a simple yes/no/maybe response, please mail directly to me. If a subtantive problem or suggestion for improvement, copy risks for possible inclusion in a future posting. Dick Wexelblat (rlw@ida.org) 703 845 6601 ------------------------------ Date: Thu, 4 Apr 91 14:29:19 PST From: "Peter G. Neumann" Subject: Open forum on computer voting system standards On Wednesday 17 April 1991 in Room T640, George Washington Univ. Academic Center, 22nd and Eye (I) St. NW, Washington DC, there will be an open forum on Developing Standards for Computer Voting Systems. Roy Saltman (NIST) and Howard Jay Strauss (Princeton) will be the speakers, and Eva Waskell will moderate. All three have been quoted in or contributed to The RISKS Forum in the past, on this topic. DC Area folks should try to attend. (Someone PLEASE write a report for RISKS, and agree among yourselves who it should be.) The meeting is sponsored by the Washington D.C. chapter of CPSR (Computer Professionals for Social Responsibility). For information, phone 703-435-1283. ------------------------------ Date: Thu, 4 Apr 91 15:33:35 -0500 From: trb@ima.isc.com (Andrew Tannenbaum) Subject: Re: Len Rose (TK, RISKS-11.36) > I have yet to hear even a marginally literate Unix type claim that, despite > prosecutors' claims in press releases (where they try to create meanings and > images that they couldn't do at court), login.c is a realistic "hacking > device." Let me do that for you then. Having root access on a UNIX system X gives you access to that system, and to any other systems that trust system X (through passwordless rlogin using rhost files, and so forth). Replacing a copy of /bin/login on a UNIX system to harvest passwords gives you keys to other systems, assuming that people use the same passwords on multiple systems, as many do. So if you can replace /bin/login, then manipulation of login.c is a legitimate hacking device, and one that I have seen used in practice. (Yes, it may be possible to replace /bin/login with a replica without knowing exactly what it does, but if you're a crook, it's comforting to know whether /bin/login has tamper-resistance safeguards in it.) Andrew Tannenbaum Interactive Cambridge, MA +1 617 661 7474 ------------------------------ Date: 4 Apr 91 12:59:00 PST From: "29706::MLC" Subject: Another computer time/date processing problem As several people have noticed, we don't have to wait until the years 1999 - 2001 to be affected by bad time/date processing via computers. On our DEC VAX system on January 2, 1991, I entered the following command to get some information about system processes: $ SHOW SYSTEM Note the "Uptime" value (days hh:mm:ss). Our system isn't *that* good! VAX/VMS V5.3-1 on node GV3 2-JAN-1991 15:40:47.36 Uptime 366 04:36:58 Pid Process Name State Pri I/O CPU Page flts Ph.Mem 20200081 SWAPPER HIB 16 0 0 00:00:40.89 0 0 [rest of output deleted...] Michael Cook mlc%gva.decnet@consrt.rok.com ------------------------------ End of RISKS-FORUM Digest 11.38 ************************