The RISKS Digest
Volume 14 Issue 3

Tuesday, 10th November 1992

Forum on Risks to the Public in Computers and Related Systems

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

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…

Contents

"To ensure the continuing access of law enforcement"
Jyrki Kuoppala
Credit Thieves
Paul Robinson
Concerns about quality in products of modern technology
Ralph Moonen
New emphasis for SDIO
Diego Latella
Accountant's error catches thief!
Joe Grace
Cellular misinformation
Barry C. Nelson
Re: Key Registration
Alec Isaacson
Peter Wayner [2]
Andrew Klossner
Re: Interesting/obscure interaction between users
Rich Kulawiec
Info on RISKS (comp.risks)

"To ensure the continuing access of law enforcement" [Re: Denning...]

Jyrki Kuoppala, Helsinki University of Technology <jkp@cs.hut.fi>
Tue, 10 Nov 1992 13:29:31 +0200
The Russian government is going to pass a law requiring furniture manufacturers
to build microphones and radio transmitters inside every sofa, chair, and table
manufactured.  A high official from the Russian government was reported to say:

  We just aren't able to function any more without a law like this.  After the
  Soviet Union ceased to exist, the United States government has hired over 50
  percent of the KGB staff and we are losing the ability to watch criminals.
  They have the need, and they have the money, and they value experience you
  couldn't have gotten anywhere else.  Thus, our law enforcement has suffered.
  When this law passes, we can catch all criminals even before they have time
  to commit the crimes.

It is planned that at a later stage when Russia has the technology to do it, a
similar law will be passed for dentists to install the same hardware in tooth
fillings.

For people who have doubts that this would be a return to the former Soviet
Union policies of watching for political dissidents, the official says:

  Absolutely not.  We have learned from our past mistakes.  It is only natural
  that we want to maintain our ability to catch criminals in the changing times
  — the changes in the job market are taking all our KGB men for a country
  where there's money and where there's a flourishing job market, and it's only
  fair we should keep our law enforcement at the high level we have managed to
  get it.  Thus we are not even increasing our resources, we are just keeping
  them the same.  The tapes will be used only to catch criminals, and a court
  order will be required before we will listen to the tapes.  Trust us, we're
  the Government and we are here to help our citizens.

The law also requires that if anyone sitting on a sofa or a chair, or at a
table, speaks any other language than Russian, she or he must be able to
provide an interpreter who will translate his talk to Russian if the law
enforcement decides there's a legitimate need to listen to the tape of the
conversation.  To make this possible, the name and address of the interpreter
must be clearly said aloud in Russian near the table/sofa/chair before each
conversation in any language other than Russian.

//Jyrki
              [Although April Fools' Day is still far away, Guy Fawkes'
              Day was last week.  Mayhaps this is appropriate?  PGN]


Credit Thieves [also submitted to the privacy digests...]

"Message Center" <FZC@CU.NIH.GOV>
Mon, 09 Nov 1992 22:23:37 EST
(Really Paul Robinson — TDARCOS@MCIMAIL.COM)

Article Summary, "The Credit Thieves" (Washington Post, Nov. 9, Page D5),
"They Take Your Identity, Then Your Good Name."

In "The Credit Thieves" article author Stephen J. Shaw asks if you have checked
your credit rating lately; some thieves have been known to find people's
personal information, then create new identities - and new credit histories -
for some people.  Apparently name and address is enough to be able to "borrow"
someone else's credit information.  Some so-called "credit doctors" charge $500
to find someone else with the same or similar name and a clean record, and give
the buyer that person's credit record.

Shaw declares personal exposure to credit fraud: his credit rating showed
"almost $100,000" in credit, services and merchandise ("loans, credit cards,
personal bank loans, plane tickets, home-entertainment systems, computers,
clothes, furniture, cellular telephones and a slew of other consumer goodies")
granted to "him" even though he lives in Washington DC, and the credit granted
to "him" was to someone in Orlando Florida, and he's never heard of the things
claimed to be charged to him.

He only found out about the incident when he applied for credit with an
organization and they asked him why he didn't declare all the OTHER credit
cards and such that he has.

Apparently almost anyone with access to a computer terminal with access to a
regular credit reporting agency can probably find out your credit history.

His "Credit Double" was only caught because he tried to buy a house using
Shaw's name.  The Secret Service is the agency that handles trying to catch
people who do this.  The "credit mugger" is in jail awaiting trial for four
counts of bank and credit fraud.

Happy ending, eh?  NOT.  Now getting rid of the inaccurate and fraudulent
credit requests is a job in and of itself.

"Equifax had deleted five of the bogus accounts, kept another four on my report
and added three new ones.  TRW told me that most of the disputed accounts had
been deleted because the creditor had not replied to TRW's inquiry, but added
that the 'creditor may re-report item.' stating , in effect, that the accounts
could reappear in future editions."  Trans Union did not have the incorrect
accounts, but still had the Florida address.  TRW also has his address listed
as Florida.

A New York State agency found six out of 17 credit reporting agencies which
advertised would sell credit histories without any attempt to verify the
purpose of the request.  An executive at TRW told a 1991 Congressional hearing
that "if someone is willing to lie to get a consumer report on another
individual, there is nothing in the present law to act as a deterrent."

Apparently it's not all that hard even to get someone's credit report legally.
The Fair Credit Reporting Act (FCRA) allows anyone with "a legitimate business
need for the information" can get your report; this includes prospective
creditors and employers.  "This loophole covers anything from renting an
apartment to paying for something by check to joining a health club or a dating
service.  Reports can be ordered legitimately by employers checking on
employees, insurance companies writing policies, someone trying to collect a
debt, and government agencies deciding to grant any form of assistance or
licenses."

The article notes one can request not to be put in the list of "pre-screened"
or "targeted" people that credit reporting agencies sell to companies that
sometimes offer credit.  You can also ask to be taken off mailing lists by
writing the Direct Marketing Association, Mail Preference Services, 11 West
42nd St, Box 3961, New York, NY 10163-3861.  They can also take requests just
to remove your telephone number from some lists.

The article recommends contacting each of the three major agencies twice
yearly, and at least 6 months before a major purchase, because some of them
don't get what the others have.  If something is wrong, contact the creditor
directly as well as the reporting agency.  If you can't get something
corrected, ask to have a statement inserted in your record.

If you're not satisfied, you can write the Federal Trade Commission at
Correspondence Dept, Room 692, Washington DC 20580.

The major credit reporting agencies are:
 - Equifax, Box 740241, Atlanta GA 30374    1-800-685-1111
 - Trans Union, Box 7000, North Olmsted, OH 44070
   Regional Offices:
   - Box 360, Philadelphia, PA, 19105         215-569-4582
   - 222 South First St., Suite 201,
     Louisville KY 40202                      502-584-0121
   - Box 3110, Fullerton, CA 92634            714-870-5191
 - TRW National Consumer Relations Center,
   12606 Greenville Ave., Box 749029,
   Dallas TX 75374-9029                       214-235-1200
   (TRW allows one free report a year by mail from)
   - TRW, Box 2350, Chatsworth CA, 91313-2350

Paul Robinson — TDARCOS@MCIMAIL.COM   [Disclaimer omitted...]


Concerns about quality in products of modern technology

<rmoonen@ihlpl.att.com>
Tue, 10 Nov 92 06:39 CST
I have been a regular reader of the RISKS forum for quite a while now, and the
situation seems to be that more and more people are becoming aware of the risks
associated with modern technology.  However, also increasing is the amount of
life-threatening accidents/near-accident/malfunctions/errors in computers and
related other electronics. Some people have proposed measures to make sure
certain quality standards are met. I can still remember the proposition for
having software professionals register themselves as such. Much was said at
that time, and the proposal got bombed. ISO has a set of standards (the 9000
series) for quality, which we adhere to within the company I work for. Others
have proposed plans, but none really seem to get the attention they deserve,
and if they do, they die a certain death after a while.  After having read 'Zen
and the Art of Motorcycle Maintainance' (highly recommended) and the ideas
about quality described in that book, I think technology desperately needs to
get in touch with reality again. I have thought about this, and have come up
with a set of situations that can adversely influence the quality of a project
or new technology. Furthermore, I would like to hear your views on the
countermeasures I propose. Just to be clear, I am in no way a quality-expert,
just a programmer who tries to keep in touch with reality, and reports as such.
The way I see it, the following are major contributors to bad quality of a
project/product:

Before implementation:

1) Concessions during design w.r.t. costs, politics, human factors.
   I realise some consessions must be made sometimes, but I have seen
   a lot of projects go down because of too many concessions.

2) Too rigid a view of what is possible/impossible.
   As seen often here, some systems think it's impossible for
   people to have 1-letter names, resulting in chaos. Others think
   it is possible to positively identify people by just a subset of
   their personal data available. Many more examples are to be found,
   but basically they all boil down to the fact that the input/output
   requirements are context-sensitive. Don't forget the Fringe-Factor (TM)!!

3) Future needs are disregarded too often.
   "Works as designed" is a standard way of getting out of this, but
   isn't a solution. Some thought *must* be given to future needs
   when designing a project

4) Compatibility needs.
   If a product is intended to work together with a different product,
   it should be clear during design exactly how the other product operates.


During implementation:

1) On the fly changes to the design, usually a result of too high a cost
   or implementors just not being up to their task. If you have a good
   design, stick too it, or change it only when it *adds* quality.

2) The tools to do the job turn out to be defective. In stead of
   replacing the tools, too often implementors are forced to use
   the old ones, thereby reducing quality of the end-product.

3) Mis-communication between implementors and supervisors of a project.
   Things are heard like "You want it next *week*?? I thought you said
   next *month*!!" Several variations on this theme come to mind :-(

4) Loss of oversight over project. Every implementor must have a
   general view of the totality of the project. The final quality
   is *his* responsibility. Details are OK, but don't loose the "feeling".

After implementation:

1) Incomplete testing of the product before delivery. Too little time
   is taken to test the product, and a product will be under-developed
   when it reaches the marketplace. Combined with point 2 this
   leads to extremely counterproductive results.

2) Rigidity of supplier.
   After the product has been delivered and installed, a provider
   should support the project with a total commitment to quality.
   Usually this is done by means of a maintenance-contract or
   an update-contract, but I think it shouldn't stop at that.
   Too often a product is only then corrected, if the customer
   reports the failure, even if supplier knew about it long ago.
   A supplier should do everything in its power to ensure the
   integrity of the product. Alas, usually the supplier won't do
   anything, even if told frequently.

3) Untrained personnel handling the new product/project.
   After said product has been delivered, unknowledgeable personnel
   often get thrown in at the deep end, sometimes with disastrous results.

While all these points are pretty straight-forward, when seen as a list, it
immediately becomes clear where most manufacturers fail.  While they don't
cover all points, I believe the following countermeasures could increase
overall quality.

1) Start design from specifications which are as context-insensitive
   as possible.
2) As I said before, don't forget the Fringe-Factor (TM).
3) Survey possible future needs *before* design.
4) Make sure you stick to the design, once it is accepted. If it costs
   more, you have failed in the initial estimate, and you should ensure
   that you can continue the project. It will pay off.
5) Check methodology and tools before implementation.
6) Make it exactly clear which secondary requirements there are to
   a project. Both the implementors and supervisors should have the
   best communication about this.
7) Make sure every developer of a product is aware of what part
   of the project he is working on, and why. Ensure he has at least
   a good working knowledge of the other parts of the project.
8) If the product is complex, then supplier should provide the
   client with an opportunity to give the clients employees and future
   users  of it's product a training in the use of this product.

If these points are taken well, I think we would see better products, which are
not necessarily more expensive. Note that I haven't touched the subject of user
interaction, but that's because I think it's a completely different field, and
is more subject to psychology than technology. Maybe some net.psychologist can
shed his/her light on this? Oh, BTW, if you plan on sending me email replies on
this, do so to:
                          accucx.cc.ruu.nl!hairy%knoware.ruu.nl

It is my private email account, so my email won't clog up AT&T's machines.

--Ralph Moonen


New emphasis for SDIO

Diego Latella <latella@cs.utwente.nl>
Tue, 10 Nov 92 10:30:15 +0100
>From  "Disarmament Newsletter - Newsletter of World Disarmament Campaign"
      United Nations Vol. 10, No.3 - June 1992

  New emphasis for SDIO

  The US Strategic Defense Initiative Organization (SDIO) has moved
  to cut its funding for space-based systems in order to increase
  its ability to deploy a ground-based system in conformity to the United
  States Missile Defense Act of 1991.
  The system proposed by this Act would be in compliance with the Treaty
  on anti-ballistic missiles  and would have the goal of providing
  a ground-based SDI system by 1996 with the capacity to defend most
  of the continental United States. This has lead to reductions in
  funding the "brilliant pebbles" space-based intercepter programme.

This on my opinion seems extremely dangerous since

1) It speaks explicitly of a *deployment* program.

2) It is in *compliance with ABM Treaty*.

3) It speaks again of *defending most of the US*.

4) Being ground-based and after the (supposed) "success" of patriots
   in the Gulf War it may claim for *more credibility* than space-based SDI.

It is my feeling the Scientific Community should once again mobilize as it
did against SDI, being also conscious that its task will probably be harder
this time (see points 2 and 4).

Diego Latella, Univ. of Twente - Faculty of Computer Science, TeleInformatics
and Open Systems (TIOS) Group, P.O. Box 217, 7500 AE Enschede - The Netherlands
phone: +31 53 893755      email: latella@cs.utwente.nl


Accountant's error catches thief!

<jgrace@tetrasoft.com>
Tue, 10 Nov 92 12:21:14 PST
I am taking an introductory Accounting course (enough groaning! :-) and
actually its quite a bit of fun --- since accounting is basically an exercise
in managing the risks of having and not having accurate information to run a
business.

Of course, the accountants try to be as exact and consistent as possible to
uncover any inconsistencies (e.g., theft, loss, mistakes).  However, only so
much can be done before the costs outweigh the gains, so only so much is
*really* done --- with the hope that that's enough and that everything will be
alright.  (This "constraint" principle is that of "Cost-benefit --- the value
of a financial item reported should be higher for the decision makers than the
cost of reporting it" [Fundamentals of Financial Accounting, 6th E., Short and
Welsch, page 159].)  Of course, this seemingly cut and dry principle is
*really* a matter of judgment --- what may *appear* as diminishing returns may
actually be very valuable information.  To sum up, accountants *try* to walk
the line between valuable information (on one side) and diminishing returns (on
the other side) with as accurate, relevant information as possible.

Unfortunately, accounting systems are easily abused by crooks.  So, accounting
also covers "Internal Controls" (this week's lecture :-), especially of cash
handling (but other stuff too, e.g., inventory, supplies).  The main approach
to avoiding misappropriation of cash is the division of responsibility for cash
collection and accounting (and other responsibilities too).  A commonly
observed example of this separation of duties:

  At most movie theaters, one employee sells tickets and another employee
  collects the tickets.  It would be less expensive to have one employee do

  both jobs, but it would be easier for an employee to steal cash.
  [FoFA, p. 356]

As you can see, these measures are very important and, unfortunately, can be
very expensive to implement.

So this week, our instructor (who is full of great anecdotes from his
banking/loaning experience) related the story of a merchandise business where,
despite separation of duties, the delivery person found a way to defraud the
company.  The scenario follows:

The delivery person delivered goods to customers in return for checks and cash
which he was supposed to hand over to the bookkeeper to record (separation of
duties :-).  Then the bookkeeper gave him the checks and cash to deposit at the
bank --- with a slip from the accountant for the amount of the deposit
(separation of duties).  Instead, the delivery person withheld a check from the
accountant and picked up a deposit slip for the reduced amount.  Then, on the
way to the bank to make the deposit, he "cashed" his pocketed check in via the
deposit cash --- thereby maintaining the validity of the bookkeeper's deposit
slip (but coming away with the cash equivalent of the "cashed" in check from
the company's payments).  The only inconsistency left by the scheme is that
customers who have paid for goods, are recorded by the company as having an
unpaid balance (when they have actually already paid).  I don't know how long
this scheme had gone on, but I imagine small discrepancies are overlooked by
larger companies (cost-benefit constraint again :-).

Ironically, as long as everything goes well, the thief gets away with his
scheme.  Of course, the error here is believing the "Internal Control" system
is not flawed --- but practically speaking, cost-benefit constraint kicks in
and keeps apparently working systems from being scrutinized (or the old,
simplistic maxim "If it ain't broke, don't fix it").

However, eventually, our ever vigilant but imperfect bookkeeper made a mistake
on the deposit slip (where an even number was odd or somesuch).  I don't know
the details (at all) but apparently the thief didn't catch the error (or it
didn't matter whether he did or not) and eventually the bank and company had to
do research to resolve the problem.  Of course, the research led to discovering
how customers thought they had paid but were recorded as not paying, etc., and
the fraud and thief were discovered.

I found the case amusing and apropos to RISKS since Accounting is a formal
attempt at reducing risk through cost-effective, relevant information
(trade-off flag immediately waving :-), "Internal Control" systems which are
subtly subject to abuse, and the ironic *value* of making a mistake once in a
awhile (perhaps even on purpose) to highlight areas taken for granted.  In this
case, "If it ain't broke, break it" [to make sure it *really* isn't busted]
seems a propos!

Of course, technology may help address these issues (while creating fresh ones
of course :-), e.g., electronic verification of paid and unpaid balances
between the company and its customers or even electronic payment (e.g.,
CheckFree), etc..
                                        Joe


Cellular misinformation

"Barry C. Nelson" <bnelson@ccb.bbn.com>
Tue, 10 Nov 92 14:58:48 EST
The Boston Globe, 9 Nov 1992, had a human interest story illustrating some good
uses for the ubiquitous cellular phones.  In many places you can dial *SP for
the State Police, and this had been credited with getting rapid assistance to
accident and crime victims, as well as apprehending a dangerous escapee. They
mentioned problems with routing 911 calls.

What I found more interesting was a discussion about the Coast Guard preparing
to adopt *CG as a maritime cellular distress number.  A local official was
quoted as saying that the existing broadcast channels will remain in operation
because anyone nearby will hear you and the CG operates Direction Finding
stations to pinpoint your location. Okay...

But then he went on to say that cellular calls "only give you a point to point
channel", leading one to the wrong belief that they couldn't DF a cellular
user, and that nobody else could listen if they wanted to.

-BCNelson

P.S.: After a PGN talk at MIT recently, someone in the audience claimed that
      the FBI has multiple "trunks" attached to the local cellular hub in
      Boston and they can monitor both sides of a conversation by just typing
      in your number.  Thank goodness that this is a democracy.  :-^


"End-Running" Key Registration

Alec Isaacson <AI4CPHYW@MIAMIU.ACS.MUOHIO.EDU>
Tue, 10 Nov 92 10:07:36 EST
Recently D.LONGLEY@qut.edu.au wrote about "How Teflon John Coped with Key
Registration" which got me to thinking about _other_ ways to beat key
registration, namely a cipher group method. (i.e. an "innocent" word has some
other word or sentence associated with it).

In that case, our criminal could send to his associate, "How is your dear Uncle
Joe."  The associate, or his computer, looks in the code table and sees that
"your" = liquidate "dear" = soonest and the intended victim is (by
pre-arrangement) the next name mentioned.  The FBI could crawl all over a
message like that with a microscope and not discover a thing.

I can't see why this wouldn't work (unless it becomes illegal to write about
non-existent relatives :).

I welcome comments, since the sum total of my crypto experience comes from
reading the spy novels on occasion.

Alec D. Isaacson, Miami University, Oxford, OH
AI4CPHYW@miamiu.acs.muohio.edu  isaacson@rogue.acs.muohio.edu (NeXt Mail)


... on a way to foil the fbi...

Peter Wayner <pcw@access.digex.com>
Tue, 10 Nov 92 10:08:43 -0500
Actually, the FBI is very technically proficient. James Bamford tells
a story about their cryptographic prowess in _The Puzzle Palace._ Apparently,
the agents determined that the _only_ way communication could be
leaving the criminals is through the shirts they sent out to be laundered.
The FBI kept track of the shipments with great patience and finally
figured out that the number of shirts of each color encrypted the message.

12. The 4 bit cipher feedback allows Teflon John to reduce his phone bill with
more sophisticated approaches where more than 1 nibble is used per message.
With 4 bit cipher feedback there is more control over the ciphertext so that
the messages can be modified easily to produce the requisite nibbles
corresponding to the ciphertext used by MAC the knife.


And by logical extension...

Peter Wayner <pcw@access.digex.com>
Tue, 10 Nov 92 10:00:05 -0500
  > Dorothy Denning suggested that anyone using high-level encryption over a
  > public network be required to register their encryption keys with some
  > agency.

Steve Tepper writes:

  > Take this a step further.  What's to stop the bad guys from creating their
  > own language?  (Say something like Esperanto but based on Navajo instead of
  > Italian.)

And what about puns, double entendres, and anagrams?  Will metaphor, simile,
metonymy, and synecdoche be the next to go?
                                                   Peter Wayner

    [Don't forget the anecdoche and its antidoche, the cynicure.
    Actually, there are all sorts of cryptic messages hidden in
    RISKS, but few people seem to notice them.  PGN]


Re: FBI Registration

Andrew Klossner <andrew@frip.wv.tek.com>
Tue, 10 Nov 92 13:30:49 PST
The clever ruse that Dennis Longley discusses doesn't differ substantially from
simply using a code within the cipher.  If you're going to load encrypted
information into the first few bits of innocent messages, you might as well
just redefine the innocent messages.  For example, "buy soybeans" might be code
for "kill tough tony".

Andrew Klossner  andrew@frip.wv.tek.com  uunet!tektronix!frip.WV.TEK!andrew


Re: Interesting/obscure interaction between users

Rich Kulawiec <rsk@gynko.circ.upenn.edu>
Tue, 10 Nov 92 08:57:16 EST
         (Honig, RISKS-13.88, Leichter, RISKS-14.01)

Jerry Leichter follows up on David Honig's discussion of the SunOS shared
memory resources by noting that it is possible to recover from resource
exhaustion by using various programs to locate shared memory segments which are
(a) were not properly deleted and (b) are not in use.  In particular, he
mentions Ultrix's "ipcstat", which displays a list of known IPC objects. (The
corresponding SunOS program is called "ipcs"; I believe that it's functionally
equivalent.)

The problem is, though, that the situation is worse than either David or Jerry
mention.  It is not only possible to create shared memory segments which
persist when they should not, but it is also possible to do so in a way that is
*invisible* to ipcs--but visible to programs like top and pstat, which can
measure available memory.  We discovered this by accident when attempting to
diagnose a resource exhaustion problem that our principal in-house application
appeared to trigger.

The scenario works like this: the basic operations permitted on shared memory
segments are creation, deletion, attachment, and detachment.  In normal use, a
master program would create a shared memory segment, and various subprograms
might attach to and detach from it as they needed to.  Eventually, the master
program would delete the shared memory segment before exiting.

However, if one process creates a shared memory segment, and a second process
attaches to it and then deletes it *while still attached*, the segment is not
freed, even though it is marked as such and is thus invisible to ipcs.  (It's
not freed when the processes exit, either.)  It's possible to start another
process which can still locate and attach to this ostensibly non-existent
segment, which is surprising.  It can be deleted without a reboot by running a
program which iterates through all possible shared memory segment identifiers
and attempts to delete each one, regardless of whether or not it appears to
exist, but this is a rather drastic solution.  (We've also discovered some
additional scenarios which lead to roughly the same problem; all of this was
under SunOS 4.1.1.)
                                      Rich Kulawiec

Please report problems with the web pages to the maintainer

x
Top