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 19 Issue 07

Monday 14 April 1997

Contents

o Swedish Narcotics Police Demand Telephone Card Database
Martin Minow
o AOL Mail Latency
Dave Kennedy
o Parkers pass out uncompliments
Michael O'Donnell
o Old RISK: ``Computers are never wrong.''
Joe Carlet
o Risks of user migration
Al Donaldson
o UK and Y2K: $50 billion
PGN
o UK MoD and Y2K: 100 million pounds to reboot missiles
Geraint Price
o GMT and Win95
Michael Bacon
o Computer kiosks
Bob Frankston
o "Crack-A-Mac" contest results
Martin Minow
o Magic-number reuse
Paul Brebner
o Air collision RISK from increased accuracy
John Brooks
o Re: RISKS of Mail Merge for Ontario Tories
Mark Brader
o Re: Blue Cross automated SSN update
Harlan Rosenthal
o Fun with export/import controls
Steve Gibbons
o On the naming of names
Danny House
o Telecommunications & Democracy: Historic Citizens' Report
Richard Sclove
o Info on RISKS (comp.risks)

Swedish Narcotics Police Demand Telephone Card Database

Martin Minow <minow@apple.com>
Fri, 11 Apr 1997 15:36:55 -0700
According to an article in the Swedish newspaper, Svenska Dagbladet
<http://www.svd.se/svd/ettan/ettan_97-04-11/narkotikapolisen.html>, the
Stockholm narcotics police have asked the national police and State
Prosecutor to require that purchasers of a new telephone card used for
mobile telephones be registered, and that the police have access to the
purchaser database. "Since the card is purchased anonymously, the owner
cannot be determined, which makes wiretapping impossible." The new card is
pre-paid with 250 or 550 kroner (very roughly $32 or $70) air time and a
telephone number, but does not require any other subscription. The card can
be used on an ordinary GSM mobile telephone "which can be borrowed or
stolen" and can be re-loaded when the air time runs out.

A similar card is in use in France.  However, the French security service
made the government force the telephone company to require that purchasers
show an id card when they purchase the card.

Quickly translated and summarized by Martin Minow <minow@apple.com>


AOL Mail Latency

<76702.3557@compuserve.com>
Sat, 12 Apr 1997 02:28:45 -0400
>From C|Net: http://www.news.com:80/Categories/Index/0,3,1,00.html?ntb.net

E-mail being sent through America Online has been delayed since Monday due to
an unusual spike in mail, according to AOL spokeswoman Tricia Primrose.  AOL
added new mail servers, now handling about 1 million messages an hour, but
the residual effects of the original jam are lingering.  Primrose could not
say exactly when the system would run smoothly, adding that the volume of
e-mail sent to and from the online service has doubled from 5 to 10 million
messages since December, when AOL began offering flat-rate pricing.

Dave Kennedy [CISSP] Research Team Chief, National Computer Security Assoc.


Parkers pass out uncompliments

"Michael O'Donnell" <mod@std.com.goAnnoySomebodyElse>
Sat, 12 Apr 1997 18:59:28 -0400
I pay for parking in the local parking garage on a monthly basis and have a
pass-card which ID's me to the garage's entry/exit control system.  One day,
after parking in the garage as usual in the morning and working through the
day in my nearby office, I walked back into the garage, started my car and
attempted to exit the garage.  Instead of the gate rising and allowing me to
pass, a klaxon sounded and I was obliged to summon a garage attendant who
eventually accused me of attempting a "pass-out" fraud - he got rather
excited and I think he anticipated being rewarded for his vigilance.  A
pass-out, in their jargon, is where one customer hands his pass out to
another who then uses it again in an effort to park two cars on one pass.

I had the attendant call his boss and then had to have her call in the next
level of management before I found someone who would even consider the
possibility that I'd not risk criminal charges over a petty fraud like this.
Boss-lady eventually began to wonder out loud if the fact that the computer
had "gone on the fritz" an hour previously might be somehow related to this
mess, but she was in no hurry to come to any rash conclusions.  I was
partially into an impromptu tutorial about the consequences of "glitches" on
saved state when, mercifully, other customers started to suffer similar
problems in the adjoining exit gates.  They all gathered around and listened
as I struggled to convince boss-lady that we had NOT all conspired to commit
pass-out fraud simultaneously.  She did let us all leave eventually, but
never seemed truly convinced that we had not gotten away with some cunning
trickery.  RISKS?  Nothing new - do I really need to say it?  Believing the
computer is always right; insufficient training of personnel who co-operate
with automata.

Michael O'Donnell     mod@std.com.goAnnoySomebodyElse


Old RISK: ``Computers are never wrong.''

Joe Carlet <jcarlet@travelin.com>
Fri, 11 Apr 1997 09:51:29 -0500
Well, this old risk of "computers are never wrong" caused my high school
teenager a buck (dollar) at the school library. He received a notice of fine
for an overdue book.  When he argued (his side of the story) they said "its
in the computer".  And besides that, there was no way to change the fine
because, again, "its in the computer and we can't change it".

He told me that they had tried to charge him for a book that never was
returned because the computer said it had been checked out to him.  When he
pointed out to them that the book had been, supposedly, checked out BEFORE
we even moved here, it (the record of fine) was removed from the computer
(see above).

It saddens me that the technologically ignorant are teaching my children
that "computers are never wrong".  That's the REAL RISK of education
... assuming that "computers are never wrong".

-Joe


Risks of user migration

Al Donaldson <al@escom.com>
Sat, 12 Apr 97 12:45:09 EDT
For several months I have been receiving bad DNS name service requests from
a ISP site in Washington state.  These were directed to nonexistent or
internal hosts in our domain, and were intercepted and logged by our packet
filter.

It appears that some time ago (perhaps even before we went on the net), the
ISP sent out incorrect information, perhaps on a setup disk, to their
subscribers listing our addresses as secondary name servers.  If for some
reason their primary name server did not respond, the client would try to
contact my (nonexistent) name servers.  There was never a security problem,
but the proliferation of log messages was annoying.

After repeated complaints, the ISP finally "solved" the problem by
installing an IP filter on their router to prevent the misdirected packets
from going out on the net.

This worked well, until recently I began to see messages from another
network directed to our non-existent "name servers".  I contacted this
Internet provider, coincidentally also located in Washington state, and
found that, yes, some of his customers had recently transferred over from
the other ISP!  And no doubt brought their configuration with them..

The real problem, of course, was that the first ISP chose to confine the
problem rather than fixing it.  This assumed that the "infected" users
stayed put behind their router, which was not a valid assumption.

Now I'm considering putting up a "special" name server on those addresses...

Al


UK and Y2K: $50 billion

"Peter G. Neumann" <Neumann@CSL.sri.com>
Mon, 14 Apr 1997 8:07:26 +0900
The Associated Press today reports that Robin Guenier, head of the UK's
TaskForce 2000, estimates that Y2K reprogramming efforts will cost Britain
$50 billion dollars, three times the guesstimates of business consultants
and computer service companies.  Guenier suggested that 300,000 people may
be required to tackle the problem.  (Coincidentally, that number is roughly
equivalent to the number of full-time computer professionals in the UK.)
  [Various versions of this noted by several folks.]


UK MoD and Y2K: 100 million pounds to reboot missiles

Geraint Price <Geraint.Price@cl.cam.ac.uk>
Mon, 14 Apr 1997 14:09:26 +0100
An article in today's *Times* (14 Apr 1997) by their Defence Correspondent
Michael Evans, titled "L100m scheme to reboot missiles" goes into the
difficulties that the British Ministry of Defence are going to face in
overcoming the problems of the year 2000.

The article refers to "Thousands of miniaturised computers inside missiles
and other modern weapon systems" that will need be replaced or reprogrammed.

The rest of the article is of little surprise to RISKS readers, but the
estimated figure of 100 million (U.K.P) is interesting in light of recent
guesswork on costs within various sectors.

Geraint Price  -  Geraint.Price@cl.cam.ac.uk
Computer Laboratory, New Museums Site, Pembroke Street, Cambridge, CB2 3QG.


GMT and Win95

"Michael Bacon" <Streaky_Bacon@msn.com>
Sat, 12 Apr 97 18:19:27 UT
There appears to be some confusion over the approach Win95 takes to
Greenwich Mean Time (GMT).

The Greenwich Meridian provides the baseline for calculating times
world-wide.  In the UK and Ireland throughout the summer months a scheme,
known in the UK as British Summer Time, applies.  This type of scheme may be
known elsewhere as Daylight Savings Time - although how one saves daylight
in a fully reuseable form I'd like explaining!

The Date/Time/Time Zone function in Win95 allows for setting the 'local time'
to any world time zone.  Win95 regards GMT as a time zone not an absolute
time, and, accordingly, selecting 'Adjust for daylight saving changes' gives
GMT+1 when the clocks are put forward in the UK and Ireland.

Michael Bacon

  [Mark Brader <msb@sq.com> notes that the basic risk in dealing with GMT
  is that of one person assuming that "GMT" means UTC, while another person
  interprets it as "the current civil time in the UK".  This is the fault
  of the UK for not having distinct abbreviations such as our EST (always
  -5) and ET (-5 or -4) [and even EDT], but what can we do about that?
     And don't forget that the differences between UK local time and North
     American east-coast local time change FOUR times a year because the
     changes happen on different weekends.  PGN]


Computer kiosks

<Bob_Frankston@frankston.com>
Mon, 14 Apr 1997 13:24 -0400
I tried out one of the new Web Kiosks that is being installed by a
USWest-related entity. Great idea though weak in execution.  But the issue
I'm not as concerned about the strange keyboard or the malfunctioning credit
card scanner.  At least, not for RISKS. Nor the unnecessarily bad
performance.  So goes naive implementations.

THe problem is that the browser defaults to remembering passwords for
visited pages.  Unless you remember to uncheck "save password" for each and
every visit, you're leaving a trailing.  I would have complained except that
I couldn't find an e-mail address other than a USWest one.  And the people
at that address said they have nothing to do with the Kiosk.

I do naively assume that they are nice trustworthy people and don't do their
own "tapping".  But then, that's the risk of any public appliance including
the telephone -- I just assume that store owners do not tape conversations
over their public phones.

Alas, a nice idea, public Web Kiosks, that will probably fail due to poor
execution rather than a poor idea.  But this is not the forum for Risks of
Marketing.


"Crack-A-Mac" contest results

Martin Minow <minow@apple.com>
Fri, 11 Apr 1997 08:56:46 -0700
In February 1997, a Swedish web design company started a contest offering
$1500 to anyone who could break into their web server. The contest ran for
about two months, they increased the reward to about $15,000 (100,000
Swedish Kroner), and nobody succeeded. Here are a few notes from their
report (still in Swedish, an English translation is due "real soon now,"
look on <http://hacke.infinit.se/> for details):

* Their web server is an "out of the box" machine with no firewall or other
  "magic" running a commercial web server. Installation time, including
  unpacking the computer, was around 30 minutes.

* The earliest attacks exploited known Unix security holes, with
  Windows NT showing its popularity.

* An amazing number of people tried to break the administration password for
  their WebStar server which, if successful, would allow remote
  management. There were over 220,000 attempts to guess the password, all
  unsuccessful. (Even if someone was successful, this wouldn't allow
  changing a web page.)

* Next, people tried breaking their DNS server, presumably so they could
  "move" hacke.se to a machine with a different IP number with a fake web
  page. However, their DNS server also runs on a Mac, so these attempts
  failed. Sendmail attacks didn't work (no Unix, remember).

* Their router was the only non-Mac software in the chain, but it, too,
  withstood attacks.

* The best attack was pure social-engineering: e-mail with a falsified
  return address asking for a change in the web page because I don't have
  time to do it myself." That, too, failed; it helped that the message was
  written in English, not Swedish.

* Some statistics: over 650,000 hits from over 100,000 unique IP addresses,
  sending over 8,000 MB data. About 75% of the visitors were from the USA,
  20% from Sweden, and the rest from other parts of the world. "We wish to
  thank the visitors that came from El Salvador and Mauritius."

This is not to say that the Mac was completely problem-free: it's
susceptible to SYN flood and "ping of death" attacks, and crashed three
times during the test period, but restarted automatically within a minute,
thanks to two small shareware programs.

Martin Minow minow@apple.com


Magic-number reuse

Paul Brebner <brebs@cbr.soils.csiro.au>
Mon, 14 Apr 1997 15:38:40 +1000
In Australia we have a Government-run "Medicare", which subsidizes Medical
care, child care, etc.  Today my wife asked me to take a pile of claim forms
down to the Medicare office to get a refund.  The forms had to have her
signature on them, so she used some that were lying around the house, which
were obtained a few months ago.

After standing in a queue for too long, the operator processed the forms.
She seemed to be have some trouble with one of them, so I managed to peer
around the corner of the monitor to see what was happening.  One of the
codes that she had entered from the form (e.g. 95) was highlighted in red,
along with an ominous message saying "Invalid code".  According to the form,
it was the correct code for "Full-time tertiary student".  After further
delay, and trying a few other random codes selected from the form, someone
else came along and was able to solve the problem - The form was an old one,
and the codes had changed.  They worked out what the new code was (e.g. 42)
and entered it without further trouble. By this time I had a neck like a
giraffe, but was able to see that the new code for "Full-time tertiary
student" was actually the same as one of the old codes for something
entirely different.  The amount of refund is based on these codes.

The risks?  First, that with the change in forms and codes, some (but not
all) of the old codes were reused, but with different meaning (I wonder what
happens if they have to rerun or check some previous transactions?).  If I
had come along with an old form filled out with the number 42 it would have
been accepted, but would have meant something entirely different.

Second, there was no way to tell that the form was out of date, other than
the system rejecting some of the "old" code numbers.

Third, in hindsight I'm not actually convinced that the form was out of date
- the system may have rejected the code for some other reason.  It's
possible that some of the categories and therefore their corresponding codes
are no longer eligible for refunds (i.e.  a policy change), and the "new"
code still stands for the category on my "old" form.  Thus, the amount of
refund I received may not be correct (which in fact was less than I
expected).

This is a further cause of concern as the data on the Medicare computers is
used by other Government departments to check eligibility for other
benefits. Maybe I'm paranoid, but I won't be surprised if my wife gets a
letter in the mail a year from now saying "We have reason to believe you
ceased full-time tertiary study in April 1997 and demand immediate repayment
of $10,000 in falsely claimed benefits..."

Paul Brebner, CSIRO Software Engineering Initiative, Division of Soils,
Black Mountain, Canberra, ACT 2601, AUSTRALIA  +61-6-246-5923


Air collision RISK from increased accuracy

John Brooks <jbrooks@peeras.demon.co.uk>
Tue, 8 Apr 1997 18:48:51 +0100
I was recently on a European passenger flight and over the Baltic observed
another aircraft zing past on a reciprocal course.  The high closing speed
gave the impression that the other aircraft was much closer than reality -
actually it was a Jumbo about 1.5 miles away rather than a much closer 737,
as I had thought.  But discussion with flight deck crew later revealed other
'facts' which may lead to increased head-on collisions in future:

* Advanced flight systems control heading, height and speed very accurately,
  so that now more aircraft fly more-or-less exactly in the centreline of
  the airway.

* Many airways are bi-directional, on identical tracks separated only by
  height.

* A pilot commented that he now frequently sees other aircraft pass directly
  under or over his own.

Conclusion: GPS and advanced nav aids have improved the accuracy of flight,
possibly to the point where collision RISK is increased.  Formerly, small
navigation errors within an airway prevented ever exactly following the
centreline. No more. Now, collision is only prevented by controlled
variation in ONE dimension - height.  A SINGLE failure in height control or
measurement will now make a collision inevitable.

Of course in this example, collisions were only prevented THEORETICALLY by
control of vertical separation anyway, since all aircraft were assumed to
follow the centreline of each airway. But PRACTICALLY, the risk of actual
collision was further reduced by horizontal errors too.  Seems to me like a
good argument now for always slightly separating the tracks of reciprocal
airways.

I would be most interested in the comments of some real professionals - I'm
very much an amateur.

John Brooks  - Technical Consultant, Energy, Network Systems and Data Comms
South Croydon, 7CR2 7HN, UK Tel: (44) 181 681 1595 Fax: (44) 181 649 7536


Re: RISKS of Mail Merge for Ontario Tories (Kabay, RISKS-19.06)

Mark Brader <msb@sq.com>
Mon, 14 Apr 97 18:12:08 EDT
As further background: The Conservatives' tactic was to announce a whole
series of far-reaching measures in matter of days, all to take effect at
about the same time, all of them to be rammed through in the same manner.
Presumably they intended that opposition would be weakened by a division of
focus.  At least some of those opposing to the changes are doing so not
because they feel that the "megacity" is impractical, but because they
object to the tactics, or the other measures, and now choose to fight
anything that this government does.

> The opposition ... is proposing about 12,000 amendments

In fact, one of these amendments was passed, after the government members
missed their cue to vote on it.  Presumably a sham review will now be held
and the execution... er, changes will proceed on schedule.

After a few more days, the legislature's Speaker (moderator) ruled that
the identical parts of the text did not need to be read each time through
any more, but only the name of each street.  It still took some time,
but all the opposition amendments were defeated by the end of last week.

Presumably, the next time this sort of thing happens, the computers will be
programmed to produce a more varied set of amendments, to defeat the "only
read the changing part" technique used this time.

Mark Brader <msb@sq.com>  SoftQuad Inc., Toronto


Re: Blue Cross automated SSN update (RISKS-19.06)

"Rosenthal, Harlan" <rosenthh@dialogic.com>
Fri, 11 Apr 97 8:25:34 -0400
> The risk is that as we automate systems, we sometimes forget that
> automation does not automatically equal efficiency.

On the contrary, as you pointed out yourself - it's very efficient for
*them*.  The problem is that the time/labor/intelligence load hasn't been
*saved*, it's just been transferred to the users.  For most people who use
such a system once per year, the amount of additional load should be minimal
... except that if a previously painless task becomes annoying, the cost in
public relations more than outweighs the savings in staff.

I work for a company that makes voicemail components.  We cringe every time
we hear about "voice-mail jail" and other poor uses of such technology,
because one bad example puts people off the entire concept, which is =on
average= pretty useful.  Same goes for computers and just about anything
else.

-harlan


Fun with export/import controls

Steve Gibbons <steve@wyrm.AZTech.Net>
Fri, 11 Apr 97 22:55:01 -0700
It's been an interesting week for me WRT security and export/import
controls.

I've been using MIT PGP v2.6.2 and Viacrypt's v2.7.1 (Macintosh) for quite a
while on my home systems.  I also use Viacrypt's v2.7.1 (AIX) product where
I work.  Yes, all of my machines are located in the U.S. or Canada.  Yes, I
realize this is an export-controlled product.  Yes, I have agreed not to
export any of these products to people that shouldn't have them.  Yes, I
even avoid using the freeware version for business purposes.  Enough
background...

I was somewhat disheartened to learn that I could not download any of PGP's
(or MIT's) current products from work via the WWW because the administrators
of our firewall had implemented a policy of "if it's not explicitly
permitted, it is denied."  PGP's and MIT's download servers run on
non-standard ports (i.e.  they don't run on the IANA assigned port 80 for
http) and were, hence, blocked from access by me from work.

The risks: Enforcing security policies blindly can actually reduce security.

I was further disheartened, when I attempted to download several of PGP's
latest products for the Macintosh to my home system.  After answering "Yes"
to several questions related to my status for distribution, I was eventually
greeted with a message that said something like "We can't determine if you
are located in the U.S. or Canada, so you have to go through the manual
order process."  I'm 99% sure that this message was generated by whatever
mechanism performs IP address to hostname lookups.  My TLD happens to be
.NET, which is not geographically limited to the US (but, then again,
neither is .COM, go figure...)

The risks: Trusting DNS, Trusting the InterNIC.

I then thought I would get "cute" and try using the lynx browser from the
shell account that I have with my ISP.  This failed, since at least part of
the download process for some products required shhtp (SSL) connections and
SSL was not supported by lynx.

The risks: as a producer of information, disregarding low-end client
software can lose some (percentage) of the total market.

I then said (to myself) "what the heck." and pointed my Mac browser at
http://www.anonymizer.com/ and then entered the URL for PGP's site.  Lo and
behold, I was eventually greeted with "You have successfully passed export
restriction."

I now have access to the files that I should have been able to (legally)
access all along by way of "cheating."

The risks: It's very probable that lots of other people have access to files
that they are not legally entitled to by the same means.

Other risks: The government _cannot_ control access to information once it
has been made publicly available and is widespread.  (At least they can't
control things without resorting to means that would toss the bill of rights
out the window - Apologies in advance for the US-centric view of things....)

Steve@AZTech.Net (sgibbo@amex-trs.com)

  [NOTE ADDED LATER: I mention above using www.anonymizer.com to access
  export-restricted content at www.pgp.com.  Unfortunately, I was misled by
  the message "You have successfully passed export restriction."
  The next page in the download sequence (that I did not follow
  when I wrote the original article) is secured via ssl and could not be
  accessed through the current incarnation of the anonymizer service.  Steve]


On the naming of names (was Re: Y2K, (Rosenthal, RISKS-18.95)

Danny House <dkh@ipsa.reuter.com>
Mon, 14 Apr 1997 13:58:00 -0400
In my first job I had to support code in which the variables were
    i, ii, iii, iiii, j, jj, ...
which continued through k and l.

More recently, I worked at a place where the ENFORCED naming convention
had been to label the functions called by a program named joe thus:
    joe_i_j_k...    where i, j and k are integers
This meant that joe_2_3 was the third function called by the
second function called by main (the language was C).  In fairness, the
convention was discontinued before I arrived.  Still, there was a huge
amount of code written to the standard that had to be maintained.

I have seen code where large groups of variables were prefixed with x_,
then repeated with p_, etc.  Of course you might wonder why there were
large groups of variables in the same scope at all (don't ask me).

It sometimes seems to me that our limited name-space is one of the most
significant obstacles to code re-use.  Our linkers are no help at all:
if two libraries refer to the function, but expect it to behave
differently, only trouble will come of it.  Strong meaningful names
fail if the only difference among various implementations are in the
time/space/re-entrancy trade-offs.  There are lots of dictionary
algorithms.

The hardware solution of numbering each type of chip and providing a
huge variety to choose from is hardly appealing.  Yet I have seen three
letter acronyms collide, and have been forced to work with 5 letter
prefixes on large projects.  They certainly don't appear meaningful,
but they can provide a somewhat OO feel.  OO languages alleviate the
problem somewhat, but we still see serious products with these ugly
prefixes.  Perhaps the hardware solution will be approached asymptotically.

Risks?
* In order to reuse well-designed and tested libraries, we accept
  meaningless names.
* In order for names to be meaningful, we accept that only one
  can fit on a line.
* Meaningful names are 'documentation', and we will try to debug
  what they mean instead of what the code is really doing.
* Someone will sell us another cure-all that doesn't.
* I will have to learn yet another naming convention.

Danny House


Telecommunications & Democracy: Historic Citizens' Report

Richard Sclove <resclove@amherst.edu>
          TELECOMMUNICATIONS & THE FUTURE OF DEMOCRACY
      Preliminary Report on the First U.S. Citizens' Panel
                by Dick Sclove, The Loka Institute

A 7-page report is at <http://www.amherst.edu/~loka/alerts/loka.4.3.htm>.
You can also receive the full report by e-mailing <Loka@amherst.edu>, asking
us to e-mail you "Loka Alert 4:3."

Dick Sclove, Executive Director, The Loka Institute, P.O. Box 355
Amherst, MA  01004, USA  resclove@amherst.edu +(413) 582-5860

Please report problems with the web pages to the maintainer

Top