Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
>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."
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
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
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
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.
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
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.
> 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
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