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 5 Issue 59

Monday, 16 November 1987

Contents

o Risks in Voice Mail
PGN
o Stark Reality
LT Scott A. Norton
o Re: How much physical security?
R.M. Richardson
o Navy Seahawk helicopters
LT Scott A. Norton
o Army Black Hawk helicopters
Peter Ladkin
o External risks
John McLeod
o Re: A simple application of Murphy's Law (Tape Labels)
Barry Gold
o EAN and PIN codes
Otto J. Makela
o Computerized Fuel Injection
James M. Bodwin
o Re: Password truncation and human interfaces
Franklin Davis
o Info on RISKS (comp.risks)

Risks in Voice Mail

Peter G. Neumann <Neumann@KL.SRI.COM>
Mon 16 Nov 87 21:45:56-PST
Computerized voice mail is providing rich opportunities for creative misuse,
including the exchange of all sorts of illicit information -- credit card
numbers, passwords, etc.  There is the old tradeoff between easy-to-use
short passwords and hard-to-break long passwords.  Opting for user
friendliness often results in breakability.  There is the problem of tracing
illegal activities back to the misusers, which appears to be more difficult
in voice mail than in the EMAIL counterparts, especially in that voice
mailboxes are currently harder for law enforcement agencies to identify.
Something like $12 can rent you one for a month.  Many familiar problems
also exist, such as authentication, integrity of the messages, presence of
Trojan horses (e.g., monitoring interesting calls, editing calls), etc.
Ain't technology wonderful?

[For Bay Area folks, there was a nice front-page article on the subject by
John Markoff in the Sunday Examiner and Chronicle, 15 November 1987.]


Stark Reality (Re: RISKS-5.58)

"LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@wiscvm.wisc.edu>
Mon, 16 Nov 87 16:43:14 PST
I sent a more detailed response direct to Hugh Miller, but here is the
gist of Capt Brindel's letter to Navy Times.  The failure of Stark to
defend against the Iraqi Exocets was, according the Capt Brindel, due
to the failure of Stark's search radars and EW system to perform as
advertised.  He asserts that his equipment operators, watch officers,
and maintenance techs did their jobs correctly, but the equipment did
not do what the FFG-7 Class Combat Systems Doctrine said it could.

To address Mr. Miller's question about the Phalanx gun, Capt Brindel
said that it was not activated: "The TAO stated that had he received
proper indications from either the radars or SLQ-32 

Re: How much physical security? (Re: RISKS-5.48)

Rich <RMRichardson.PA@Xerox.COM>
16 Nov 87 15:51:46 PST (Monday)
> There is some fractional risk from physical assault.  The cost of 
> significant improvements seems high.  The value of the facility, 
> including data files, is high also.  How does one rationally decide
> whether the risk is acceptable? 

> My tentative answer is not to do anything about physical security.
> The Institute is insured against equipment losses.  

This should be taken care of by trading off between investment in security
facilities and insurance costs.  Is the insurance company astute enough to
check your physical security and adjust the premium accordingly?  (Is
"competent insurance company" an oxymoron?  Oh, sorry. :-)

Also check the change in probability of loss against losses not covered by
insurance (does your insurance cover the cost of lost work while the
equipment is being replaced?).  How long will it take to get replacement
equipment in, up, and running?  Do you "lay off" everyone who needs the
computer to do their job until you're running again?  What is the cost of
lost opportunities during the replacement time?

Do you lose valuable people because your "slovenly security" is a 
sign of incompetence?  Do you lose valuable people because your 
"Draconian security" is unendurable?  

Some thought should expand this list of questions to help you make the
decisionSomewhere in the middle of all these factors is a reasonable area to
operate.  You could even ask your users about this.

> The one thing we don't do is to keep copies of valuable files 
> stored in an independent environment.  This can be done for fairly 
> low cost, although it goes against the grain for researchers to 
> make backups at all.  

Since you have a "mainframe" (rather than workstations), it should be much
easier to backup your file systems (at least the project and user
directories) to mag tape on a weekly basis and take those tapes off site.

> As far as I can see the absolute risk from power surges, flooding, 
> and network breakin is greater.  We have had instances of all of these.

Are any of these covered by insurance?  I'd guess flooding might by and
power surges and breakin are not.  Power surges can be protected against by
equipment and I would think would be worth at least some investment.  At the
very least, you might save some equipment with a latch that must be reset by
hand before re-applying power after an outage.  This allows you to bring the
system back up in an orderly manner.

If you haven't done something about network (or telephone) breakin by
now, your case may well be hopeless.  :-)  
                                                   Rich


Navy SH-60 Seahawk helicopters

"LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@wiscvm.wisc.edu>
Mon, 16 Nov 87 14:05:58 PST
The probable reason the Navy required heavier shielding on their version
of the SH-60 is that when landing on a ship's flight deck, the aircraft
passes right through the main lobe of ship's air search radar(s), about
50 ft from the antenna.  The need for shielding is obvious: you stare
right down the radar's feed horn as it swings around.

LT Scott A. Norton, USN, Naval Postgraduate School, Monterey, CA 93943-5018  


UH-60 problems

Peter Ladkin <ladkin@kestrel.ARPA>
Mon, 16 Nov 87 17:34:46 PDT
One should note that the problems with the UH-60 are of disputed origin.
Aviation Week and Space Technology, Nov 16 1987, p27 , "Army Modifies UH-60s
To Cut Electromagnetic Interference in Controls":  "Washington - Concern
about the vulnerability of the Sikorsky UH-60 Black Hawk helicopter to
electromagnetic interference has led the Army to modify its aircraft, but
the Army and Sikorsky deny that electromagnetic interference has caused any
crashes of the helicopter. [.....]".

One should beware of inferring by association, because of its social
consequences. A case in point is the V-tail Bonanza, a light aircraft that
has been in production for almost forty years. Over the years, a number were
lost in unexplained in-flight breakups, some with very experienced pilots at
the controls. Beech, for good legal reasons, maintained that the airplane
satisfied the requirements of certification, and did not investigate.
Apparently the presumption was that if they were to conduct their own tests,
this could be used as evidence that they were not completely sure of the
airframe quality, in hypothetical litigation proceedings (this is my
personal interpretation, as well as that of others). This is not by any means
unsound reasoning. They willingly conducted extensive tests when required to
do so by the FAA (which seemed in retrospect to be the obvious solution -
one can wonder about the FAA's tardiness). Meanwhile, many v-tail owners
died.  We all suffer from the consequences of this kind of political/legal
conundrum, and so one should note that the facts are disputed in the UH-60
case. None of which means that the press is wrong, of course.
                                                                peter ladkin


External risks (Re: RISKS DIGEST 5.58)

John McLeod <jm7@pyr.gatech.edu>
Mon, 16 Nov 87 16:31:47 EST
Another class of risks to computers is accidents external to the complex.  A
couple of years age at the University of New Mexico, several of the
computers were shut down by a backhoe breaking a large water main on
central.  The water from the main flooded the steam tunnels while the steam
pipes were hot.  The temperature in the computer room reached 100F, and the
humidity reached 100%.  This triggered the shutdown sequence for the
computers.  However, the air conditioners overloaded when attempting to cool
this mess to a suitable temperature.  The computers were down for two weeks
while new air conditioners were purchased and installed.

A few weeks ago here at Georgia Institute of Technology, we had a backhoe
break the power cable and the network cables.  The computer was down for
about 12 hours.

JOHN MCLEOD, Georgia Insitute of Technology, Atlanta Georgia, 30332
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!jm7


Re: A simple application of Murphy's Law (Tape Labels)

Barry Gold <lcc.barry@SEAS.UCLA.EDU>
Sun, 15 Nov 87 10:46:13 PST
In designing the "secure" operating system KVM/370, we considered the
danger of an operator mounting the wrong tape from a different
perspective.  In an environment that mixes applications with different
classification levels, an operator error can result in the data on a
Top Secret tape becoming available to a user who is cleared only to
Secret--or in Top Secret data being written on a tape whose external
label claims it is "unclassified".

We decided to assign a separate "authenticator" to each removable volume
(tape OR disk).  The design was to work as follows:

Every volume, even "foreign" tapes, is assigned a volume id ("name"
and/or location when racked) AND a "password".  This information is
entered in a database, along with the classification level and owner.
The "password" is NOT given out, but is written on the tape's external
label.

When requesting a tape mount, the user specifies the volume id.  The
operator retrieves the tape (or disk) and gives the system the volume
id, the name of the user who is to receive access, and the "password".

The system checks that:

1. the "password" is correct for the volume id.  

2. the classification level of the tape matches the user's current
classification level.  (A user cleared to Top Secret can choose to work
on the Unclassified subset of his data, but will then not get access 
to Top Secret tapes!)

If either of these checks fails, the operator is prompted to try again.
The operator can try again with the same tape (possible typing error)
or a different one, or abort the mount request.

Note that there's no deep dark secret about the volume's "password".  It's
just a check that the right tape has been mounted.  

I think the above scheme would also work to protect against accidental
destruction of data in an unclassified environment.  Just leave out the
classification check.

You might or might not get additional protection by adding a check that
the user who is to get access is the owner.  If not, the USER gets a
prompt "do you want to read (viz write on) xxxx's tape?"  You could even
add a third password that the user gives out to people who should be
able to write on that tape.

Of course, the operator can always get around these checks by "adding" a
new tape and claiming that the tape to be mounted is that tape, or by
calling all tapes a certain standard one with a known volume id and
password.  You need to make sure that operators understand that just ONE
use of that facility that results in overwriting the wrong user's tape
will get them fired.


EAN and PIN codes

<MAKELA_O%FINJYU.bitnet@csl.sri.com>
Mon, 16 Nov 87 10:42 O
In RISKS 5.57 Elizabeth D. Zwicky writes:
>To the best of my knowledge, this feature is not used by actual UPC (that
>is, in the Uniform Price Code standard), but is used in EAN, the European
>standard which uses the same bar codes.  If they use the check digits for
>something else, then only they will be able to figure out what they are;
>anything that reads UPC will reject it, since UPC specifies what the
>odd/evens must be, anything that reads EAN will reject it because the check
>digits are wrong, and programs that read both will read everything but the
>numbers of interest, because they ignore odd vs. even.

This is both correct and not.  The EAN standards actually comprise of two
distinct product coding systems: the EAN-8 and the EAN-13.  The EAN-8 is an
eight-digit no-frills barcode which is encoded only in the "set A" bars.  The
EAN-13 comprises of 13 digits (see, we aren't superstitious over here :-) coded
into a dual barset of 6 digits each.  The 1st digit of the product code is
encoded into the usage of "set A" and "set B" bars in the first barset, and
the last (13th) digit of the barcode is a checksum from the previous 12 digits.
So the EAN-13 barcode looks something like this:
                !!!!!!!!!!!!!!!
                !!!!!!!!!!!!!!!
                !!!!!!!!!!!!!!!
               0!123456!789012!
With the first "0" being the digit encoded into the A/B bars in the first
barset.  The second barset does not contain any coded information in the
usage of bars, it is done simply in "set C".
Why this type of encoding was chosen, beats me!  It is however compatible
with the american UPC coding, since I once tested a bar code reader program
with mixed EAN-codes and UPC-extended codes (you know, the ones you get on
book covers with the price on a little extra barset after the main code).


Also, in RISKS 5.57 Theodore Ts'o writes:
>There is a similar problem with the (Massachusetts) BayBanks teller system:
>it truncates your PIN to FOUR numbers (even though they tell you to pick a
>PIN between four and six numbers).  Yes, it's still there.  When (or if)
>they will ever fix it is unknown.
  Can someone out there in netland tell me how the international PIN system
works (in principle, I'm not expecting the top secret algorithm :-) ?
The cards one gets around here have a 4-digit PIN field in the magnetic stripe
plus one digit of "PIN version".  The PIN system would seem to me to be a
*very* great risk indeed, since as far as I know, the cash registers that can
take a PIN code from a keypad instead of having you sign a sales slip ARE NOT
CONTROLLED ITEMS, ie. I could just go out and buy one.  At least, an organized
and determined group of criminals could steal one.  I would assume that the
part of the cash register that handles PINs works on the "black box" principle,
that is you feed in a card number and what was typed on the keypad and it says
yes or no.  The problem is that a maximum of five digits on the PIN (if we
count the "version" in) would give only 100000 possible codes.  One would not
have to actually reverse-engineer this device (how about calling it a "PIN
Black Box" ?), only use it for testing through the possible keys.
  It's designers would have taken reverse-engineering into account (per the PIN
security requirements), but an attack of this type would be very hard to
counteract in the design criteria, since the actual Black Box has been
obtained, and can be used at leisure for "cracking" card security.
  On the other hand, a determined person with enough technical skill could most
certainly reverse engineer such a device.  A public knowledge of the PIN
algorithms would make stolen/lost credit cards a real disaster, since most of
your money would probably be gone even before you could get to a phone.
Comments, anyone ?

Otto J. Makela, U of Jyvaskyla, Kauppakatu 1 B 18 SF-40100, Jyvaskyla Finland 
voice phone:  +358 41 613 847      BBS phone:      +358 41 211 562


Computerized Fuel Injection (RISKS DIGEST 5.58)

<James_M._Bodwin@um.cc.umich.edu>
Mon, 16 Nov 87 11:10:44 EST
In the mid seventies Volkswagen developed a fuel injection system
for all of their vehicles.  The system has a logic box that that
measures the rate of air flow and then controls valves attached to
the injectors in order to obtain the correct air/fuel mix.
According to the story I heard, the system worked fine in Europe so
they brought a few models over to the US to test out.  For some
unexplained reason the cars would occasionally stall out completely
and fail to restart.  Then, a few seconds later (before thgey could
even get the hood up) the engine would start working again.  This
delayed shipment of the cars to the US market.  After much head
scratching someone finally figured out the problem: CB radio
transmissions from nearby cars were inducing enough current in the
injector control wires to cause the injectors to malfunction.  Of
course, the problem went away as soon as the CB stopped transmitting
or when the car got a reasonable distance away.  The problem was
only noticed in the US because of the relatively large numbers of
CBs in this country (remember the CB craze in the 70s?).  The fix
was to shield the control wires.

Unfortunately, this was long enough ago that I can't remember my
original source for this story nor can I verify its accuracy.

I don't know enough about the power or frequencies used by CBs and
cellular phones to know whether or not they are significantly
different. However, CBs remain popular enough that I'm surprised
that the car companies haven't already taken sufficient steps to
sheild car electronics from radio transmissions.  Or perhaps they
just designed them to filter out junk in the CB frequencies.


Re: Password truncation and human interfaces

Franklin Davis <fad@Think.COM>
Mon, 16 Nov 87 13:01:36 est
   Mark W. Eichin <eichin@ATHENA.MIT.EDU> writes:

   What is especially interesting (in the BayBanks case) is that 
       2) The screens actually flicker visibly once you have pressed
   the fourth digit, making this feature easy to suspect...
In fact, on the newer machines I can't enter my password at my normal
rate -- the system pauses after the fourth digit, and won't accept the
fifth for a moment.  A poor interface indeed!
                                                     --Franklin

Please report problems with the web pages to the maintainer

Top