The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 3 Issue 28

Thursday, 31 July 1986

Contents

o Laserprinter dangers
Mansfiel
o Errors in error-handlers
Mansfiel
o Military testing errors
Alan Wexelblat
o Re: Comet-Electra (RISKS-3.25)
Bill Fisher
o Computer and Human Security
Lindsay Marshall
o Info on RISKS (comp.risks)

Laserprinter dangers

<MANSFIEL%DHDEMBL5.BITNET@WISCVM.ARPA>
Mon 31 Jul 86 17:38:10 N
Increasingly, large and "official" organisations such as motor vehicle tax
offices, insurance companies, etc. are using laser printers to print the
bills and other requests for money which are sent to customers. Whereas
previously pre-printed letterheads (often with several and or coloured inks)
were used, now the laser printer is relied on to print the letterhead
itself, so that plain paper can be used.

It is probably only a matter of time before some clever person prints off a
batch that looks fine but that have the c.d.'s own account number (or some
other slightly safer one) on them, sends them out, and gets lots of money.

There must be lots of other forgery and swindling possibilities with laser
printers.  Have any frauds of this type have actually been committed?

   [Most banks no longer make blank deposit slips routinely available, after
    various episodes of people magnetically coding account numbers onto the
    blanks and leaving these slips in the stack of blanks.  Spoofing of
    letterheads is of course relatively easy with laser printers, but also
    with many of the electronic mailers around the net.  PGN]


Errors in error-handlers

<MANSFIEL%DHDEMBL5.BITNET@WISCVM.ARPA>
Mon 31 Jul 86 15:47:17 N
Ken Laws, in RISKS-3.25 said

        > Errors that arise within the error handlers are similarly
        > important, but beyond my ability to even contemplate in
        > the context of current languages.

A related problem, but much simpler and much more common in my experience,
is that the user-written error handling code contains lots of errors.
Reasons for this include

        (a) This code is not considered "important", because we don't
        really expect it ever to be used, and even if it is,
        it will be used so rarely that normal criteria for
        neatness, etc., are not relevant.

        (b) To exercise the code, the errors have to be caused
        or simulated. This is just too much work, especially
        as the program works "satisfactorily" as it is anyway.

The usual result is that when a rare error occurs, the error handler blows
up, or worse, gives a wrong report. Then, having found the problem after
many fevered days, you realise that the one time you need all the help you
can get, including accurate error reports, is when you are under pressure to
repair a crashed system, and you vow that in future ...


Military testing errors

Alan Wexelblat <wex@mcc.com>
Wed, 30 Jul 86 14:49:03 CDT
The following second-hand item appeared in the local Austin rag:

"SANTA ANA, Calif (AP) - A Pentagon error that knocked off two points on
aptitude test taken by military recruits caused thousands of servicemen to
lose training and benefits, according to a newspaper report.

 The scoring error on nearly 2 million aptitude tests since 1984 could have
been crucial for some recruits, because a single point can mean the
difference between college-level training and a less-desirable assignment.

 The _Orange County Register_ said Saturday that the military did not
announce the errors but acknowledged them when queried by the newspaper.  [...]

 Rep. Robert Badham, R-Calif., said the House Armed Services Subcommittee
on Military Personnel is investigating the testing problem and its effects.

 It was unclear what caused the problem.  The newspaper said that the error
was apparently due to either to a miscalculation of the scoring curve
incorporated into the Chicago testing computer or an actual misprint in the
test booklets."

Does anyone have any better information than this?
Alan Wexelblat
ARPA: WEX@MCC.ARPA
UUCP: {ihnp4, seismo, harvard, gatech, pyramid}!ut-sally!im4u!milano!wex

"It is quite impossible for any design to be `the logical outcome of the
requirements' simply because, the requirements being in conflict, their
logical outcome is an impossibility."


Re: Comet-Electra (RISKS-3.25)

<bfisher.ES@Xerox.COM>
30 Jul 86 07:33:41 PDT (Wednesday)
Some years back (>10) there was a book out, "The Tail of the Comet,"
analyzing the design process for the Comet and then the investigations and
procedures which pinpointed the design errors.  I can't remember the author,
but a comment of his is carved in memory, viz., "Extrapolation and
interpolation are the fertile parents of error."

Bill Fisher 


Computer and Human Security

"Lindsay F. Marshall" <lindsay%cheviot.newcastle.ac.uk@Cs.Ucl.AC.UK>
Wed, 30 Jul 86 13:30:00 gmt
I feel that there are significant differences between the quality of the two
sorts of security.  I appreciate the similarities that Bob has described and
agree with his "MIT" rule, but there are many instances where computer
security seems very much more superficial than human security.  Passwords are
the most obvious example - there is no simple way to determine whether or
not the person typing the password is in fact the person expected, whereas
there are other clues available to a trained human (NOT that I am saying
that these are always correct or are always used!).  In simplistic terms, it
is much easier (for the average person) to impersonate someone "anonymously"
by using their password, than it is for someone to actual pretend to be that
person to other people. Of course, someone with enough confidence can get
away with a phenomenal amount of pretence, because most people aren't really
supicious (e.g., men in white coats in hospitals/labs, cleaners, postmen
(cf. Father Brown story, "The Invisible Man")) or because people don't
follow the rules (e.g. people with photos of apes/Einstein stuck to their
identity cards).  An example from my own experience when working in Industry:

    I had received a tape written at 1600bpi on an IBM machine and
needed a copy made at 800bpi for our PDP-11, so I went to the computer
centre of our parent organisation, stopped an operator and asked him to make
the copy and if possible to run the job that was on the tape.  (It was an
ENORMOUS Fortran H compilation...)  The op said OK and I hung around a bit,
looked over peoples shoulders and chatted with some people whom I knew, but
that wasn't obvious).  An hour later the op returned with my tapes and
listing and said "By the way, who are you?".  The day after that they
installed electronic card locks on all the doors to the computing centre and
stationed someone on the door....

    I got away with this a) because I had never thought that there would
be a problem, and so was the reverse of furtive (I may add that I had a lot
of hair at time as well) and b) because the management hadn't actually
considered the security risks (they did MOD work on the machine). On these
lines has anybody more information about the Lockheed document scandal or is
that too hush-hush???
                                        Lindsay

Please report problems with the web pages to the maintainer

Top