The RISKS Digest
Volume 18 Issue 91

Monday, 17th March 1997

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

"Grounding of the Royal Majesty"
John Berg in searoom-l from Steve Schultz via Mike McLaughlin
Risks of losing your identity
CALPIRG item from PGN
Ignoring smart-card risks
David Randolph
Shockwave security hole exposes e-mail
Sidney Markowitz
Risks of online commerce
Paul O'Donnell
Experiences with a Year-2000 credit card
Robert Bowdidge
Re: Y2K: the revenge of originality
Amos Shapir
Risks of random-number servers
Eric Rescorla
Ariane 5 - a wry comment
C. Shen Orr
Re: Telephone Scam
Lou Fernandez
Dan Hicks
Stuart Woodward
Pete Kaiser
Jonathan I. Kamens
Info on RISKS (comp.risks)

"Grounding of the Royal Majesty" (Re: RISKS-17.19, 17.25)

"W.M. (Mike) McLaughlin" <mike@shentel.net>
Sun, 16 Mar 1997 16:30:22 -0500
>Subject:   searoom-l V1 #394
>searoom-l                 Saturday, 15 March 1997      Volume 01 : Number 394
> [...]
>Date: Sat, 15 Mar 1997 00:03:57 -0500 (EST)
>From: John Berg <johnberg@concentric.net>
>Subject: N.T.S.B. issues report on the grounding of the Royal Majesty
>
>     Royal Majesty (Panamanian-registry 32,000-gt, 2,700-dwt, 173-meter/568
>foot, 1,056 passenger capacity ship built in 1992) ran aground at 2230 10
>June, 1995, on the sand Rose and Crown Shoal 16 kilometers/10 miles east of
>Nantucket Island, Mass., because the crew was inattentive and relied too
>heavily on a computerized display, according to a U.S. National
>Transportation Safety Board report issued 12 March. The ship ran aground
>while sailing from St. George's, Bermuda, to Boston with 1,509 people
>aboard. She was 27 kilometers/17 miles outside shipping lanes and with
>6.1-meter/20-foot draft, the bow ran aground in 3.4 meters/11 feet of
>water. Five tugboats refloated the ship at high tide with damage limited to
>stress cracks in the hull and fuel tank. Including lost revenue, the
>incident cost U.S.$7 million. The N.T.S.B. report said the crew members were
>not adequately trained in the use of the automated capabilities of the
>ship's integrated bridge system, including an STN ATLAS Elektronik G.m.b.H.
>Navigation Command System (NACOS 25) with two input ports for a Raytheon
>G.P.S. receiver and a Raytheon Loran C receiver. Crew members' training was
>limited to on-the-job knowledge from each other, with no performance or
>training standards, no inspections and no certifications. An hour out of
>Bermuda, an antenna cable connection on a G.P.S. receiver was severed. The
>system defaulted to dead reckoning when the cable was disrupted, and did
>not account for wind or sea changes. The automated display therefore showed
>the ship on course. The ship failed to acknowledge alarms, visual warnings,
>aids to navigation including channel buoys and lights and differences in
>water color. Norwegian Cruise Line recently announced plans to buy the
>Royal Majesty from Kvaerner A.S.A. for U.S.$190 million.
>[...]
>     World Maritime News is distributed by electronic mail every Friday.
>Due to its distribution beyond the original format both in style and
>medium, it is preferred that it be left intact or that World Maritime News
>and/or Steve Schultz (sschultz@execpc.com) be attached with excerpts,
>especially those excerpts in which structure and tone are not changed from
>that used in the World Maritime News. If in doubt, please ask. Although
>every effort has been made to verify the accuracy of the information
>presented, I do not assume any liability arising from its use.
>[...]
End of searoom-l V1 #394


Risks of losing your identity

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 17 Mar 97 10:02:14 PST
CALPIRG (a public-interest research group) has a new Theft Identity Guide
(``What Can Consumers Do To Avoid Becoming Theft-of-Identity Victims?'')
for any of you who want to know what you can do to protect yourself against
having your identity misappropriated.  I worked my way down the PIRG Website
and found the Guide at
   http://www.pirg.org/calpirg/consumer/privacy/toi/prevent.htm .  If you
cannot get a Web copy, send e-mail to watchdog@pirg.org, or call
1-800-533-4449 within the U.S., or write to CALPIRG at 11965 Venice Blvd
#408, Los Angeles 90066.

If you are a new RISKS reader and don't know about the potential risks, the
RISKS archives contain a startling number of cases involving individuals
whose identity has been usurped, purloined, lost, or otherwise impaired.
Some of the early cases are summarized in my Inside Risks column, CACM, 35,
1, January 1992, and more recently in my RISKS book (Computer-Related Risks,
Addison Wesley, 1995, pages 194-199).  The RISKS archives include (among
others) the following cases — itemized in the Illustrative Risks summary
(ftp://ftp.csl.sri.com/illustrative.PS), with references (S i j) to
volume=i,issue=j of the ACM SIGSOFT Software Engineering Notes.  Most of
those cases were initially discussed on-line; grep away if you want the
original items.

 Repeatedly detained (S 10 3, S 11 1), Terry Rogan wins rights violation
   case (S 12 4); settles for $55,000 (S 13 2)
 Other cases of false arrest due to computer database use: C.R. Griffin
   license not suspended; Sheila Jackson Stossier mistaken for Shirley
   Jackson; two Shirley Jones, diff birthdays, 6", 70 lbs diff (S 10 3)
 More computer-inspired false arrests, libel, etc. (S 12 3)
 Michael W. Klein, mistaken identity due to outrageous mismatch (S 20 2:7)
 Identical database record names cause nasty tax problem in Canada (S 12 4)
 Two Belinda Lee Perrys share the same birthdate (S 21 4:13, R 17 88)
 Nonupdated stolen-car database; one owner shot, one roughed up (S 21 4:14)
 Risks of naming files ``core" (S 21 2:18)
 Risks of non-portable configuration files (R 17 62)
 Mistaken-identity nightmares: Foster, O'Connor, Taylor, Stapelton (S 13 2)
 Richard Sklar falsely apprehended three times because of impostor (S 14 2)
 Roberto Hernandez falsely jailed twice; won $7000 first time! (S 14 5)
 Joseph O. Robertson in for 17 months despite contrary evidence (S 14 5)
 Martin Lee Dement 2 yrs LA County jail; fingerprint sys not used (S 14 6)
 Another bogus identity: Teresa Stover alias' VA DMV license;
   `perhaps thousands' of fraudulent licenses `bought'? (S 16 3)
 Driver arrested in computer muddle: two cars with same plates (S 17 1)
 Police raid wrong house (twice), due to uncorrected database typo (S 17 1)
 Two Russ Hamiltons with same birthdate; wrong one jailed (S 19 3:6)
 Imposter usurps Clinton Rumrill's existence (S 19 3:7)
 New license sent to imposter who plagued Charles Crompton (S 19 3:7)
 Rented car falsely listed as stolen leads to false incarceration (S 16 4)
 ATM photo of wrong person sent as rapist/robber; `downloading error' (S 16 4)
 Motorist gets citation based on photo, responds with photo of money (S 16 4)
 Impersonator transfers numerous traffic citations to victim (S 17 2)
 Two Steven Reids in Montreal sharing same birthday (S 18 1:22);
 See also Don Norman, et al., on-line (RISKS-14.12-17) on Name Problems


Ignoring smart-card risks

David Randolph <daverand@nkn.net>
Mon, 17 Mar 1997 10:40:12 -0600
Recently, the Risks Forum listed an article describing successful attacks on
smart cards.  I reviewed the article and talked to a friend at a chip
reliability lab.  He believed that his lab could use those techniques to
break the card security in a few days from a standing start.  Once the
system was up, they could do it in hours.  Based on that, I believe that the
challenges to smart cards are very real and that the cost of breaking a
smart card is low enough to make it worth while for organized crime to use.

Card Technology magazine (intended for executives in the smart card
arena) in the Jan/Feb 97 issue had an article titled ``Facing the
Smart-Card Security Issue''.  (Here are some selected quotes.)

"The industry needs to put the latest attacks and methodologies into
perspective by taking a good look at the security of their entire systems.
As we have heard before, any chain is only as strong as the weakest link.
This is definitely true for smart card systems.  Most of the attacks of
recent days are classified as class 3 attacks, which means it would take
millions of dollars of equipment, and hundreds of years of computing power,
to actually break into a transaction.  In most cases, there are many easier
ways for some of this information to be obtained.  A through risk analysis
must be performed at every level of the system to determine what is being
protected, the value of that asset, and how much security is required to
protect that asset."

"The smart card is an intrinsically secure device."

"Are smart cards 100% secure? Claiming that any system and/or technology is
100% secure is irresponsible.  Any system can be compromised given the
appropriate amount of resources.  The main consideration for any system is
whether the level of security meets with the level of effort that an entity
would be willing to expend in order to compromise the security."

"Pay TV systems are probably the most publicized cases of security attacks
and compromises of smart cards.  Once a pay TV system is compromised, new
cards are sent out to subscribers to update the system."

"A third paper was recently presented at the USENIX Electronic Commerce
Workshop in Oakland, Calif.  This paper "Tamper Resistance-A Cautionary Note"
goes into more detail on how a smart card can be manipulated to produce a
fault in a particular calculation.  Its authors also have published a paper
entitled "Improved Differential Fault Analysis" which reviews the work of
both Bellcore and Shamir, putting it into a smart-card context."

The major risks are that people may believe that the smart card is still too
expensive to break and thus not put in the checks to detect counterfeit
cards.  The risks are not in breaking one transaction, but in counterfeiting
cards that the system can not detect are counterfeit.  Whoever issued the
original cards could wind up paying large sums to cover transactions from
counterfeit cards.  Visa recently ran a contest where the prize was a smart
card containing $2,500 value.  That much benefit on one card makes the cost
of counterfeiting look very attractive.

David Randolph  Prairie Trail Software, Inc

  [A smart card strategy may be to understand the risks
  of smart-card strategies.  PGN]


Shockwave security hole exposes e-mail

Sidney Markowitz <sidney@research.apple.com>
Mon, 17 Mar 1997 10:41:05 -0800
Shockwave is a Web browser plug-in from Macromedia http://www.macromedia.com
that plays animated multimedia content.  A security hole that allows a Web
server to read e-mail files on a client browser's machine is described by
David de Vitry on http://www.webcomics.com/shockwave/ with an example Web
page that reads Netscape Navigator e-mail files on Windows 95 and NT, how
Shockwave can be used to read any local file on the client machine and send
data to the server, and Macromedia's response and plans for fixes.  This
site also gives yet another variation that allows the server access to any
Website that the client has access to, even Websites on local networks and
behind firewalls.  See also
http://www.wired.com/news/technology/story/2548.html .  Another article at
http://www.macintouch.com shows how the same technique can be used to read
Eudora mail files on a Macintosh.

Relevant to the previous discussions on RISKS about Authenticode, de Vitry
points out that users of Microsoft Internet Explorer who enter a page with a
Shockwave movie on it are presented with an Authenticode digital certificate
signed by Macromedia, not by the author of the possibly malicious movie.

 — sidney markowitz <sidney@research.apple.com>

  [Sidney kept sending me later updates from Friday and Monday, which I
  have incorporated.  The date/time stamp is from his latest message.  PGN]


Risks of online commerce

"Paul O'Donnell" <pod@ms.com>
Mon, 17 Mar 1997 14:04:22 -0500 (EST)
A couple of weeks ago I tried to use www.movielink.com to purchase tickets
for "The Empire Strikes Back" at a theatre in New York.  I've used this
service many times in the past (at other theatres).  For those who haven't
used it, it works over https - you select a movie showing, give it the
number of tickets, credit card number and expiry date.  It gives you a page
saying "You must remain on this page", while it processes the transaction,
and then gives a success or failure message.  When you get to the theatre,
you swipe your card in a card reader, and the tickets pop out.

For this movie, I got a failure message so I tried again.  This too failed,
so I gave up and bought the tickets the old fashioned way.

I just checked my credit-card bill, and I was billed (by the theatre, not
some ticket agency) for both attempts.  How many people keep an accurate
track of the movies they saw a month ago?

  [Especially risky if you see a lot of films.
  You may be suffering from Jedi Red-Eye, and
  spending too much time in E-Wok mode — some
  sort of electronic Chinese-restaurant syndrome?  PGN]


Experiences with a Year-2000 credit card

Robert Bowdidge <bowdidge@watson.ibm.com>
Sat, 15 Mar 1997 12:02:31 -0500
Well, I'm getting to experience the Year 2000 problem first-hand. My bank
sent me a Visa debit card with an expiration date of January, 2000 last
month.

I didn't notice the problem until I first tried to use the card.  The local
grocery store's card reader wouldn't handle it; when it phoned the bank, it
came up with some error code the checker didn't know about, and wasn't about
to try to figure out.  At another store, the card reader also phoned the
bank and came up with a strange error code.  When the clerk phoned in the
problem, he found the error message explicitly meant "your firmware is out
of date, look in your manual for the process for upgrading the card reader's
software."

I've also hit one store that has a combination cash register and card reader
that appears to date from the early '80's.  Their card reader caught the
date problem before phoning in the card, and thus wouldn't allow the bank to
be contacted.  The clerk assumed the problem was a date problem and misread
the "valid from" date as the expiration date in his quest for something that
looked (to his eyes) as a valid date.  The owner of the store didn't seem to
understand my explanation for the problem, either.

In most of the cases where the card's been rejected, the clerk's been
completely confused by the card reader's reaction and isn't sure what to do.
Luckily, by issuing error codes at the bank end on Y2K problems, the bank
can probably figure out which card readers are running old software, then
lean on the store managers to update the software.  This minimizes some of
the risks of untrained salespeople not understanding the problem enough to
tell their manager to update the card reader.

I'm going to try very, very hard to have one card with a 1999 expiration
date at all times for the next few months.

Debugging New York State one card reader at a time,

Robert

(Other RISKS articles about VISA's warnings to member banks:
          RISKS-18.62, "current score is Y2K 1, Visa 0",
          RISKS-18.74  "VISA fines banks with Y2K problems"
 Other first-hand stories
          RISKS-18.65, "Year 2000 and expiration dates",
 Salesmen canvassing for non-Y2K card readers
          RISKS-18.68, "Year 2000 Sharks")

[Another case forwarded to RISKS by tony.lima@toadhall.com (Tony Lima).  PGN]


Re: Y2K: the revenge of originality (Vaneynde, RISKS-18.90)

<amos@nsof.co.il-nospam>
Mon, 17 Mar 1997 14:58:37 GMT
> he told me of a colleague who used nonsense words as identifiers ...

Since COBOL has about 300 reserved words, a lot of programmers have taken to
using nonsense words for variable names, to avoid reuse of a reserved word.
This makes it much more probable that a date field would have a meaningless
name, than in most other languages.

Amos Shapir   nSOF Parallel Software, Ltd., Givat-Hashlosha 48800, Israel
amos@nsof.co.il   +972 3 9388551


Risks of random-number servers (Re: Drake, RISKS-18.90)

Eric Rescorla <ekr@terisa.com>
Mon, 17 Mar 1997 07:24:46 -0800
While I understand, quite easily, the feeling that one (or in this case
one's friend) has tried to do a good deed and it hasn't gone unpunished, I
nevertheless think Mr. Drake is missing the point — which is that
industrial-strength random numbers merit industrial-strength delivery.

The presumptive argument for this service is that the numbers provided by
this system are better (more random) than the user could obtain on his
own. While the source of these numbers may well be superior, the method of
their delivery may well render them worse than the user could obtain on his
own.

Mr. Drake says:
> The Risks question here is, just what level of paranoia is suitable here?
> If you're paranoid enough to think you need quantum-randomness as
> your random number source, you should definitely want extremely
> high security in how they are delivered.

Interestingly, this is the precise converse of the usual error: getting your
crypto right and your randomness wrong. The risk, of course, is the same:
lavishing care on one part of a security system while ignoring the rest.

-Ekr [Eric Rescorla]


Ariane 5 - a wry comment

"C. Shen Orr" <cshenorr@netvision.net>
Sat, 15 Mar 1997 09:44:55 +0200
The Ariane 5 failure surely is the winner of the ongoing contest for "Most
Damage Done Per Line-Of-Code Changed" - $1.8B / 0  [!].

I fully agree with Kevin Quinn's point (RISKS-18.90): no formal methods
would have detected the problem - its roots lie within the realm of human
communications and tying together seemingly-unrelated physical information,
rather than programming.

  [Coming through, awry?  Comment by PGN]


Re: Telephone Scam (Daniels, RISKS-18.90)

Lou Fernandez <lff@sequent.com>
Mon, 17 Mar 1997 10:37:57 -0800
The house I live in (in Portland, Oregon, USA) was formerly owned by a
family with many teenagers and a home-based business so they had at least 5
telephone lines.  I have one phone line.  However, I get a dial tone on 4 of
the 5 lines coming into the house.

I believe this happens when the local telephone service provider does not
physically disconnect the wiring when service is canceled.  When they
subsequently reassign a wire pair from the canceled service to a new
customer, they make a new connection to the wire pair.  Now the wire pair
can be used by both the old and new customer and the new one gets the bill.

It's also possible the wires are accessible to people other than you and the
phone company.  If you live in an apartment building, the phone lines for
all the residents probably are accessible from a single box in the basement.
If that box is not sealed with a phone company seal, anyone with a telephone
and access to the box could have made the calls.

Louis F. Fernandez Sequent Computer Systems Beaverton, OR 97006-6063
lfernandez@sequent.com


Re: Telephone Scam (Daniels, RISKS-18.90)

<hicks@millcomm.com>
Fri, 14 Mar 1997 20:55:35 -0500
Many years ago, when I took up residence in New Jersey to work for what was
then a major electronics company (and what is now a minor subsidiary of GE),
I had some problems with the phone in my apartment.  At first it didn't work
at all, but the phone company was finally able to get it working after about
ten days.  It had bad crosstalk, but I took that to be a problem with the
old lines in the area.

About a month later I got my first bill.  There were toll charges totalling
over a hundred dollars, even though I had only used the phone for about ten
brief calls.  I called the business office and got the usual "the computer
doesn't lie" response.  (Based on the numbers called, the charges appeared
to be associated with a construction business, but the folks in the business
office seemed unimpressed with the argument that I'd have no reason to make
such calls).

Not knowing what else to do, I called the repair service and complained that
the lines must be crossed somewhere .  A few days later the crosstalk
disappeared (and later bills revealed that the improper billings ended on
the same date).

Unfortunately, the repair service didn't communicate any of this to the
billing department, and I continued to be billed for the bogus calls.  Only
after I insisted that the folks in the billing department inspect the
service records did they grudgingly agree to adjust my bill.

Risks: Obviously, the "the computer doesn't lie" syndrome.  Beyond that,
though, three more observations:

1) It is arguable that the repair personnel, when they corrected the
apparent wiring error, should have recognized that it could have generated
bogus billings and communicated this information to the billing department,
especially since the service call was initiated with this suspicion.

2) Some consideration should be given in the design of equipment to the
prevention of this sort of error.  Close as I can tell, the problem was
probably some sort of simple wiring error — either a short between adjacent
wires or a "split pair".  That such a reasonably likely error could go
undetected and, further, produce erroneous billings, indicates a lack of
"robustness" in the design.

3) Consumers are increasingly at the mercy of various forms of automated,
computerized billings, but increasingly there is no "hard copy" or
independently verifiable record of the transactions.  In a sense this is
valid justification for an increasing level of technophobia.

Dan Hicks http://www.millcomm.com/~danhicks


Re: Telephone Scam (Daniels, RISKS-18.90)

Stuart Woodward <stuart@gol.com>
Mon, 17 Mar 1997 06:15:26 GMT
I don't think the following story will help solve the mystery of the calls
to Guyana, but it demonstrates a risk with "intelligent" pieces of telephone
equipment.  I once found several calls on my International telephone bill
that I was doubtful that I had made.  Thankfully, they were all very short.

The following month I called a friend in London, I was living in Tokyo at
the time, but the call was answered by the operator who asked which number I
was calling. Since I always used the single keypress quick dial feature I
had difficulty in answering the question but looked in my address book, told
the operator, and the call was put through. I asked my friend why the calls
were being stopped and she said that they had been suffering from calls
where no-one spoke.

Later, I noticed that there was an extra LED lit up on my answer phone and I
looked in the (Japanese) manual to find out what it meant. It meant that an
option designed to call a pager was enabled and that every time someone left
a message on my telephone answering machine when I was out, the telephone
was subsequently calling a pager number. I entered the sequence to find out
what number it was calling and found that it was calling my friends number
in London.

I then realized that a couple of months previously, when I had first entered
her number as a single keypress number, it hadn't initially worked and that
I had accidentally entered it as the pager call number.  The key sequences
do this were similar to the single keypress entry sequence. Since I hadn't
programmed a sequence to be sent to the pager, my telephone remained silent
when it called my friends number.  I didn't even know that the telephone had
this feature as I only read the parts of the manual I was interested in.

The problem was hidden since it only occurred when I was not there to answer
the call. Also the user interface of the telephone was very limited making
it easy to make mistakes and hard to find them.

Had I been programming a single keypress dial number to a recorded service
in London, I would possibly have run up an enormous bill.


Re: Telephone Scam (Daniels, RISKS-18.90)

Pete Kaiser <kaiser@acm.org>
Mon, 17 Mar 97 14:31:26 +0100
This happened to me.  A neighbor had made a physical tap into my phone line
and used it to make many expensive long-distance calls.  A switch cannot, of
course, distinguish this from your own telephone, since it happens on the
same wire.  In my case it took several months, plus the threat of legal
action, to persuade the telephone company to investigate the problem down to
the level of the wires in my block of dwellings.


Re: Telephone Scam (Daniels, RISKS-18.90)

"Jonathan I. Kamens" <jik@cam.ov.com>
Mon, 17 Mar 1997 14:01:06 -0500
If you are certain that the call was not made by someone in your
house, then the two most likely explanations of their origin are:

1) You have a cordless phone, and someone with a similar model of
   phone made calls on your line from near your house (e.g., from a
   nearby house, or from a car parked nearby).

   Some complicating factors:

   Most cordless phones will not allow calls to be made when the
   handset is in the base.  But you may have left the handset out of
   the base.

   Before being able to do this, the thief would have had to figure
   out what model of cordless phone you had.  But he could have seen
   you talking on your phone in your front yard, or he could live
   nearby and accidentally picked up a conversation on your phone,
   causing him to become aware of the fact that his handset is
   compatible with your phone.

   Most cordless phones nowadays have some sort of security code
   exchanged by the handset and base before the base will allow a call
   to be made.  But you may have a phone without such a system, or the
   attacker may have figured out (intentionally or accidentally as
   described above) the code used by your phone.

   Of course, if you don't have a cordless phone, all of this is
   irrelevant :-).

2) The thief tapped into your line outside the house to make the
   calls.

   This isn't that hard to do.  The telephone handsets used by
   repairmen are not that hard to come by, and all the thief would
   have to do is find the junction box for your telephone wires, open
   it, and clip a handset onto the line.  Even if the junction box is
   inaccessible or locked, the thief could find the wires themselves,
   strip the insulation off of them, and clip directly to the wires.

   If this is a possibility, then you should figure out where the
   wires for your phone line enter your house, and trace them back as
   far as you can (e.g., until they claim to the top of a telephone
   poll you don't want to (or aren't legally allowed to) climb).  Make
   sure there's no place where the wires are stripped, and also make
   sure that any junction boxes and other wiring cabinets which
   provide access to the wires are locked.

   If you find a junction box or wiring cabinet outside your house
   that isn't locked, you are almost certainly justified in calling
   CableTel and demanding that they (a) secure it and (b) don't charge
   you for the calls you did not make.  However, they may have thought
   of this first, in which case they may have already sent out a
   repair crew to find your junction box and lock it.

Jonathan Kamens  |  OpenVision Technologies, Inc.  |   jik@cam.ov.com

Please report problems with the web pages to the maintainer

x
Top