The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Rutgers 'Security List' (incl. - Archives (1988)
DOCUMENT: Rutgers 'Security List' for May 1988 (14 messages, 14838 bytes)
NOTICE: recognises the rights of all third-party works.


Thought I'd relate a recent incident to the group regarding computer virus
writing and propogation.  Apparently we have a professor who thought it would
be a good experience for his students, as a project, to write (each) a
virus, and demonstrate that it works.  OK, in my opinion we're already on
shaky ground assuming the 20 or so different viruses can remain totally
isolated within the student-instructor environment.  As you can guess,
some of them have "leaked" out of the "lab".  One report indicates that
the instructor's hard disk was erased, and another that one student's
final project was eaten by his own virus.  At least one unrelated PC was
found to be infected (in the University's Micro Resource Center!).  There
are arguments going backand forth about whether this was blatantly
irresponsible, or if viral education is a good thing.  One can't even
consider firing the instructor because he's already leaving to go to
another institution.  So, this might be a good topic to kick back and
forth for a while?  What are the ethics/legalities of such an incident?
For instance, in American law & philosophy, freedom of information is nearly
sacred; is propoagation of the knowlege on how to write a virus itself a
bad thing, or only the malicious and/or negligent spreading of one and it's
symptoms/damage?  Is the passing of this knowlege to a "random" group of
students (where the professor is probably unable to evaluate each one's
future intentions or views of morality) an unethical, if not illegal, act?

Disclaimer: The above are my views, not my employer; I have not had direct
contact with the professor or his students.
Date:      Sun, 1 May 88 13:33:11 +0100
From:      Brian Randell <>
Subject:   Prestel Hacking
  The most celebrated "telephone hacking" court case in Britain so far involved
penetration of British Telecom's Prestel viewdata service. Legal history seemed
to have been made when the perpetrators were convicted of having committed
forgery! However the Appeal Court threw out the conviction, and this decision
has just been finally confirmed by the House of Lords. Thus in Britain, at any
rate, it seems that new laws will be needed to cope with such activities.

  On April 28, the Guardian carried a lengthy article, written by one of
the hackers. It is given here, in its entirety (without permssion), for the
editor to hack out those parts which are most likely to be of interest to
the RISKS readership. [Why should PGN have a British Telecom-like monopoly on
bad puns!]

Brian Randell


Steve Gold explains what really happened in the Prestel case, resolved by the
the Lords last week:

  "The first inkling I had that there was a world ready to be dialled up was
when British Telecom installed international direct dialling in my home town,
Sheffield, back in 1971. I soon discovered that you could dial certain codes
and, subject to a slight deterioration in call quality, not incur any charges.

  This cost me dear. In May 1975, along with several other Sheffield students,
I was fined (pounds)100 for placing national and international telephone calls
without payment.

  Several years later, in 1983, I bought a computer. And while I was fiddling
away with my Sinclair Spectrum, East Midlands Allied Press was busy negotiating
with British Telecom to launch a microcomputing service on Prestel: Micronet
800. Initially the service was available to users of the Acorn BBC micro, but
soon Micronet and Prestel launched a Sinclair Spectrum hard-wired modem, the
Prism VTX5000. In August 1984 I bought one for (pounds) 74.95.

  I was equipped to use Prestel, but Prestel was boring. While waiting to be
[admitted to Micronet 800, I discovered that, if you sounded plausible enough,
you could gain editing rights to unrouted pages on the Prestel database. These
pages were known as the prestel Scratchpad.

  A friend and I joined forces and developed a software editor for the
Spectrum/VTX5000 combination and, much to Prestel's incredulity, began to use
it to edit Prestel pages offline and upload them to the database. Before long,
Micronet 800 hired us to edit pages on their database.

  In the summer of 1984, an electronic acquaintance (we had never met) told me
that he'd discovered a simple ID of ten 2s and a password (1234) which gained
admission to Prestel without paying.

  That was Robert Schifreen, and the ID was a Mr G. Reynolds, whose profile
on Prestel identified him as a member of BT staff. He was entitled to look
at areas on the database not normally accessible to members of the general

  Those pages contained the nucleus of how Prestel worked, right down to the
telephone numbers of Prestel computers we'd never even heard of. One of these
"development computers" had an unusual log-on frame: it welcomed modem users
with, and prompted them to enter, their ID and password. It had a series of
numbers on its log-on frame which both Robert and myself recognised as a
Prestel ID and password.

  Keying in these numbers resulted in the user logging on (that is, gaining
admission to the database) as the system manager. The system manager could do
things with Prestel that no other user could do. this included interrogating
the user files to obtain IDs and passwords by the cartload.

  Thus, at the press of a few keys, the system manager could obtain information
that enabled him or her to log on as any other subscriber on the system. Also,
using information-provider IDs and passwords, it was possible to alter or amend

  We had hacked Prestel at the highest level.

  However, power brings responsibility, and since we were both active
contributors to the Micronet database, we approached Micronet's staff to show
them. Micronet duly contacted Prestel, who were made aware of the incredible
loophole in their security.

  Prestel strove to protect the integrity of their database. Changing
everyone's ID on the database was not worthwhile, in its opinion. Information
providers - high-ranking subscribers who rented their own pages - were seen as
a high risk, since anyone using their IDs and passwords (obtained using the
system manager ID) could alter or delete pages at will.

  So within a matter of days, Prestel changed the information-provider
passwords. But they made a mistake. Instead of changing them completely, they
merely transposed the access and editing passwords! Since Robert and I were
editors on the system (using Micronet-supplied IDs) we were notified that our
original passwords of (say) ABCD and 1234 had turned into 1234 and ABCD.

  After a phenomenal process of deduction, we applied the same transposition to
a selection of information-provider passwords in our possession. They worked.

  Fortunately for BT, information providers realised the crassness of Prestel's
attempt to plug its security and changed their own passwords, thereby barring
normal (but unauthorised) access to Prestel editing facilities to Robert and

  But amazingly, Prestel had left a trapdoor for us to use. The high-speed
update ports, by which information providers could edit their pages in bulk,
required only an editing password. Most information providers kept their own
editing password, believing that their access passwords had been changed.

  After noting a little judicious editing, Prestel was faced with the awful
truth: it's security division had said that the hacker problem had been
resolved, yet pages were being changed again under their noses. Prestel finally
changed its information-provider IDs and passwords, thereby plugging the gap.
And that seemed to be that.

  We had told Prestel (via Micronet) about the security lapse. We'd also had a
little fun at Prestel's expense. Prestel recognised what we had done, and that
we hadn't done anything stupid such as altering or deleting pages on the
database. The incident passed into history, or so we thought.

  During October and November, Prestel placed a telephone tap on Robert's north
London home telephone line. After monitoring his activities they found he was
frequently calling a Sheffield number (he was comparing notes with me). By
January 1985, they thought they had enough information to prosecute us both.

  Had we know about it, we would have expected a prosecution under the Theft
Act - for theft of (minute amounts of) electricity. But Prestel and BT were
worried about computer-hacking. IDs and passwords were being exchanged at an
alarming rate. Prestel IDs (as passwords) were assuming the same level of
security as train numbers. ID spotters (apprentice hackers) were hanging around
on Prestel, using the message boards (chatlines) to exchange passwords.

  BT logged Robert sending me an electronic mail message (using someone else's
ID and password). The message contained the ID and password of that account.
BT later produced that message in court as confirmation of our hacking
activities. Unknown to BT (and Robert) however, I had already obtained this
particular ID and password from the Prestel chatlines. I already knew that
these particular details were passing around dozens of users.

  Prestel had problems. Hordes of youthful users were staging multiple log-ons.
One particular group even boasted of its intention to "clock' an account one

  Like car mileometers, Prestel accounts had a rolling tally of the charges on
an account. These went up to (pounds) 9,999.99, at which point the meter would
roll over to zero and start again. The chatline boasters intended continually
to access chargeable areas of the database until the (pounds) 10,000 mark was
broached. Such pointless activities took place often in 1985. Prestel thought
they had tracked two major hackers in Robert and myself. In fact they had
latched onto two journalists who were compiling a dossier of online security
breaches. The real hackers were - and are - still at large.

  On Tuesday March 26, two groups of police officers and BT staff
simultaneously raided my house in Sheffield and Robert's house in north
London. We were both driven to Holborn police station in London and held
overnight and throughout most of the following day. It was with some amazement
that I discovered in the course of my interview with Detective Inspector John
Austin and BT security chief Ron Aston, that I had been arrested for hacking.
Up to that point I had suspected that someone - probably an online acquaintance
- had committed a major bank robbery.

  We were subsequently charged with committing a number of offences contrary
to the Forgery Act 1981. Forgery is, we were told, a serious offence and can
carry a prison sentence of ten years. Ten years - just for breaking into
Prestel, and telling them what we had done!

  Rather than printing dud fivers in our kitchens we had "forged" an area of
Ram (random access memory) in the Prestel computer - using our modems over the
telephone line - which existed for about one fortieth of a second before being
wiped clean. Could BT provide the instrument (the area of Ram) in court, the
judge asked. No, since the area of Ram was etherial. It was, in fact, an area
of the program known as the user segment. Our guilt or innocence hinged on
how an electronic signal was interpreted by the court.

  We were convicted and fined, but the case came up for appeal in July last
year. The three Appeal Court judges - presided over by Lord Justice Lane -
mulled over the arguments. Several weeks later, Lord Lane announced he was
quashing the conviction, calling the case a blatant attempt to mould the facts
of the case to fit the scope of the Forgery Act.

  I was dismayed to discover that BT had applied to take the case further, to
the House of Lords. But the highest court in the land concurred with Lord Lane's
decision from the Appeal Courts that, if hacking was to be considered a crime,
then a change in the law was required.

  We are free, but the issue remains unresolved."
From:  3-MAY-1988 18:56

(If you put your real name on the message, I'll feel like I'm
answering a person rather than a string of alphabet soup.)

>        I want to ask a question about computer security. Are there
> any legal obligations (British or American) on a computer user
> who finds a major flaw within a popular OS?

Legal: no. The laws surrounding computer security are in an incredibly
primitive state. In the US and some European countries, unauthorized
use of computers is now explicitly illegal; in the UK, recent
decisions I've heard about indicate that there is no law against
simple unauthorized entry. Enforcement is yet another story, ranging
from the French throwing Steffen Wernery in the nick on suspicion of
hacking, to the Germans having to catch someone at home with his
fingers in the cookie jar, with the US somewhere in between.

But I know of no law that requires an individual to report security
problems. If I attempt to draw a parallel to other industry, I don't
believe there are any laws requiring private individuals to report,
say, safety problems they become aware of. In general, concealment of
risks is only illegal where the party who hides information stands to
gain from having the information remain secret (e.g., by avoiding a
costly recall campaign or expensive safety improvements in a factory)
or has control over the risk.

But I do think people whe find a security problem have a moral
obligation to report it. People who find security problems are in
general professionals or researchers, and carry an obligation to the
advancement and improvement of the art. Reporting problems is part of
that obligation.

>						 How could a private
> individual bring a bug to the attention of a computer manufacturer
> given that site computing personnel take a dim view of anybody who
> finds these bugs?

I'm distressed to heard that site management personnel would be so
short-sighted to discipline someone who searches for security bugs.
If a security problem exists, someone will find it sooner or later;
I'd rather it were the curious but responsible hacker than someone

Do please report the problem to the manufacturer. Easier said than
done, of course. Most major computer manufacturers have large
bureaucracies dedicated to "customer service", and wading through
this bureaucracy and its rules can be tedious. DEC is no exception.
Try starting with the nearest software service office. See if you
can get through to someone technical. I like to think that we've
done a pretty good job of instilling in our technical support people
the appropriate Pavlovian response to the phrase "security problem in
VMS". (If you haven't guessed, that response is "contact engineering,

If you can't get through this way, like because you can't get past
the secretary because you don't know your service contract number
or don't have one, see if you can get through to someone responsible
at a regional office like Basingstoke. (Colorado Springs in the US.)
If this doesn't work, try the informal but direct route. The engineering
folks of most of the major manufacturers are reachable via the
internets. All you have to do is find out who they are. Look for
people who discuss security things in the newsgroups (like me here,
for example). I can't give you specific names for all time because
people change jobs, but recent mail ought to give you some leads.
Once you get electronic mail to an interested party in the company,
chances are pretty good the information will get to the right person
in a matter of days or even hours.

[You may wonder, why doesn't DEC just publish an internet address for
the express purpose of reporting security problems? It has to do with
who owns the nets and what they're supposed to be used for. By and
large, they are government funded, and are supposed to exist for
the benefit of the educational and research organizations. Having a
manufacturer make such a direct use of the public nets smacks too
much of gaining commercial benefit from a publicly funded facility.
Also, it gives rise to complaints of preferential treatment for
sites that happen to have internet access. Obviously, any information
volunteered to individuals via the internet will be put to appropriate
use by the manufacturer, but expressly setting up a service appears

If you've still gotten nowhere, you may have to try a broadcast
approach. Send a message to an appropriate newsgroup (like INFO-VAX
for VMS) to the effect "I have found a security problem in xxx and
would like to report it to the responsible party. Would someone in
engineering please contact me?" I would guess that all the
manufacturers monitor the important newsgroups (DEC certainly does),
and you should get response fast. Of course, your site people may also
be reading the newsgroup, and if this is something you haven't told
them about and they have the attitude you described above, you may
regret having done this. You'll have to weigh the pro's and con's.

There is a logical next step one might consider, which is to publish
the problem itself. This I implore you not to do. Please don't even
tell your friends. Yes, you'll get lots of attention and action, but
you'll also cause both the manufacturer but mainly the entire user
base much pain. Think about it. You're the only person (in all
probability) who knows about this problem. If you're a responsible
guy, it'll be safe with you. But there are a lot of not very nice
people in the world, and a lot of copycats. If you publicize a
security problem, you give all these dirtballs a tool to go messing up
the lives of a lot of innocent computer users.

Even publicizing a security problem to "responsible people" carries a
risk. The more people know about the problem, the greater the chance
it will get out somehow. Even if the whole story doesn't get out, if
partial or distorted information gets out, others still will know
where to look. Consider the probabilities. The typical mean time to
discovery of a security problem in VMS is a couple of years. You just
found it. But the chance that anyone else working independently will
find it in the next 6 months is fairly small. Resist the temptation to
conclude that just because you found this problem, all systems in your
company or university are at risk and must be notified immediately. It
ain't so. The bug always looks horribly simple and obvious after
you've found it. But it's buried in a million or so lines of code, and
you got lucky. It's only a problem if you tell others.

There is a set of people who disagree with the above philosophy, and
will probably jump all over me when they see this message. (I've
gotten jumped all over each time previously.) I still stand by my
position. Others will claim that once one cracker knows about a problem
you might as well assume everyone knows about it. Further, they
claim that suitably informed system managers can take their own
defensive measures if they are informed about a problem. I don't
buy it, for several reasons:

(1) My experience tells me the cracker communications aren't that good.
    Yes, some of them will post the news on bulletin boards and it
    will spread some, but they're just not that globally organized.
    The Chaos Club is an exception to this rule, but they're not

(2) You can't tell the good guys from the bad guys. Make the information
    available, and you will guarantee that it will fall into more of
    the wrong hands.

(3) Some system managers will be sufficiently competent to solve the
    problem on their own. The majority are probably not. Sorry, it
    sounds like a damned elitist thing to say, but an operating system
    is a complicated gadget, and if you fix something wrong you're
    more than likely to break something else worse. What if someone
    publishes a patch for the problem? Would you trust a patch for
    your operating system coming from someone you never heard of? If
    you would, read some of the recent mail about viruses and think

(4) You won't reach nearly everyone. The internets reach only a small
    percentage of the customer base of any of the major manufacturers.
    So you do publish a trustworthy patch for all the internet users.
    The other 90% of the installations won't get your message, and now
    they're all the more vulnerable because all the bad guys who read
    the net news know what the problem is. Not even all the folks on
    the internets will get the message. I recently saw mail go by from
    some poor soul who had not heard about the V4.4 SECURESHR bug, and
    that one has been discussed extensively in INFO-VAX for months.

I've been in this debate for some years now, and everything I've seen
and heard tells me that if you find out about a security bug, you should

(1) tell the manufacturer as effectively and directly as you can
(2) otherwise shut up.

Well, that was a long answer to a short question. But it's one of my
favorite subjects. Thanks for listening.

					Andy Goldstein
					VMS Development
From:  6-MAY-1988 19:30
I have a question about the security of TV broadcast systems.  We've all heard
of "Captain Midnight" and his interruption of HBO (or was it Showtime?) using
a satellite up-link.

The other night, while I was watching "Conan the Destroyer" (no comments about
my taste in movies please), a message came on in plain white letters overlaying
the bottom of the screen: "This program brought to you by the association of 
american leprosy societies."

This was on cable, watching a LA broadcast channel.  Does anyone know how this
could have occured?  Sorry, I don't have a video tape to back up my claim, it
was out on loan (why do you think I was watching Conan?).

From:      Rob van Hoboken <RCOPROB@HDETUD1>  13-MAY-1988 22:37
I have found many bugs and/or security exposures in MVS and as such have had
to think up a reaction to such finds.  I have done the following:
1. create a proof for submission to the manufacturer,
2. send in a documented error report to the technical rep. and a high ranking
   management type of the manufacturer.

   When after several weeks nothing has happened:
3. send the above mentioned trouble report to <trusted> colleages in other
   computer centers, and have them submit a similar report to the manufacturer.

I have made a policy of never going <public> with such exposures because of the
seriousness of the situation.  Consider a computing center being faced with
an exposure in one of its key software systems (e.g. their transaction system).
What options do they have?
1. They can not remove the software from their systems, that would lose them
   millions of dollars PER DAY.
2. They could try to hack a fix for the exposure.  Estimated time of success
   several weeks of <highly qualified> syspro work.  Risks of malfunction of
   the entire transaction system, no support from supplier.  No dice.
3. Monitor abuse of the exposure.  Difficult.
4. Contact the supplier, explain the predicament and suggest you go looking for
   a replacement of his product.  Usually successful, but it takes about half a
   year for a security fix to arrive.

I think it is immoral towards colleages in your site and other centers to
publicly announce a security leak.  Even discussing it with too many syspro
types is risky, because one of them may be a blabbermouth and spill the news
to an unfriendly hacker or newspaper type.
It happens to be our reality that you cannot close down a system on account of
a security exposure if that system is earning you money.  Fixing it is risky
and difficult, so waiting for you friendly supplier is the best you can do.

In this respect IBM has the best policy I know of:
each contract contains a clause that a security exposure shall be dealt with
within a specific time.  I've seen it work and I am impressed.  Of course
some sites never apply the fix, so not everybody will be covered, but that is
their risk.
Other suppliers (on the IBM market) do not have a similar policy.  I know of
several instances where an exposure was not even fixed after three years.
In one case I persuaded some of my friends to remove the product from their
systems and terminate the contract with the supplier.

I don't want to sound too gloomy, but the morally acceptable method will not
always yield results.  The (in my view) immoral way <may> yield long term
results, but in the period between public exposure and fix your systems are
extremely vulnarable to practically every hacker with assembler knowledge.
In no way can you guard against that many possible perpetrators.

The only argument I can come up with to defend a security through ignorance
policy, is the small number of attempts that will be made on your system.
I <may> be better to keep relatively inexperienced hackers unaware of exposures
when knowledgable folks can find out.  In the worst case it will save you
unscheduled IPLs.
From:      dasys1!  15-MAY-1988 18:30
Medeco Lock Co. had their cylinder tested by a government lab at Port
Hueneme, California.  The test, I believe, used sound waves to determine
pin height. The test was performed around 1980. 

Does anyone have any info on the test and is there an NTIS number.

Stanley Wociechowski
Big Electric Cat Public UNIX
From: (Thea Iberall)  23-MAY-1988 08:38
To:        mit-eddie!, mit-eddie!,
The instructions that are sent with the program say that when
compiled and run the program will draw a nice picture
of a turkey.  I have been informed that the program is a Trojan Horse.  It
does not draw a turkey, but it does erase all of the unprotected
files in your directory.  You might want to pass this information along to
people you know who use the networks.
From:      Liisa Rautiainen <TKOP_LR@FINOU>  23-MAY-1988 08:53
I'm studying system analysis at the University of Oulu. Now I'm working with my
pro grad thesis subject of which is information system security. During the
summer 1988 I'm going to develop an overall security program for a computer-
center. Therefore I'm interested in all aspects concerning information security
and vulnerability.

I'm very grateful if someone could give me some hints where and how to get
latest information of the owerall security programs for computer-centers or
send information about the subject:
     classifications of the system security aspects,
     computer risks, vulnerability, risk analysis,
     contingency planning and so on.

     Yours sincerely Liisa
From:  23-MAY-1988 14:45
In the 4/88 issue of Progressive Architecture:

Security: The Next Stage


Not Just Bricks and Mortar

    Highly developed design tools are beginning to emerge in areas related 
to security.  As has been the case in other areas of design 
(structual and energy systems, for example), engineers are providing
architects with computer-based techniques for analysis and design.
    One such example, apparently unique, is BombCAD(TM), developed
jointly by the Evertt I. Brown Company and the Lorron Corporation to
assess the possible effects of terrorist bombings on buildings and their
components and Occupants.
    In demonstrations of the program, using a hypothetical building and
site, BombCAD's developers are able to show a highly detailed diagram of 
bomb-induced overpressures and impulse loads at interior and exterior points
of the building.  The effiacay of new architectural and site elements - for
example, placing an earth berm at the base of a building, or specifying
stronger glazing and framing members for a lobby partition - can be assessed
    Much of the knowledge used to develop this software has been available 
in other places (for example, in monographs and tables provided in various
military design manuals and guidelines).  And, as its authors redily 
acknowledge, BombCAD has limitations (one of which is that the program's 
estimate of human injury are based only on primary plast effects, while much
empirical evidence suggest that an equal or greater number of fatalites and 
serious injuries may result from secondary and tertiary effects, such 
as flying debris or subsequent building collapse).  Still there is no denying
that the software integrates existing knowledge and gives it new 
    As security conerns continue to grow in priority among the traditional
clients for design services, we can expect more design tools of this variety
to emerge. 
- By Thomas Vanier, AIA

[Accompanying the article are two examples of the program output from
a video display]
  In a demonstration of BombCAD analysis, a car bomb (top, show as a 
white star) explodes outside a building lobby.  The program sets shock 
impulse load and overpressures (figures in yellow and red) on key parts
of the building exterior.
    BombCAD also can estimate interior blast loads and overpressures.
Red stars indicate locations of other potential bombs, whose characteristics
and effects can be modeled seperately.  A second example (above) illustrates
one of many possible placements of a so-called briefcase bomb.  The program's
flexibility allows examination of many possible bomb locations and charge 
I am currently researching "computer viruses", trojan horses, and the
like.  The report which I plan to prepare will include descriptions
of various public domain and commercial software which claim
to protect from or detect viruses.  Some examples of software
I am evaluating are: DataPhysician, Triad line, Protec, VI-RAID
(commercial), Flushot+, Novirus, Checkup, and CRCDOS (public domain).

If anyone is currently using any of these programs, or others like
them, I would greatly appreciate your sending me information
describing how they are implemented, access controls you have
in place, and anything else which you think will be of help.

I will be happy to describe the results of my research on SECURITY.

Neil Goldman   (NG44SPEL at MIAMIU.BITNET)
From:  27-MAY-1988 01:27
>Medeco Lock Co. had their cylinder tested by a government lab at Port
>Hueneme, California.  The test, I believe, used sound waves to determine
>pin height. The test was performed around 1980. 

I have never seen any info about tests of that sort... It sounds kind
of pointless to perform this sort of test on a Medeco though.  Once
you know pin heights, you still don't know the rotation of the assorted
pins, so you still have a decent number of permutations in order to find
the correct combination.  I can see more use in performing this sort of
test on a Best cylinder, or some other cylindar that doesn't rotate the

From:  27-MAY-1988 11:15
This note is addressed to the entire list because (a) of its general
interent and (b) Liisa's original note did not indicate which network
to respond to.  (Liisa, please contact me directly.)

I recommend "Building A Secure Computer System" by Morrie Gasser, Van
Nostrand Reinhold, 1988 and "Tutorial: Computer and Network Security"
by Abrams & Podell, Computer Society of the IEEE, (Computer Society
order number 756, IEEE Vatalog number EH0255-0), 1987.

- Marshall D. Abrams, phone: (703) 883-6938
   The MITRE Corporation, 7525 Colshire Drive
   Mail Stop Z670, Mc Lean, VA   22102
   Alternate e-mail address:
From:      Douglas Humphrey <>  27-MAY-1988 14:00
An interesting possibility for lock work would be a Sonogram system,
used to look into peoples internal organs, etc. with sound waves. These
seem to be pretty portable. I wonder how well they would work. 
Anyone know more about this?

From:      PALMER   at DUVM  29-MAY-1988 16:05
Taken from the Sydney Morning Herald and the May 22, 1988 issue of
Awake magazine.

In an effort to outwit phonebooth theives, Telecom, Australia's government-
owned telephone company, has fitted the susceptible booths with Kirk safes.
Named after the worker who invented them, the safe has so far proved 100-
percent effective. As mentioned in the Sydney Morning Herald, it has with-
stood 'oxy torches, ramset guns, angle-grinders, hydraulic jacks, pulley
clamps, centre-punches and bricks.' Ironically, the new safes appear to have
led to an increase in vandalism, as theives frustrated by the tough safes
vent their anger on the booths. Telecom reports that the current rate of
smashed glass and ruined handsets and cords is at a new high of 3,000 cases
per month.