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…
eddy <eddy@gen.cam.ac.uk>
Wed, 26 Jan 94 16:10:01 GMT
We had our local unix-support by yesterday helping us out with a putative
kernel reconfiguration; told me the following job after which he'd had to
do the sorting out recently:
The two principal departments of Maths here, pure and applied, face each other
around a courtyard. Someone had bunged an ethernet link out the window of one
and in the window of the other in order to get their PC in one attached to the
ethernet in the other.
When, in due course, we had a thunderstorm, the PC and the ethernet box on the
other end of the link were both totally cooked. Fortunately, the damage
stopped there. Let's hope they now stick in a gateway to connect the two
departments so no-one will try that again.
Eddy
[and not Flo. Yes, An Eddy is of course a current
running opposite to the normal flow. PGN]
E-Mail Fraud
Lori Carrig <carrigl@fire.nic.ddn.mil>
Wed, 26 Jan 1994 13:15:34 -0500 (EST)
Electronic Mail Fraud, by Lori Carrig
With the advent of Electronic Mail we have several risks associated with this
modern vehicle of information. Of these risks one is E-Mail fraud. Just like
with Mail and Telephone fraud, Electronic Mail fraud has come of age. Before
I diverge into this problem let me set an example of an incident I worked on:
I received a notice from a user that she received E-Mail promoting computer
chips for sale from a internet address. She had not received her items
which she paid for and wanted to report it. She gave the following account:
She had received and responded to this address about the sale of the described
items. After several exchanges of E-Mail from the culprit the price was
determined and she inquired to the method of payment for the desired items.
The culprit explained that they would only take Money Order. The culprit
would accept a check, but would not ship the desired items until after the
check has cleared. A name and address was given, but no phone number, to send
the check to. The culprit stated that they would ship the items after 5-7
days. After 9 days the victim sent an E-Mail message to the culprit and
inquired if they received the check. A message was sent back stating that
they did receive the check and was awaiting for it to clear the bank. After
30 days the victim had not received the ordered, and paid for, items from the
culprits.
The risk here is quite apparent. As with Mail and Telephone Fraud, E-Mail
fraud can cause extreme losses to users. What would prevent such an incident?
Well here are some of the ways I have seen:
1. Order from known companies like Intel, Microsoft, CompUSA, and so on.
2. Pay with an Credit Card. You have the right to cancel the payment
within 30 days if the items have not been received. There is other
risks associated with giving you Credit Card number out, but I will
not address them at this time.
3. Request a phone number and call the vendor to confirm the order.
The best prevention is number 1 above and common sense. Know who you are
dealing with before any monetary exchange takes place. Items 2 and 3 above
have other risks involved with them which, in turn, may be another form of
fraud.
There are other samples of E-Mail fraud, but I will not address them at this
time. I will leave that for future releases. With the estimated losses to
Computer crime ranging from $3-6 billion dollars(1) it is cause for alarm.
If you suspect that you are a victim of E-Mail fraud, contact your local
police department. Please note that only 11% of computer crimes are ever
reported to law enforcement.(2)
The opinions above are mine only and DO NOT reflect any other parties position.
Lori Carrig
carrigl@nic.ddn.mil
Footnotes:
(1) Publisher: Search, Sacramento, CA
(2) Publisher: Law and Order, September 1990
Update on voter fraud in Costella County, Colorado
Bear Giles <bear@tigger.cs.Colorado.EDU>
Wed, 26 Jan 1994 10:19:50 -0700
[Followup on election fraud report from last summer (fall?).]
A state grand jury in Denver has indicted eleven people for voter
fraud in Costella County, Colorado. In 1990, the census found
2278 adults living in the county, but there were 2536 registered
voters.
Those indicted include:
o County Clerk Roy David Martinez, charged with falsifying residency
reports in the 3 November 1992 general election.
o His wife, deputy clerk and recorder Mariconsuelo Stella Rodriquez,
charged with allowing Martinez's sister, a non-resident of the county,
to vote.
o Costella County Commissioner George Valdez, charged with aiding and
abetting voter fraud, threatening to withhold a county employee's
pay unless he voted for Valdez, and enabling a jail inmate to vote
absentee, all during the August 1992 primary.
o former County Commissioner Ernest Leo Chavez, charged with helping
an alien to vote absentee.
Also indicted were former County Commissioner Samuel Gonzales and his
wife Lisaida, Martinez's siter and brother-in-law, two sisters-in-law
of George Valdez and one of the latter's husband.
Lisaida Gonzales was registered to vote in both Costilla and El Paso
[Colorado Springs] counties. The relatives of George Valdez were
registered in both Colorado and California since the 1940s.
Bear Giles bear@cs.colorado.edu/fsl.noaa.gov
Laptop Computer Could Explode
"F. Barry Mulligan" <MULLIGAN@ACM.ORG>
Wed, 26 Jan 1994 06:01:21 -0600 (CST)
Source: Consumer Reports, Feb 94, p.125, "Recalls" column
NEC Technologies laptop computers; Battery could explode and catch fire.
Products: 13,000 computers, models PC-17-01 and PC-
17-02, sold 12/88-4/90. Model no. appears on bottom.
What to do: Turn on computer with AC adapter discon-
nected and allow battery to discharge fully. Call 800
237-2913 for replacement battery and $100 bonus.
(The image of a laptop exploding has a certain horrid fascination.)
/* barry /& mulligan@acm.org
Opening of European borders delayed by information system problems
Bertrand Meyer <bertrand@eiffel.com>
Wed, 26 Jan 94 09:04:11 PST
Source: Agence France-Presse, 26 January 1994
The Schengen agreement stipulates the opening of borders between nine
countries of the European Community (the Twelve minus Great Britain, Ireland
and Denmark). The agreement's implementation has already been delayed several
times but was now planned for February 1st. A report of the French Senate's
foreign affairs committee states that it won't be operational for another
year. According to the chairman of the committee, Xavier de Villepin, the
culprit is the computer information system, which is not yet "operational".
[This is a politically charged issue, because of fears regarding security
(read terrorism) as well as illegal immigration from outside the European
Union. I haven't seen any details about the problems of the "computer
information system". — BM]
-- Bertrand Meyer, ISE, Santa Barbara
Canada loses satellites — anyone have more info?
"Alan (Miburi-san) Wexelblat" <wex@media.mit.edu>
Wed, 26 Jan 94 10:33:03 -0500
This is from EDUPAGE, the summary service run for free by EDUCOM:
> SATELLITES OUT. Geomagnetic storms caused by solar flares knocked out
> Canada's two communications satellites within hours of each other.
> Affecting broadcasters, phone and cable companies, and other business
> subscribers, they began to question the reliability of satellite
> communications in the context of the info-highway and examine more
> land-based means of transmission. (Toronto Globe & Mail, 01/22/94 A1).
Does anyone have access to the original Globe & Mail article cited, or more
info from another source? Did this loss of equipment mean interrupted or
lost service, or did everything just switch to land lines?
When they say "knocked out," does that mean the satellite hardware is
damaged, or just that the software got wiped?
--Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard, Media Lab,
Adv. Human Interface Group wex@media.mit.edu 617-258-9168 an53607@anon.penet.fi
Risks of dynamic binding
Andrew Shapiro <shapiro@marble.Colorado.EDU>
Wed, 26 Jan 94 14:40:49 MST
A quick description of dynamic binding:
When a program is linked (the object files are put together,) certain common
routines (like the I/O calls) are copied from a standard library into
the executable file. This is called static binding. Dynamic binding allows
the library routines to be stored in one place and are joined with the
executable only when it is loaded to run. Dynamic binding saves space and
allows libraries to be updated without re-linking executables. They also
can be deleted.
The other evening I stumbled upon an interesting single point failure for Sun
Microsystem computers. While working I distroyed the /lib/libc.so.0.15 file.
To my surprise nothing works without it. I already knew that Sun's defaulted
to dynamic binding at link time, I also knew that it was possible to suppress
this option by using the -Bstatic keyword to the link editor, ld(1). What
surprised me was that the static option had not been used when building any of
the user commands. I would have expected some of the most basic commands like
ls, cp, and either tar or dd to be compiled with static linking. If this were
the case repairing the /lib/libc.so.0.15 file would be simple. Instead I was
forced to reboot from tape, install the mini-kernel and then mount the
filesystem and restore the file.
I believe the engineers that developed the dynamic binding system understood
the implications of *every* program depending on a single file and kept the
static binding option to prevent this. However, if the OS designers never
use the static option and the dynamic library is lost . . .
Andrew T. Shapiro, CSES/CIRES University of Colorado, Campus Box 449
Boulder, CO 80309-0449 (303) 492-5539 andrew@gooter.metronet.org
New museum on cryptography
Jeremy Epstein -C2 PROJECT <jepstein@cordant.com>
Tue, 25 Jan 1994 09:32:41 -0500 (EST)
There's absolutely no RISK in this article, but I thought it might be
interesting to RISKS readers.
The 24 Jan 1994 *Washington Post* has an article about a new museum of
cryptography at NSA. The author describes the runaround in trying to locate
it, finding the usual problem of NSA phone numbers which answer with
extensions and people who don't have names. The article then goes on to
describe why cryptography is so important.
The museum contains all sorts of gems of the cryptography trade, including
some old ciphering machines, displays of Civil War use of SIGINT, Enigmas
(including one that can be tried out by museum visitors), and a Cray X-MP.
The museum is located in a building surrounded by barbed wire behind
an old gas station near Baltimore. According to the author:
The National Cryptologic Museum, reached by exiting the
Baltimore-Washington Parkway east on Route 32 and heading
behind the Shell station, is open from 9am to 3pm Monday
through Friday. Some at NSA say you can reach it at
301-688-5849. Others at NSA deny that number exists.
I haven't been there (if it in fact exists :-), and would be interested
in hearing from others if it's worth the trip.
--Jeremy Epstein Cordant, Inc. jepstein@cordant.com
[I'm sure some readers will find risks. BTW, for old-timers, it was
the Colony 7 motel. I am told it is indeed open to the public. PGN]
Is Global Authentication Impossible? (Re: phony air traffic controller)
Li Gong <gong@csl.sri.com>
Tue, 25 Jan 94 14:54:55 -0800
In RISKS-15.40, John Stanley (stanley@skyking.oce.orst.edu) argued:
If there were to be such a voice authentication system, the
information would need to be readily available to every pilot. This
includes ... several hundred thousand of them. In addition, ... If
the information is that readily accessible, the bad guys can get it,
too ...
Contrary to this gloomy picture, past two decades of research in
distributed computing, especially in naming and authentication, seems
to suggest that (1) naming information can be made globally available
and (2) authentication data can be widely distributed without
compromising security (e.g., using public-key certificate technology).
Li Gong, SRI International, Computer Science Lab, Menlo Park, CA 94025, USA
Re: Spoofing Air Traffic Control
Etc Bowers <n911@pnet16.cts.com>
Wed, 26 Jan 94 16:23:35 HST
In Vol 15, issue 40, Jim Wolper stated that it would be difficult to implement
digital signatures into the IFF transponder system. The military has been
doing this for many years now. There is an IFF mode in which there is an
encrypted "code of the day" transmitted by the interregator set, to which only
a properly keyed tranponder will reply. In a very similar way, the military
mode of TACAN can encrypt ident and radial information to deny use of our
TACAN to an enemy. And of course, the military can encrypt Global Position
System transmissions to deliberately degrade it's use by non military users.
So it's not that difficult, just expensive to implement.
ETC Mark A. Bowers, Naval Computer and Telecomm., Area Master Stn, Eastern
Pacific, Wahiawa, Hawaii mbowers@nctsemh-epac.navy.mil n911@pnet16.cts.com
phony air traffic controller (Pereira, RISKS-15.39)
Cameron Strom <syscrs@devetir.qld.gov.au>
Wed, 26 Jan 1994 10:07:47 -40962758 (EST)
> an out-of-work janitor pleaded guilty to giving false radio commands
> to pilots
On January 25, the Brisbane Courier-Mail reported the following:
A teenager with a $70 radio in his bedroom intercepted air traffic control
channels and told two airline pilots to abort landings. The 17-year-old air
cadet, obsessed with planes, also gave false reports of planes in distress
and falsely instructed other aircraft for two weeks in December last year.
He had learnt how to intercept radio transmissions as a member of the air
cadets and from his time in the air traffic control tower on work experience
as a Year 10 student. The control tower had been aware that someone had
been abusing the system in the area and had been on extreme alert to make
sure the pilots received correct instructions.
The lad has pleaded guilty to prejudicing the safe operation of aircraft. He
is undergoing psychiatric assessment, and will be sentenced on March 28.
Cameron Strom syscrs@devetir.qld.gov.au Brisbane, Queensland, Australia.
Jerry Leichter <leichter@lrw.com>
Sun, 23 Jan 94 22:37:38 EDT
In RISKS-15.35, Mich Kabay reports on a Washington Post newswire story about
the Government spending on an Intelligent Vehicle and Highway System, which is
intended to provide a variety of advances leading up to the dream of
computer-controlled cars.
The article is sub-titled "Washington's Latest Billion Dollar Boondoggle", so
we know right off how it will be slanted. The story is the flip side of the
"sales job" articles one too often sees. Were the director of this program to
write a press release, it would certainly discuss all the great potential,
including the potential of parts of the system no one really has any idea how
to build, and none of the problems. The Post article discusses all the
problems, including all the problems of versions of the system no one would
consider building, without considering any of the possible advantages. In
fact, one can look through the article and construct a guide to "how to write
an article about the RISKS of a newly proposed system". Thus:
1. Compare to a system everyone loves to hate - no matter how little it has
to do with the issue at hand:
"Government spending on the little-known Intelligent Vehicle and
Highway Systems (IVHS) program is expected to exceed $40 billion
over the next 20 years. (By comparison, in the first 10 years of the
Strategic Defense Initiative, Washington spent $30 billion.)"
A more relevant comparison might be to the expected outlay of money over the
next ten years on, oh, repaving existing roads, upgrading bridges, and so on.
Also, how much of this cost is for development, and how much for deployment?
SDI was all development costs. Deployment of almost anything on the scale of
the national highway system - even something as simple as traffic lights to
help control entry at busy on-ramps - quickly runs into the billions.
2. Demand proof before anything at all can be done:
"claims of improved safety are unproven"
3. Assume a system model that is known not to be applicable:
"central computer failures could lead to massive accidents"
It's hard to imagine any reason for centralized control of such a system. Has
anyone actually proposed this?
4. Demand that the system solves problems that are outside of its purview:
"proposed fuel savings from smoother driving could be lost through
higher speeds"
"minor attention given to smart public transport, priorities for
high-occupancy vehicles"
Even if this is true, so what? Fuel savings are a social good; so is higher
speed commuting. A smart highway system would give society the ability to
make tradeoffs between them, to any desired degree. In what way is this a
negative?
Smart public transport - whatever that might mean - would be a social good if
we could get people to use it, but the fact of the matter is that most of the
population long ago "voted with their feet" in preferring cars - and not
"high-occupancy vehicles" at that - to public transport. This project does
not attempt to join the long list of failed efforts to convince people that
they really would prefer to be on a bus or train; it attempts to provide a
better implementation of the choice they've already made. Again, why is this
a negative?
5. When in doubt, name some big companies that like the idea - that can
always be relied upon to generate uproar:
"main proponent of scheme is IVHS America, supported by 500
organizations including IBM, AT&T, Rockwell, General Motors,
Chrysler, Ford"
6. Always, always stress the dangers to people, but don't mention the hazards
of existing systems.
"Participants in RISKS will shudder at the thought of testing computer
programs design to control thousands of cars in lockstep at 200 kph.
I wouldn't enjoy being part of the beta-test population."
"proponents concerned with limiting liability for failures"
"I find the concern with legal liability an alarming indication of
where we're headed."
The current "human controlled" highway system kills, what, 50,000 people a
year? It has no effective mechanism for keeping significant numbers of drunk,
drugged, or otherwise incapable drivers from wreaking havoc. It has no
effective mechanism for getting drivers to respond rationally to such problems
as inclement weather. Dealing with the ice on the roads here the last week
or so isn't nearly as scary as dealing with the idiots who think that four-
wheel-drive will magically allow them to steer and stop at high speed no
matter how slick the roads are.
The legal liability issue grows right out of this: Under the current legal
system, evidence that something is less risky than what it replaced is not
considered relevant; all that's considered relevant is that the system that
actually *is* in effect hasn't prevented some injury. The current driving
system is tolerated because it spreads the legal risk. If a new system cut
the risk 100-fold, so that only 500 people a year died because of system
problems, virtually everyone would consider that an unalloyed good - but if
the result were 500 successful, massive lawsuits against whoever created,
installed, and ran the new system, it would quickly collapse.
7. Make the technical problems appear clearly insoluble:
"Participants in RISKS will shudder at the thought of testing computer
programs design to control thousands of cars in lockstep at 200 kph.
I wouldn't enjoy being part of the beta-test population."
"I wonder how much attention will be paid to deliberate or accidental
interference?"
"How will partial or total breakdown of the control systems be
handled? Car-to-car signalling?"
"Presumably information will be transmitted through radio-frequency
modems. What will the unique identifiers be for each car. What
happens if two cars have the same identifier?"
"What methods will be put into place to prevent spurious instructions
from being accepted by car controllers?"
Sorry, but none of these strike me as particularly difficult problems. 200kph
requires reaction times that are not a problem with even fairly stupid control
systems. "Thousands of cars" are not a problem unless one visualizes a system
that controls them all from a central location. In fact, traffic control
is the ultimate distributed problem, since the automobiles involved are
distributed all over the world. The short-term choices that an automobile
controller must make involve information about at most a few tens of other
automobiles. Sure, long-term planning of routes and such requires more global
information, but this is not a safety issue, and is not time-critical.
It is easy to design "fail safe" modes for automobiles when there is some kind
of system failure; all that's necessary is to gradually slow to a stop. In
fact, this is something we handle rather poorly today - consider what happens
when a front tire blows out in heavy, rapid traffic, or the repeated instances
of multi-car collisions when visibility drops. Almost any reasonable system
would be an improvement, and would probably save lives.
This also relates back to point 3, "Assume a system model that is known not
to be applicable". While the article didn't happen to address this point,
complaints about the difficulty of creating such systems usually assume that
the most advanced form (full computer control) will exist in parallel with
the current system (full human control, pedestrians, bicyclists) on the same
roads. That makes the system much, much harder - but why would we wish to
build it that way? Highways today already assume limited access; why would we
not designate some highways - or perhaps lanes of existing highways isolated
by crash barriers - for computer controlled use only?
Really, I can't believe anyone is concerned about the difficulty of ensuring
that every car has a unique identifier. If it bothers you, use a 512-bit id
and have the car pick one randomly every time it is turned on. The chance of
a clash should be comparable to the chance that all the molecules in the car's
gasoline simultaneously happen to break apart in a spectacular fireball. It
would also make it much harder to track a particular automobile. Then again,
why does a car need a globally-unique identifier anyway unless you assume the
model of a single, central controller?
That leaves the security issues, which are of course quite real and worthy of
significant concern and careful design. But do they really look daunting
enough to make the whole project clearly impossible? One important effect of
almost any technology is that it increases the "leverage" an individual has.
This "leverage" can be used for many purposes, some of them malignant. What's
important are the tradeoffs.
As an interesting exercise, one can apply the seven techniques outlined
above - there are undoubtedly others, like "argue that the system will
disproportionately injure the poor" - to argue, early this century, that
automobiles should not be developed to replace horses. For example:
2. Demand proof before anything at all can be done:
We know how reliable horses are. Can you prove that you can build a gas
engine as reliable as a horse?
3. Assume a system model that is known not be be applicable:
It's one thing to keep supplies of hay and oats at home, but would you want
everyone to keep a tank of gasoline at home to keep his car filled up? Think
of the fire hazard!
5. When in doubt, name some big companies that like the idea - that
can always be relied upon to generate uproar:
Actually, you can list some of the same companies....
And so on.
— Jerry
Telescript risks
<blakley@vnet.IBM.COM>
Wed, 26 Jan 94 16:03:19 EST
I think the discussion of telescript risks here so far misses the two
most important points:
(1) It doesn't really matter whether telescript agents "directly manipulate the
memory, file system, or other resources of the computers on which
they execute"! If they're going to be useful as "agents", they're
going to be authorized to use the interfaces of their host systems
to do some amount of useful work. Presumably, since users don't want
to administer authorization on a user-by-user basis when the potential
user set is "everyone on the worldwide internet", either:
(a) The telescript agent on most machines is going to be a "somewhat
privileged" or "highly privileged" trusted program, with access
to a useful set of system services, utilities, and applications, or
(b) The telescript agent on most machines isn't going to have access
to much useful functionality.
If (b) turns out to be the default, then our worries are limited.
The worst permutation of (a) is that everyone installs the telescript
agent on his workstation as the equivalent of a "setuid root" program,
which allows it to do anything it wants..... Then it's just a matter
of the "bad guy" writing a program in the interpreted language which
invokes the desired functions on the remote machine.....
The bad guy will *of course* be able to do this — the whole *point*
of Telescript is to make it easy to write programs which can invoke
arbitrary functions on remote machines.
The point here is that regardless of how much *mechanism* support is
built into Telescript, the real problem is the complexity of administering
authorization policy in a network in which:
(a) There is no central administrative authority (i.e. most machines
have their own unique security administrators), and
(b) The people generating requests (i.e. releasing telescript programs
into the network) have no idea where those requests are going to
end up.
(2) But of course the really bad problem which isn't addressed by any
authentication or access control mechanism is the problem of emergent
behavior in the network. Nobody knows what the dynamics of a network
filled with end-user-written, self-routing "semi-intelligent" agents
is. My bet is that IP storms are nothing compared with the weather
we're going to get when substantial numbers of these agents start
roving around....
Usual disclaimers apply along with the following unusual one:
The author is G.R. (Bob) Blakley III (Security Architect, IBM LAN Systems,
Austin TX), NOT G.R. (Bob) Blakley, Jr. (Mathematician & Cryptographer, Texas
A&M University, Bryan TX)! Phone (512)838-8133 t/l 678-8133, FAX 838-1040
Re: Can SETI signals bear viruses?
Andrew Klossner <andrew@frip.wv.tek.com>
Wed, 26 Jan 94 12:31:01 PST
Some serious naivete here ...
"You don't need to worry about spreading viruses if you
transfer data disks (say, word processing or spreadsheet files)
between computers."
It's not so. People can, and do, spread viruses by carrying Macintosh
data disks from one machine to another. Spreading viruses via PC data
disks is a bit harder, but does happen.
"Well, hopefully if it comes to that one of our Heroic
Scientists will have the presence of mind to read the bloody
code before they run it!"
I have seen malicious programs whose source was written in such a way
that a careful read wouldn't necessarily betray its malicious
character.
-=- Andrew Klossner (andrew@frip.wv.tek.com)
Please report problems with the web pages to the maintainer