The RISKS Digest
Volume 12 Issue 25

Thursday, 5th September 1991

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

A kludge too far? FAX-to-OCR-to-speech
Bob Frankston
LA Times Article on E-mail
Mike Kimura
Re: RISKS of using electronic mail
Brian Clapper
David Parnas
More on SSN risks
Glen Osterhout
Universal Email addresses and SSN
Jim Anderson
Re: "Thieves Hit Social Security Numbers"
Bob Frankston
Re: National Character variations in ASCII
Jim Haynes
Pork barrel software validation
Paul Eggert
Multics/UNIX Lessons
Edward Rice
Call for Papers, FICS 92, Singapore
Harold Joseph Highland
Info on RISKS (comp.risks)

A kludge too far? FAX-to-OCR-to-speech

<frankston!Bob_Frankston@world.std.com>
4 Sep 1991 22:55 -0400
In the New York Times, Sept 4th, there was a blurb titled "Fax Machines Are
Getting a Voice".  The article describes a product (from Malibu Software
Group) that OCRs incoming FAXes and then converts them to speech.  So one
dictates a message to someone who enters it into a Word Processor and then
prints it on paper, sends it as a FAX, it gets scanned into a computer, OCRed
and then converts it (or something loosely related to the original) to speech.

Computers are wonderful, they allow one to keep layering technology on top of
technology.  Actually this is nothing new, bureaucracies have been using this
kind of approach for many years.

There are many risks associated with situations in which the original rationale
is lost as layers get added.  Technology increases the opportunities and adds
new elements of mystery and credibility to these kludges.


LA Times Article on E-mail

Mike Kimura <MNK@PYXIS.RSG.hac.com>
Wed, 4 Sep 1991 16:20:00 PDT
On page 1 of the View section of today's (Wednesday, September 4, 1991) LA
Times there is an interesting article written by Amy Kuebelbeck entitled:

         G e t t i n g    t h e    M e s s a g e
     E-mail is fast and efficient. But it isn't always
    private — and that can mean big trouble for users.

The article describes the growing use of E-mail in American business and
describes how it is raising sobering questions about workplace privacy vs.
accountability.  It describes the risks of accidentally sending E-mail to the
wrong person or to a huge list of people.  It quotes several authors and
professors.  Some important advice was

    o Be careful about expressing emotion
    o Assume messages are forever

The article describes the lawsuits pending against Epson America and
Nissan Motor Corp. USA.  There is an interesting section on the
LAPD's use of E-mail where the Christopher Commision, investigating
the Rodney King beating, deemed about 700 messages improper
apparently sexist or racist.  Interesting reading considering it
was written for the people who have probably never used E-mail.

Mike Kimura, Hughes Aircraft Company, mnk@rdac.dnet.hac.com


Re: RISKS of using electronic mail

Brian Clapper <bmc@hutch.rabbit.com>
Wed, 4 Sep 91 17:45:24 EDT
In RISKS-12.22, David Parnas writes about the electronic mail problems one
incurs when changing jobs.  I ran into the problem myself when I left my former
employer; they refused to forward electronic mail for reasons that struck me as
specious as best.

Establishing a location-independent personal communication system could
solve the problem; however, I wonder who would be responsible for
maintaining such a system, assigning addresses, etc.  In any case, I'm not
sure it's necessary.

When I move my residence, I have many of the same problems with physical
mail.  The consequences of not forwarding my mail to my new residence can
be catastrophic.  The primary difference between that arena and the
electronic one — at least in the U.S. — is that most physical mail can
legally be transported only by a central postal authority.  The postal
authority currently allows me to instruct my old post office to forward all
my mail to my new post office for a few months.  Electronic mail "post
offices" are typically the property of the owner of the machine; as
demonstrated by Mr. Parnas's post, the owner really has no incentive to
forward anyone's mail.  Some do so as a courtesy; some flatly refuse.  If
the postal service were to stop forwarding mail (say, because it costs too
much), the difference between these two situations would disappear.

In the physical world, I have two ways to ensure that I don't lose mail
when I move.  Each method has its analog in the electronic arena.

1 - I can have my old post office forward the mail during the transition
    period.  In the electronic world, this is analogous to having my old
    employer forward my mail, which they may or may not do.

2 - Rent a post office box (from the postal service or from a private
    mail service company) before I move, and notify those who send me mail
    to use the post office box address instead.  In the electronic world,
    this is analogous to opening an account on a public access computer
    computer system like CompuServe or The Well and notifying people to use
    that address instead.

In both worlds, #2 has a problem: I may forget to notify someone, and mail
from that person will eventually be returned with an indication that the
address is invalid.  I'm not convinced that this problem is sufficiently
serious to warrant restructuring the system.  For the professional who
needs a dedicated, reliable, permanent electronic mail feed, renting an
electronic post office box can be viewed as a cost of doing business, much
the way dues in professional societies are viewed.  (I wonder what the IRS
would do if I tried to write off a CompuServe account as a business
expense?)

As an aside, the electronic world also provides a third alternative: I can
buy a machine, contract with a supplier for a network feed, and establish
my own "post office".  That's a little hard to do in the real world.

The difficulties associated with changing one's address aren't new; changing
the message medium doesn't change the problem.  The risks that Mr.  Parnas
outlines don't seem to differ from risks we already accept when we deal with
"real" mail.

Brian Clapper, Rabbit Software Corporation, Malvern, PA       bmc@rabbit.com


Re: RISKS of using electronic mail ... (RISKS-12.22)

David Parnas <parnas@qusunt.Eng.McMaster.CA>
Wed, 4 Sep 1991 22:38:05 -0400
    [In response to Brint Cooper]

1) I do keep a mailing list and have notified all who are on it of my move.  It
is an obvious thing to do.  However, I regularly get mail from people who are
not on that list.

2) I personally feel no need for the kind of privacy that involves not having a
personal net address.  I would strongly oppose a requirement that every
individual have such a personal address, but those who chose to have one should
be able to have one.
                                        Dave


More on SSN risks

Glen Osterhout <glen@tegra.com>
5 Sep 91 14:53:54 GMT
This article was taken from the new products section of the July/August issue
of ISPNews.  This company is apparently marketing a software product that
incorporates a database of social security numbers!?

"Veris is a computer program designed for the financial institutions
that need to verify social security numbers as part of their business.  The
product will determine if a number is valid for the person using it.  Along
with a valid number, the product lists the state or territory where it was
issued and the year(s) in which that set of number series were issued.  In the
event of an invalid number, warning and advisory messages are given.  The
product runs on Macintosh and IBM PC compatibles or networks."

Glen Osterhout, Tegra-Varityper, Inc., Billerica, Massachusetts glen@tegra.com


Universal Email addresses and SSN

Jim Anderson <jim@saylor.saylor.mn.org>
Wed, 4 Sep 91 18:49:41 CDT
Somehow, I find a contradiction in the last couple Risks Digests.  On one hand,
we are told to protect our SSN, and that it is a BAD thing to use as a
universal ID number.  On the other hand, we have a message saying that we need
a universal EMail addressing scheme.  Why not combine the two and make your SSN
the email address?  Or if that isn't acceptable, how many 'universal' ids
should we have?

Jim Anderson, Saylors Software First, 6532 Edenvale Blvd, Eden Prairie,
MN 55346 612-636-7451       jim@saylor.mn.org or jim@aob.mn.org

    [Of course there is a contradiction.  You cannot optimize for privacy and
    universal accessibility at the same time.  If a unique ID is used to link
    databases universally, that is risky.  If a unique ID were used only for
    identification, then that has some merit.  It is the controls on potential
    use that present the problems, not the unique identifier itself.  PGN]


Re: "Thieves Hit Social Security Numbers" (RISKS-12.23)

<frankston!Bob_Frankston@world.std.com>
5 Sep 1991 09:40 -0400
Simple reason for less abuse of SSN's in Sweden?  Less diversity and
poverty?  Be careful about generalizing across societies.


Re: National Character variations in ASCII (RISKS-12.24)

Jim Haynes <haynes@cats.UCSC.EDU>
5 Sep 91 06:01:15 GMT
Perhaps it's worth discussing a bit of history here.  One of the precursors of
ASCII was a military character code called Fieldata.  If I remember correctly
this was an upper-case-only, and used 6 bits to represent all the printing
characters.  A seventh bit was part of the code (and there was a parity bit, so
8 bits were transmitted).  At any rate a lot of the code combinations were
deliberately left unassigned, so that designers of systems using Fieldata had
plenty of codes available for control purposes, or for extra printable
characters if they so desired.

The committee that designed ASCII decided this was not such a good idea,
as different systems used different characters for the same purpose, or
the same character for different purposes.  They therefore took pains to
insure that in ASCII every code combination was used for something, leaving
no room for expansion.  (That's not precisely true; ASCII was standardized
in two phases, first upper-case-only and later upper-lower; and the
character that prints as dollar sign in the U.S. was designated "currency
symbol" so it could print a sterling sign in the U.K., or other signs
in other countries; and there were a few others designated for national
characters.)

When a character set is designed by a committee and ratified by majority vote,
as was ASCII, there is naturally a certain amount of pushing and shoving to get
various companies' favorite features in there.  ASCII includes shift-out and
shift-in characters, analogout to the figures and letters characters of Baudot,
which could be used to shift to an alternate printable character set.  It also
includes escape, to mean that the following character(s) is not to be
interpreted as ASCII.  (There were some truly frightful proposals for getting
back to ASCII after an escape, such as using a character with deliberate
incorrect parity.)  There are Cancel and Substitute; I've never heard anybody
able to explain unequivocally exactly what they are supposed to mean.

Not that it matters much.  Once the computer people got hold of ASCII they made
up their own interpretations.  Delete, the all 1s character, was intended for
erasing mistakes in paper tape.  A character deleted this way should be simply
ignored altogether; but the computer people gave it the entirely different
interpretation of "discard the previous character."  Backspace was meant to
work exactly like backspace on a typewriter.  With a hard copy terminal you
could type o backspace / to get an o with a slant through it.  But certain
computer people decided to use backspace in the same way that others use
delete; and few video terminals are able to do backspace and overstrike the way
a hard copy terminal can.  Control-C was meant to indicate the end of text in a
message; but computer people widely use it to mean "interrupt the currently
running program, or the program currently attached to the terminal."  And so
on, so in the end we have exactly what was had with Fieldata.

                                   haynes@cats.ucsc.edu  haynes@ucsccats.bitnet


pork barrel software validation

Paul Eggert <eggert@twinsun.com>
Wed, 31 Jul 91 21:13:00 PDT
Research in computer software validation is not immune to the increasing trend
by the US government to fund projects for merits that are political, not
technical.  Eliot Marshall reports (_Science_, 19 July 1991, p. 257) that a
bill passed by the Senate Appropriations Committee on 11 July includes $10
million for a new software validation center at West Virginia University.  It
is not a coincidence that the committee is chaired by Robert Byrd (D-WV).
Regardless of WVU's merits, the public would be at less risk if the government
funded software R&D's best technical opportunities instead of succumbing to
political opportunists.

Paul Eggert <eggert@twinsun.com>

    [Yes, this item is over a month old — I was finally trying to catch up
    with some of the backlog from my three-week absence.  But it is still
    timely.  NPR had a rather acerbic piece on 4Sep91 on some of Senator
    Byrd's successes in getting some substantial chunks of the USGovernment
    moved to West Virginia.  PGN]


Multics/UNIX Lessons

Edward Rice <Edward.Rice@p0.f716.n109.z1.fidonet.org>
04 Sep 91 19:56:27
An article by Paul Stachour in the v12, n23 issue of RISKS DIGEST, contained
several statements that I feel deserve comment.  His recollection of the
recognized need to filter out control sequences in inter-user messages is
essentially correct, although the actual date may be a year or two later.  The
problem in question arose when Delta Data 4000 terminals capable of "smart
answerback" were in use at the University of Southwestern Louisiana, and users
were coding their login passwords into those answerbacks.  Another issue, which
was dealt with even later, was the concern that in a shared-terminal
environment, a user could leave the terminal not with a logout, but by
executing a malicious program that would issue what appeared to be a standard
system logout, appear to respond correctly to a new user, and would record the
new user's name and password on behalf of the hacker.  (It could then claim the
password type-in was in error, issue a logout-with-no-messages, and let the
real operating system respond correctly to the user's next attempt to log in.)

Paul's comments reflect the hindsight of the intervening years in two ways.
First, his comments indicate that "Unix is supposedly an 'improved' derivative
of Multics [sic]" is not correct.  A tripartite design group consisting of
General Electric, M.I.T., and Bell Labs designed the original Multics system;
when it came time to start building Bell removed itself from participation in
MULTICS, and developed UNIX as what it perceived a more cost-effective and
achievable system.  By then, Honeywell had acquired GE's large-scale computer
division (and in a later acquisition of the rights to MULTICS, was required by
M.I.T. to rename their operating system "Multics," for all you trivia fans) and
continued with Multics for the next fifteen or so years.  UNIX was indeed a
derivative of MULTICS, but intended as a cut-down, quicker, less-elegant
project better suited to Bell's needs.  In later years, of course, UNIX was
improved.

Second, "The mechanism by which Multics sends its mail and messages ...  was
well-designed to ..." gives somewhat too much credit to the design.  The
original Multics mail scheme not only permitted inter-user messages and mail to
contain control characters, but used a shared-stored method of holding the
messages while they awaited delivery that let message forgeries be as simple as
using a text editor.  Literally: in the original scheme, you could use a text
editor to take a message that was "in transit" and freely change the contents,
including sender ID and all other header fields.  Security was enhanced, later,
to provide for mailboxes that required outer-level operating system
intervention to place or retrieve messages.  In that development, undertaken in
part to satisfy Air Force requirements for a secure, multi-security-level
computer utility, the resolution to the smart terminal/control codes problem
became feasible and was implemented.  (The problem of forgery of the operating
system's login sequence turned out to be a great deal more difficult, as it was
a much simpler hack.)

Finally, the comment that "Multics source has always, to my knowledge, been
publically available" requires comment.  Paul's belief is not precisely
correct, but it is true that Multics source has been available to users of the
system and to the research community without major limitation.  Within the
Multics community, anything less than a complete willingness to hand critical
code over to any hacker who asked for it was demeaningly referred to as
"security through obscurity," and was avoided at all cost (generally, however,
at NO cost, and often with distinct benefit).

                                    Edward_Rice@p4124.f716.n109.z1.fidonet.org

[By the way, you can probably still get a Multics from Bull, if you hurry. PGN]


Call for Papers

"Dr. Harold Joseph Highland, FICS" <Highland@DOCKMASTER.NCSC.MIL>
Wed, 31 Jul 91 11:39 EDT
                   C A L L        F O R      P A P E R S
        THE IFIP/SEC'92 INTERNATIONAL CONFERENCE on COMPUTER SECURITY
                       May 27-29, 1992    Singapore

The purpose of the 1992 International Federation for Information Processing
Security Conference [IFIP/Sec'92] is to provide a forum for the interchange
of ideas, research results, and development activities and applications
among academicians and practitioners in information, computer and systems
sciences.  IFIP/Sec'92 will consist of advance seminars, tutorials, open
forums, distinguished keynote speakers, and the presentation of high-quality
accepted papers.  A high degree of interaction and discussion among Conference
participants is expected, as a workshop-like setting is promoted.

IFIP/Sec'92 is co-sponsored by The International Federation for Information
Processing, Technical Committee 11 on Security and Protection in Information
Processing Systems [IFIP/TC11] and The EDP Auditor's Association.  IFIP/Sec'92
is organized by the Singapore Computer Society and IFIP/TC11 and is sponsored
by the National Computer Board, Singapore, Singapore Federation of Computer
Industry, Microcomputer Trade Association of Singapore and the EDP Auditors
Association of Singapore

Because IFIP/Sec'92 is a non-profit activity funded primarily by registration
fees, all participants and speakers are expected to have their organizations
bear the costs of their expenses and registration.  Presenters of papers will
pay a reduced conference fee.


WHO SHOULD ATTEND

The conference is intended for computer security researchers, managers,
advisors, EDP auditors from government and industry, as well as other
information technology professionals interested in computer security.


CONFERENCE THEME

The Eighth in a series of conferences devoted to advances in data, computer
and communication security management, planning and control, this Conference
will encompass developments in both theory and practice.  Papers are invited
in the areas shown and may be theoretical, conceptual, tutorial or descriptive
in nature. Submitted papers will be refereed, and those presented at the
Conference will be included in the proceedings.  Submissions must not have
been previously published and must be the original work of the author(s).

The theme for IFIP/Sec'92 is "Computer Security and Control: From Small
Systems to Large."  Possible topics of submissions include, but are not
restricted to:

o    Auditing the Small Systems Environment
o    Auditing Workstations
o    PC and Microcomputer Security
o    Security and Control of LANs and WANs
o    OSI Security and Management
o    GOSIP - Government OSI Protocol
o    Electronic Data Interchange Security
o    Management and Control of Cryptographic Systems
o    Security in High Performance Transaction Systems
o    Data Security in Developing Countries
o    Software Property Rights
o    Trans-border Data Flows
o    ITSEC (IT Security Evaluation Criteria - The Whitebook)
o    Database Security
o    Risk Assessment and Management
o    Legal Responses to Computer Crime/Privacy
o    Smart Cards for Information Systems Security
o    Biometric Systems for Access Control


THE REFEREEING PROCESS

All papers and panel proposals received by the submission deadline will be
considered for presentation at the Conference.    To ensure acceptance of
high-quality papers, each paper submitted will be blind refereed.

All papers presented at IFIP/Sec'92 will be included in the Conference
proceedings, copies of which will be provided to Conference attendees.
All papers presented, will also be included in proceedings to be
published by Elsevier Science Publishers B.V. [North-Holland].


INSTRUCTIONS TO AUTHORS

[1]  Three (3) copies of the full paper, consisting of 22-26
     double-spaced (approximately 5000 words), typewritten pages,
     including diagrams, must be received no later than 1 December 1991.
     Diskettes and electronically transmitted papers will not be
     accepted.      Papers must be sent to the Program chairman.

[2]  Each paper must have a title page which includes the title of the
     paper, full name of all authors, and their complete addresses
     including affiliation(s), telephone number(s) and e-mail
     address(es).  To facilitate the blind review process, these
     particulars should appear only on a separate title page.

[3]  The language of the Conference is English.

[4]  The first page of the manuscript should include the title and a
     300 word abstract of the paper.


IMPORTANT DATES

o    Full papers to be received by the Program Committee by 1 December 1991.

o    Notification of accepted papers will be mailed to the author on or
     before 1 March 1992.

o    Accepted manuscripts, in camera-ready form, are due no later than 15
     April 1992.

o    Conference: 27-29 May 1992.


WHOM TO CONTACT

Questions or matters relating to the Conference Program should be directed
to the Program chair:

Mr. Guy G. Gable
Department of Information Systems and Computer Science
National University of Singapore
Singapore 0511
Telephone: (65) 772-2864   Fax: (65) 777-1296  E-mail: ISCGUYGG@NUSVM

For information on any aspect of the Conference other than Program,
panel, or paper submissions, contact the Conference Chair:

Mr. Wee Tew Lim
Organising Chairman
c/o Singapore Computer Society
71 Science Park Drive
The NCB Building
Singapore 0511
Telephone: (65) 778-3901    Fax: (65) 778-8221

Papers should be sent to:

The Secretariat
IFIP/Sec '92
c/o Singapore Computer Society
71 Science Park Drive
The NCB Building
Singapore 0511

In the States and Canada, inquiries about the Conference can be sent to:

Dr. Harold Joseph Highland, FICS
Chairman, IFIP/WG11.8 - Information Security Education and Training
562 Croydon Road  Elmont, New York 11003-2814  USA
Telephone: 516 488 6868                 Telex: 650 406 5012 [MCIUW]
Electronic mail:     Highland@dockmaster.ncsc.mil
 X.400: C=US/A=MCI/S=Highland/D=ID=4065012         MCI Mail: 406 5012

Please report problems with the web pages to the maintainer

x
Top