The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 11 Issue 38

Thursday 4 April 1991

Contents

o Risks of "recycled" phone numbers
Barry Wright
o Tricky application of Caller ID
Jeff Johnson
o Land your MD-11 at 15000 feet?
Eric K. Olson
o Automatic Vehicle Identification (was: driving and privacy)
Ed Ravin
o Dealing with billing errors
Scott Schwartz
o Computer Ballot Tally
Richard Wexelblat
o Open forum on computer voting system standards
PGN
o Re: Len Rose [and login.c]
Andrew Tannenbaum
o Another computer time/date processing problem
Michael Cook
o Info on RISKS (comp.risks)

Risks of "recycled" phone numbers

Barry Wright <ronin@ronin.sbi.com>
Thu, 4 Apr 91 13:04:02 EST
>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."


Tricky application of Caller ID

Jeff Johnson <jjohnson@hpljaj.hpl.hp.com>
Fri, 29 Mar 91 13:15:54 PST
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


Land your MD-11 at 15000 feet?

Eric K. Olson <olson@endor.harvard.edu>
Thu, 4 Apr 91 02:28:11 EST
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


Automatic Vehicle Identification (was driving and privacy)

Ed Ravin <eravin@panix.UUCP>
Thu, 4 Apr 91 16:41:06 GMT
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


dealing with billing errors

Scott Schwartz <schwartz@groucho.cs.psu.edu>
Wed, 3 Apr 91 20:45:08 EST
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.


Computer Ballot Tally

Richard Wexelblat <rlw@ida.org>
Thu, 4 Apr 91 15:01:12 EST
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


Open forum on computer voting system standards

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 4 Apr 91 14:29:19 PST
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.


Re: Len Rose (TK, RISKS-11.36)

Andrew Tannenbaum <trb@ima.isc.com>
Thu, 4 Apr 91 15:33:35 -0500
> 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


Another computer time/date processing problem

"29706::MLC" <mlc%29706.decnet@consrt.rockwell.com>
4 Apr 91 12:59:00 PST
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

Please report problems with the web pages to the maintainer

Top