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 58

Friday 30 January 1998

Contents

o Man jailed because of computer glitch
Bear Giles
o False identification of child support deadbeats
Epstein Family
o Y2K bug at major bank?
Andrew Walduck
o Dangerous handling of null variables in programs
Mike Jeays
o Internet Explorer flaw
Joseph Bergin
o Location tracing service of handy phones starts in Tokyo
Kenji Rikitake
o EuroParl Rpt on NSA, Trade, & Crypto Controls
Vin McLellan
o Crash of A-320, Strasbourg
Alexandre Siniakov
o Re: TCAS near-miss
Nancy Leveson
o Re: robots.txt
Bertrand Meyer
o 4-Letter words, Re: CyberSitter
Devon McCormick
o Re: Possible Netscape source code risks
Dale Martin
o Info on RISKS (comp.risks)

Man jailed because of computer glitch

Bear Giles <bgiles@kentek.com>
Wed, 28 Jan 98 16:45:42 MST
>From "Glitches of the Week",
http://www.currents.net/newstoday/98/01/27/news1.html

>Man Jailed Because of Computer Glitch
> Tony Ninness of Agnes Waters, Australia, was jailed for six hours for
> failing to pay a traffic fine, even though it turned out he had paid the
> fine five years ago.  Last month, police came to Ninness' residence with
> outstanding warrants for his arrest.  He was held in custody at the Agnes
> Waters police station until the friend paid the police $1350.  The next
> day, courthouse staff confirmed that Ninness had indeed paid off the fine
> long ago, and issued him a refund check.  But then the police contacted
> him and said they had issued too large a refund, and said he would be
> jailed again unless he returned $114.60.  "It sounds like a load of
> rubbish to me," Ninness told the Sunday Mail newspaper.  "Why should I pay
> it?  It's not my fault."  Police officials blamed computer glitches for
> the problems.

Unfortunately, the article doesn't make it clear if the "excess amount" was
on top of what the friend paid in "outstanding" fines, or if the check was
for $1350 and the police demanded incarceration charges similar to those
becoming common in the United States.

Bear Giles  bear@coyotesong.com


False identification of child support deadbeats

Epstein Family <jepstein@mail1.mnsinc.com>
Thu, 29 Jan 1998 21:12:12 -0500
*The Washington Post* (29 Jan 1998) reports that the state of Virginia has
been cracking down on noncustodial parents who have fallen behind on child
support payments.  About 15,000 people have paid $15 million.  But 2300
other people were incorrectly identified as delinquent and were sent notices
revoking any hunting and fishing licenses they have.  The incorrect notices
were caused by "a computer programming error".  The state official
responsible for child support apologized and said that safeguards have been
put in place to avoid it happening again.


Y2K bug at major bank?

"Andrew Walduck" <waldua@nortel.ca>
27 Jan 1998 17:48 EST
I'm having an interesting encounter with one of the major Canadian banks
right now over RRSP (registered retirement savings plan) receipts.  It
smells vaguely Y2K-ish.  Here's the scenario.

In August of 1997, I purchased 11 $1000 GICs (guaranteed investment
certificates) laddered at 4 months increments with the farthest out one
coming due in 5 years (or 2002-09), the earliest would come due in 1 year, 8
months (1999-05) (the actual maturities are 1999 5, 1999 9, 2000 1, 2000 5,
2000 9, 2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9).

In December, I received a receipt for $2000. The bank usually accumulates up
all of your contributions for the year and then sends one receipt. In my
case, I should have received a receipt for $11,000. I thought this strange,
so I phoned their call center and was told that a receipt for the rest of
the amount would be coming. So I made a note in my daytimer, and let it
sleep.  So today (end of January, 1998) I phoned my branch and talked to a
rep I know there about my account. She checks the records and they show that
I was to receive only a $2000 receipt (not $11,000), although, there are 11
different GICs in my account all purchased in August! Fortunately, I still
have the temporary, no good for taxes, receipt. So now she's investigating
and I did some thinking.  Of the 11 GICs I purchased, 2 came due before
2000, (in 1999 5 and 1999 9), the rest came due in (2000 1, 2000 5, 2000 9,
2001 1, 2001 5, 2001 9, 2002 1, 2002 5, 2002 9). Hmm... $2000 receipt... for
the ones maturing before 2000?  Where did the receipt for the rest go?? ;-)

The hypothesis: If you buy a GIC that matures after 2000-1-1, the receipt
program breaks, and ignores the amount. You don't get a receipt mailed to
you.

Has anyone else had this experience with a Canadian bank?

Andrew Walduck


Dangerous handling of null variables in programs

"Jeays, Mike" <JEAYS@statcan.ca>
Wed, 28 Jan 1998 09:26:00 -0500
The treatment of null values is arguably reasonable once it is understood -
null values simply fail all comparisons with non-null variables. This means
that if you ask if x(null) < y(non-null), you will be told "no". The same
thing will happen if you change the operator to ">".  Not too bad so far.

However - I found the result of "<>" deceptive. It fooled me into writing a
statement that did the exact opposite of what I expected.  Behaviour like
this in a language is dangerous, because many people will fall into the
trap, and some of them will bring down national telephone systems.

The following code snippets are NOT equivalent:

if x=b then
  print "Equal"
else
  print "Not equal"
endif

and

if x<>b then
  print "Not equal"
else
  print "Equal"
endif

The latter is perverse and non-intuitive. It says the two variables
are equal when one of them is null and the other isn't. Think very
carefully when you use the "<>" operator!


Internet Explorer flaw

"Joseph Bergin" <berginf@pace.edu>
Wed, 28 Jan 1998 07:32:02 -0800 (PST)
It seems MS/IE makes it easy to steal private keys:

  Microsoft Product Flaws Make Net Dangerous, Experts Say
  By Douglas Hayward, TechWeb (23 Jan 1998)
  <http://www.techweb.com/wire/story/TWB19980123S0007>

Joseph Bergin, Professor, Pace University, Computer Science, One Pace Plaza,
NY NY 10038  berginf@pace.edu  http://csis.pace.edu/~bergin/

  [The beginning of the text is excerpted below by PGN Stark Abstracting:]

Flaws in the security of Microsoft's Internet products allow malicious
hackers to steal users' private encryption keys and impersonate their
victims, security experts said.  [...]  A security advisory note circulated
this week by Peter Gutmann, a security expert in New Zealand, said that
private encryption keys can easily be stolen from the hard disks of machines
whose users are surfing the Web, thanks to flaws in several Microsoft
products, including the Internet Explorer browser and the Internet
Information Server package.  "I would say it was a fairly important security
flaw," Gutmann told TechWeb. "At the moment there is no defense against the
problem."


Location tracing service of handy phones starts in Tokyo

Kenji Rikitake <kenji.rikitake@acm.org>
Thu, 29 Jan 1998 20:38:20 +0900 (JST)
On 20 Jan 1998, NTT Central Personal Communication Network Inc. announced an
experimental service of providing the estimated location of a PHS (Personal
Handy-phone System) terminal through a FAX machine.  The service will be
provided in Tokyo from February to April.  The location information is
accessible by any FAX machine with the phone number and the access PIN of
the PHS terminal.  The information is given by a circle on a map, with the
radius of 100 to 500 meters (or 328 to 1640 feet) range.

The company has been field-testing the service since July 1997, and will
provide the same kind of experimental service for The coming Nagano Olympic
Games too.

The risk is quite obvious; anyone who has a PHS terminal is technically
traceable, without the consent or knowledge of the owner.  I found a similar
service was being developed by British Telecom too[1].

PHS is quite popular in Japan. The number of PHS service subscriber in Japan
was 6,992,000 as of December 31, 1997, according to the report of
Telecommunications Carriers Association[2].

References:
[1] "Spy phones trace cheating husbands -- and employees", RISKS Forum 19:35.
[2] http://www.teleserve.co.jp/tca/whatn/whatn_e.html

Kenji Rikitake <kenji.rikitake@acm.org> <URL:http://www.k2r.org/kenji/>


EuroParl Rpt on NSA, Trade, & Crypto Controls

Vin McLellan < <vin@shore.net>
Wed, 28 Jan 1998 03:30:35 -0500
A draft ("consultation version") of a report by the European Parliament's
Office for Scientific and Technological Option Assessment (STOA) entitled
"AN APPRAISAL OF TECHNOLOGIES OF POLITICAL CONTROL" has been submitted to
the EuroParl's Civil Liberties and Interior Committee. Several IT-relevant
excerpts are now available at John Young's widely respected crypto-politics
website: <<http://www.jya.com/atpc.htm>

(STOA regs apparently require a document to be distributed only on paper
while it is a "working document."  Quaint, huh? A hardcopy can be ordered by
e-mail from the office of British MEP Glyn Ford <

Crash of A-320, Strasbourg

"SINIAKOV ALEXANDRE" <san_k11@ns.aanet.ru>
Fri, 23 Jan 1998 20:38:24 +0300
About the cause of air accidents and crashes of

 * Boeing-747, Flight 826, 28 Dec 1997 (Tokyo-Honolulu)
 * A-320, 20 Jan 1992 (Mont Saint-Odile, France)
 * A-310, 22 Mar 1994 (Novokuznetsk, Russia)
 * Tu-154, 6 Dec 1995 (Habarovsk, Russia)

Computer researches show,that Local Geophysical Resonance was primary cause
of these air accidents (B-747) and crashes (A-320, A-310, Tu-154).  This is
a previously unrecognized natural phenomenon, connected with the resonance
characteristics of both the solar system and outer space.  LGR arises from
the interaction of the planets of the solar system and is a cause of an
excitement of space-local sones.  In such cases natural and technical
catastrophes take place.

Specifically, under certain conditions at a moment of LGR, aircraft
flight-safety-critical whirlwinds (tornados) arise.  The whirlwinds are the
common cause of these incidents.


Re: TCAS near-miss (Bellovin, RISKS-19.55)

Nancy Leveson <leveson@cs.washington.edu>
Wed, 28 Jan 1998 06:11:30 -0800
 > ... Someone on the ground switched on a transponder; the TCAS system on
 > the plane overhead decided that an aircraft had suddenly appeared 3000
 > below it, and suggested that the pilot climb.

This didn't make any sense to me.  TCAS recognizes transponders on the
ground and ignores them.  It also only issues alerts near the ground when an
aircraft is within 750 feet (not 3000) and even at high altitudes the max is
950.

As usual, what you see on the net has been garbled.  The FAA is still
investigating, but apparently the radar data shows that the actual
separation between the two aircraft was much greater than reported by the
media (in fact, the media has exaggerated the whole event).

What seems to have happened is that a maintenance shop on the ground was
testing the altitude reporting capability of the transponder and the
transponder was reporting an altitude above ground level.  The FAA has
guidance to perform such tests with the transponder antenna shielded so that
these events will not occur.  They are still investigating why the shielding
did not occur.

Where the media got the number "3000 feet below it" is unknown but was
probably a garbling of the Southwest Airlines plane's climb rate of 3000
feet per minute.

  [It would indeed be helpful if would-be RISKS contributions gave
  specific sources of information.  To satisfy that desideratum in
  this case, I note that Nancy's information comes from the head of the TCAS
  program at the FAA and the AIRINC investigation report of the incident.
  PGN]


Re: robots.txt (Meyer, RISKS-19.57)

Bertrand Meyer <bertrand@eiffel.com>
Fri, 30 Jan 98 00:23:26 PST
I have received a flurry of responses to my article describing the risks
associated with the `robots.txt' convention for excluding search engines
from indexing parts of a Web site.

I apologize for not responding individually to all the people who wrote to
me.  I have put, however, all the answers in a Web page, for the benefit of
anyone who cares to consult them:

    http://www.eiffel.com/private/meyer/robots.html

(available Saturday, Jan 31st, 18:00 California time).

The common theme of the answers can be summarized as follows: I was wrong to
criticize the robots.txt design because it is not meant to protect pages,
simply to keep search engines away from pages that are not *worth* indexing,
e.g. because they are of temporary values. To quote one correspondent, Osma
Ahvenlampi <oa@iki.fi>:

> Robots.txt is a way to protect your web server from being overloaded by a
> dumb robot in a cgi loop, not a security tool. This much should be obvious
> to anyone capable to be in charge of web site administration.

or, according to Chris Cheyney <cheyney@mindspring.com>:

> Anyone stupid enough to leave a network open and count on the optional
> robots.txt robot exclusion de-facto standard for security gets (and should
> get) what he deserves.

Among the people making similar points: Thomas Andrews
<thomaso@andromedia.com>, Nelson Minar <nelson@media.mit.edu>, John
R. Levine <johnl@iecc.com>, Jeremy Nelson <jem@stairways.com.au>, Barry
Margolin <barmar@bbnplanet.com>, Laurentiu Badea <byte@lmn.pub.ro>, Klaus
Johannes Rusch <KlausRusch@atmedia.net>. Again, see the Web page for the
details of their comments.

I stand by my original assessment:

1. If every facility was always used as its designers intended, the RISKS
archives would be noticeably slimmer. Here the possibility of misuse seems
rather considerable. If you are just a bit absent-minded, isn't it natural
to use this mechanism to exclude stuff from being indexed and hence believe
no one will find it? "Stupid", maybe -- but not unlikely.  After all, the
designers of the Mercedes A-Class car could also say "anyone stupid enough
to swerve violently when an elk crosses the road gets (and should get) what
he deserves". Unfortunately for them, and probably fortunately for most of
us, that doesn't pass muster.

2. For anyone who thinks this is just a hypothetical possibility, here is
the robots.txt file of the site of a major communications company:

 robots.txt

    User-agent: *
    Disallow: /bug-navigator # Bug Data
    Disallow: /warp/customer # Registered Users
    Disallow: /kobayashi # Navigation for registered
    Disallow: /cgi-bin # no programs
    Disallow: /pcgi-bin # no programs
    Disallow: /univ-src/ccden # will get content through /univercd
    Disallow: /cpropub/univercd # obsolete

The first two lines at least suggest to me that this is stuff that the
company doesn't want publicized -- for security reasons, not because it is
of temporary value.  Were I a "hacker" in the bad sense of the term, I would
revel in such information, as it would direct my efforts to the really juicy
bits.

Here is an extract from another page -- I'll let you guess the URL:

    # o Created this file to prevent indexing of one
    #   SME directory.

    User-agent: *

    Disallow: /sparc/SPARCengineUltraAX/oem/
    Disallow: /microelectronics/SPARCengineUltraAX/oem/
    Disallow: /javachip/SPARCengineUltraAX/oem/
    Disallow: /javachips/SPARCengineUltraAX/oem/

    Disallow: /sparc/SPARCengineUltraAX/download/
    Disallow: /microelectronics/SPARCengineUltraAX/download/
    Disallow: /javachip/SPARCengineUltraAX/download/
    Disallow: /javachips/SPARCengineUltraAX/download/

I can't say for sure, but doesn't some of this look a tad like
proprietary information?

3. So even if the respondents are right that it is "stupid" to use
robots.txt in that way, my posting at least draws attention to the risk. If
it succeeds in making just one Webmaster a bit more careful, it will not
have been useless.

4. Of course designers cannot always be blamed for misuses of their
mechanisms. But they should minimize the possibility of misuses. In the
robots.txt case it seems to me rather wrong to have a conspicuous
world-readable file that draws attention to *excluded* information. (Reminds
me of programming languages which implement information hiding by making the
author of each module list conspicuously, as the first thing you read in the
module's text, those features which are *not* exported!) This draws
attention to what should not attract attention. I think that a more
effective convention would have been to include a special marker (META tag?)
in HTML files that shouldn't be indexed, and a special file (exclude.txt?)
in the directories that should not be explored at all. Then you would only
be able to find that information if you already knew where to look.  The
robots.txt mechanism is a godsend for Peeping Toms in search of possible
secrets.

(Thanks too to Marc Horowitz <marc@cygnus.com> and
Rik Moonen <rik.moonen@technopol.be> for their comments.)

Bertrand Meyer, Interactive Software Engineering, makers of ISE Eiffel
<Bertrand.Meyer@eiffel.com>, http://www.eiffel.com


4-Letter words, re: CyberSitter

Devon McCormick <Devon.McCormick@bankerstrust.com>
27 Jan 1998 13:43:51 -0500
  [I wrote an article on the ramifications of binary data as "bad words" for
  our local New York APL (A Programming Language) newsletter.  I think you
  can get the gist of it without the special font you need to read the APL
  code properly.  Devon]

I was thinking about the CDA (Communications Decency Act) the other day,
about how much more important it is to protect our children from bad words
than from bad laws, and I wondered what I could do to help make the 'net
as bland and harmless as television.  One danger no one has pointed out
has to do with another fine U.S. government initiative, the Clipper chip
(or whatever name it's disguised under right now).  It occurred to me that
any good encryption routine, and the NSA promises that Clipper is real good,
effectively turns its input into an output that appears random.

This raises the dismaying possibility, in fact certainty, that an encrypted
datastream will contain dirty words!  At first glance this seems to be simple
enough to remedy: we can scan the encrypted stream for dirty words and replace
them with some equivalent string then convert them back at decryption time;
in fact, someone has already written software to do this using names of U.S.
senators as the dirty word equivalents.  However, this is not as simple as it
seems.  Consider that a dirty word may be written in upper-case letters,
lower-case, or a combination of the two.  Also, there is the concern of
performance degradation.

Pondering these difficulties, I realized that since most dirty words are 4
letters (bytes) long, and that most computers do well with 4-byte (integer)
conversions and comparisons, there is a good solution: consider only the
equivalent "dirty" numbers!  Once I had had this insight I leapt to my
keyboard to answer the question that must now be burning in your mind the
way it was then in mine: just what are these dirty numbers and what can we
do with them?

The following Dyalog APL session explores some of the possibilities.  One
advantage dirty numbers have over dirty words is that you can do things
like find the "average" dirty word: this could lead to a whole new class
of forbidden words (albeit largely unpronounceable ones).

      BADWORDS
7 4

       Apologies to George Carlin.

      BADWORDS[;0],'*','*',BADWORDS[;,3]
F**K
S**T
Q**M
C**T
F**T
D**N
P**S
   Or, for the more squeamish:
      BADWORDS[;,0],7 3'*'
F***
S***
Q***
C***
F***
D***
P***
      ALPNUMAV

OK, let's see what the all-upper-case dirty numbers look like:

      (ALPNUM)ALPNUMBADWORDS
302078184196 357695050756 349323218180 289194005508 301743625220
      293153361412 344827581188

Account for all possible upper- and lower- case combinations by expanding
the upper-case versions with all 4 digit boolean combinations (so "1 1 1 1"
maps all-upper to all-lower, "1 0 0 0" maps all-upper to initial upper-case
letter only).

      VARBW(-/AV'Aa')((42)16)
       Assumes upper and lower alphabets are each contiguous.
      ALLBW(VARBW)+ALPNUMBADWORDS
 16 4  16 4  16 4  16 4  16 4  16 4  16 4
      BADWORDS-ALPNUM[ALLBW]   Check that we have what we think we do
1

      BADVARIANTS(ALPNUM)ALLBW
7 16
      BADVARIANTS
1179992907 1179992955 1180005195 1180005243 1183138635 ...
1397246292 1397246340 1397258580 1397258628 1400392020 ...
1364543821 1364543869 1364556109 1364556157 1367689549 ...
1129664084 1129664132 1129676372 1129676420 1132809812 ...
1178686036 1178686084 1178698324 1178698372 1181831764 ...
1145130318 1145130366 1145142606 1145142654 1148276046 ...
1346982739 1346982787 1346995027 1346995075 1350128467 ...

       So, the average of each bad word variant is:
      ALPNUM[(4ALPNUM).5+(+/BADVARIANTS)16]
. $


 $
.Y
 %Y


       And the average variant bad words are:
      ALPNUM[(4ALPNUM).5+(+BADVARIANTS)7]
J
J
J"
J"
J<
J<
J<"
J<"


"
"
<
<
<"
<"

       And the overall average bad word is:
      ALPNUM[,(4ALPNUM).5+(+/,BADVARIANTS),BADVARIANTS]
ֹ
       So, ֹ the CDA!


Re: Possible Netscape source code risks (Wilson, RISKS-19.57)

Dale Martin <dmartin@helga.ececs.uc.edu>
28 Jan 1998 16:32:38 -0500
This possibility exists with ANY software project.  Personally, I feel
better about source code that's being looked at by thousands of developers
rather than a few in a company, at least with regards to "slipping nasty
things in so-called bugfixes".

Dale E. Martin | University of Cincinnati Savant Research Laboratory
dmartin@ececs.uc.edu   http://www.ececs.uc.edu/~dmartin

Please report problems with the web pages to the maintainer

Top