risks@CSL.SRI.COM (RISKS Forum) (04/05/91)
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.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 11, j always TWO digits). Vol i
summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" 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 <jjohnson@hpljaj.hpl.hp.com>
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" <neumann@csl.sri.com>
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" <mlc%29706.decnet@consrt.rockwell.com>
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
************************