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 18 Issue 4

Monday 15 April 1996

Contents

o OS/2 Warp TCP/IP misfeature
Pete Bentley
o Data entry omission extends prisoner's sentence
James K. Huggins
o Has the net reached a critical size?
Frederick Roeber
o Single names and identification
Colin Eric Johnson
o The joys of FAX machines
Drew Dean
o Real "Natural" language design isn't easy either
Peter Van Eynde
o Another Daylight Saving Time problem: Netscape 2.* reload
John F. Whitehead
Prentiss Riddle
o Another Daylight Savings Time risk: billing
Lorne Beaton
o Abuse of statistics about computer crime
Dan Barrett
o Phone-sex users on web index accidentally [Name withheld by request]
o Re: The weakest link
Paul Robinson
o Re: X-Confirm-Reading-To: Pegasus woes ...
David Woolley
Peter Yamamoto
o Re: A note on e-mail
David Milun
Jiri Baum
o Info on RISKS (comp.risks)

OS/2 Warp TCP/IP misfeature

Pete Bentley <pete@mimir.com>
Thu, 11 Apr 1996 12:44:22 +0100
[ I was recently reminded of this one by a thread in a newsgroup I frequent ]

It seems that in the OS/2 (2.1 and Warp) TCP/IP stack socket descriptors are
system-wide.  That is, they aren't per-process file descriptors, so if you
can discover the number of some other process's socket (and netstat -s will
helpfully list all the open sockets on the system) you can send(), recv(),
shutdown() or do many other fun things with it.

Risks include the fact that anyone with telnet access to the machine (and
OS/2 telnet security is a risk in itself) can write a program to subvert any
TCP/IP server running on it.

A shame, because otherwise it's one of the better non-Unix implementations
of the BSD socket API.

Pete


Data entry omission extends prisoner's sentence

"James K. Huggins" <huggins@eecs.umich.edu>
Thu, 11 Apr 1996 10:30:12 -0400 (EDT)
Summarized from the *Detroit Free Press*, 11 April 1996, p. 4B.

John O'Valle was convicted in 1987 on charges of cocaine and weapons
possession, and was expected to serve 20 years in prison.  Later on,
however, the sentencing judge reduced the sentence on technical grounds,
making him eligible for release in 1992.  The reduction was noted in
O'Valle's written file, but not in the Department of Corrections' computer
records.  (Neither O'Valle nor his lawyer was notified of the change.)

In January 1996, prison officials reviewed his records and discovered the
discrepancy.  However, there is now a new problem.  In 1995, O'Valle was
convicted for possession of marijuana while in prison, a felony.  Had he not
been in prison at the time, he would have been guilty of a misdemeanor and
not subject to jail time.  So now O'Valle is serving time for a felony,
which (presumably) never would have happened had he been released on time.
State officials aren't sure what to do.

Officials aren't sure what happened.  O'Valle's warden says that sentencing
formulas are complicated, and the prison camp program and parole programs
were in "transition" during the time O'Valle entered the system.

Perhaps a new story with an old moral: if you have replicated data sets,
make sure that the data sets are consistent.

Jim Huggins, University of Michigan (huggins@umich.edu)

   [The O'Valle course runs twistingly around.  PGN]


Has the net reached a critical size?

Frederick Roeber <roeber@iea.com>
Sun, 14 Apr 1996 22:15:20 GMT
I don't mean "critical" as in "film-at-eleven," but as in its size
or penetration has reached a sufficient point for a process to occur.

In ten years on the net, I've only come across a couple other people with my
last name.  Websearches never revealed anything but links to my own data.

But within the past few weeks this has changed.  RISKS had an article about
www.switchboard.com, which lists some 350 Roebers.  A new websearch finds a
dozen Roebers.  And suddenly the e-mail has started coming in-- "My name is
<something> Roeber.  Might we be related?"  And this is all happening at
once.  It shouldn't be long before we have the whole family tree worked out.

I can't say there's a hard risk to this, other than the usual ones of
privacy and how the net is making this an ever-smaller world.  (But I do
hope none of those 350 www.switchboard.com hits are actually federal
witnesses in the American witness protection plan.  Pretty soon they'll
stick out like sore thumbs.)

Frederick Roeber  roeber@iea.com - roeber@cern.ch - roeber@caltech.edu

  [Frederick has gone from being a Roeber Baron to being a DisRoeber,
  in short order.  This must be where the Roeber meets the load.  PGN]


Single names and identification

Colin Eric Johnson <colinj@unm.edu>
Mon, 15 Apr 1996 14:50:55 -0600 (MDT)
It seems that a friend's friend [name altered] decided that he wanted to
only have a single name, Smith. When Smith had his name legally changed to
just Smith one of the things that he had to do was get a new drivers
license. So he headed on down to the local DMV.

It seems that the state of Oregon (at the time at least) had a computer
system that required that both a first *AND* last name be entered for every
persons license. Of course Smith only had one name (and the paper to prove
it). So after struggling with the system for a while the diligent workers
asked Smith to come back in a couple of days when they would have a license
for him. And, sure enough, a couple of days later he returned to find a
license with just the name Smith on it waiting for him, all seemed to be
well.

While on a road trip, which Smith is prone to, he was pulled over for some
sort of traffic violation. When he was offered up his license as per request
the police officers were concerned with his lack of a second name (first or
last? you decide). When they looked him up, he was not in Oregon at this
time, they could not find any such person as "Smith" in the Oregon registry.
At this point the police officers began to get suspicious. After much
investigation, and a great deal of lost time and frustration on the part of
Smith and the local constabulary, it was determined that the state of Oregon
had done the following:

Failing to get the system to accept a single name for a drivers license they
inserted a fictitious second name "Jay". They then simply altered the
printing process so that only the name "Smith" actually appeared on the
license. So to find Smith in the Oregon listing one would have to look under
"Smith Jay".

The risks? Well, I believe trouble with the law would be obvious in this
case. It might also cause problems in terms of employment where security and
background checks are done as well as insurance. I believe that the least
that could have been done would have been to explain to Smith what had been
done to make this work. It might also be more appropriate to have a preset
second name like "No Second Name" that could appear either in the list, on
the license or both.

Colin Johnson | colinj@unm.edu | http://www.unm.edu/~colinj/


The joys of FAX machines

Drew Dean <ddean@CS.Princeton.EDU>
Sat, 13 Apr 1996 19:18:28 -0400
I was filling out an application for a summer job.  Time was of the essence,
so the company's normal employment application was FAXed to me.  Printed in
landscape mode, the bottom question, about whether I'd been convicted of a
crime, got cut off by the FAX machine.  Since various companies ask the
question in different ways (some ask only about felonies, others include
traffic citations, etc.), I decided that the best approach was to write in,
"I have not been convicted of a felony" and to initial it.  I then FAXed the
application back.

I received a phone call within the hour asking if I was a felon.  I had
written the word "not" a little lower on the page, and _it_ got cut off on
the return trip.  The situation was resolved, but somewhat amusing.  I've
fought laser printers that can't print closer than 1/4" to the edge of the
page before, so I should have known about the problem, but I forgot.

RISKS: You think of FAX as being WYSIWYG, but it isn't quite.  And you can't
(easily) see what the recipient will get.

Drew Dean <ddean@cs.princeton.edu>
Department of Computer Science, Princeton University


Real "Natural" language design isn't easy either

Peter Van Eynde <natst3@uia.ua.ac.be>
Thu, 11 Apr 1996 08:54:37 +0200 (MET DST)
The Netherlands and the Dutch-speaking region of Belgium have an
organization to define the language (Dutch) spoken in the two counties. This
organization reformed the Dutch language the last time in 1947-1954 by
printing "Het groene boekje" (the little green book) _Woordenlijst
Nederlandse Taal_. This book defines the rules and words used in the Dutch
language.

In the last few years, there has been a feeling of unease with the spelling:
it was felt that there were to many "illogical" words. So, a committee was
formed to reform the language. But they proposed a radical change -- for
example, the use of "c" sounding like "k" would be abolished. There was
protest (and the grounding of a "We love the letter C" group) and the
politicians told the committee to soften its proposal. It seems that they
did this (in a very short time) by simply removing rules that were too
radical, and then removing a bit more. (Nobody actually knows for sure:
interviews with committee members result in a lot of finger pointing and "It
works for me".)

So, version 2 came out, and is now law. It must be introduced in the
schools, government and media. There is one snag: the rules are not
"complete": the rules given don't even include the spelling of words given
as examples, and there are cases without any rules.

Nobody uses the green book; people use dictionaries. But the major
publishers found the rules and the words in argument, so introduced their
own rules. Each publisher has different ones. Major newspapers also have an
internal dictionary, and they did the same. One major encyclopedia publisher
even found the new rules so bad that it refuses to use the new spelling.

The RISKS? I have to write my thesis *after* the new spelling becomes law,
and I have to write it in Dutch. Now my only problem (and that of Microsoft,
Lotus(oops IBM), Word-perfect (whoever owns them), etc), is *which* Dutch.
This whole case is a textbook demonstration of the RISKS of language
specifications and the influence of politics on "natural" or "logical"
designs. 20.5 million people have to live with the consequences.

Peter Van Eynde  [It's logic Jim, but not as we know it.]


Re: Daylight Savings Time problem: Netscape 2.* reload

"John F. Whitehead" <jfw@wral-tv.com>
Thu, 11 Apr 1996 18:45:14 -0400
There has been another side effect of the daylight savings time change,
with the Netscape Navigator browser: caches have incorrect times and no
longer work properly for documents that change frequently.

Netscape Navigator version 2.x for Windows and Unix platforms is an hour off
in its cache-file handling.  If a user tries to reload a page that has
changed within the last hour, the browser still thinks its cached version is
more up to date and won't retrieve the new version.  (After an hour, this is
no longer an issue.)  This has been a problem with news organizations (such
as ours), chat/bulletin boards, and java applets that need to be updated
frequently.

Netscape's "force reload" procedure (shift key + reload button) doesn't
always work either: the only solution is to flush the memory and disk caches
before a reload, or to set them to size zero.  Netscape has made no official
statement, but apparently has said the bug won't be fixed in the next
version of the software (2.1) but in the one after that (3.0 (Atlas)).

The Macintosh version does not suffer from this bug, nor do versions 1.x, or
browsers from other manufacturer.

The risk (aside from the obvious one related to programming for time
changes) is trusting that a market-leader software company is going to have
bug-free software.

John F. Whitehead  OnLine Technical Director
919-821-8605  jfw@wral-tv.com  http://www.wral-tv.com

  [This problem was also reported by CurtAkin@aol.com and
  Prentiss Riddle <riddle@is.rice.edu> -- next message.  PGN]


Another Daylight Saving Time problem: Netscape 2.* reload

Prentiss Riddle <riddle@is.rice.edu>
Mon, 15 Apr 1996 09:14:54 -0500 (CDT)
[...] One workaround is said to be to run Netscape in California time, e.g.
under Unix:

        setenv TZ PDT ; netscape &

Defying the RISKS tradition of intoning that "the risks are obvious",
one could draw the following lessons:

   -- Time-dependent functions should be tested using multiple time
      zones and both DST- and non-DST dates.

   -- In networked applications, local time issues can cause more than
      just local problems.

Prentiss Riddle <riddle@rice.edu>  http://is.rice.edu/~riddle
RiceInfo Administrator, Rice University


Another Daylight Savings Time risk: billing

Lorne Beaton <beaton1@server.uwindsor.ca>
Thu, 11 Apr 1996 16:20:49 -0400 (EDT)
My university recently (ca. January 1, after a testing period of about a
month) instituted a new dialup service, for which students and faculty are
charged 75 cents per hour peak and 60 cents off-peak.  A couple of days ago
I logged on and saw something like the following in my logon message:

>  Charges THIS month to date   500 minutes for a cost of $   49.59
>  Charges LAST month (total)  2089 minutes for a cost of $   24.76

(Note that these aren't the exact figures, but you get the idea.)  Needless
to say I was consternated.  After complaining to the admins, I learned that
the billing discrepancy arose from the change to Daylight time.  Night owl
that I am, I happened to be logged in at the exact moment that 2:00 a.m. EST
became 3:00 a.m. EDT.  Needless to say, this was the first time they had
dealt with the changeover.  Happily, the problem has since been fixed, but
the risk is self-evident.

Lorne Beaton <beaton1@server.uwindsor.ca>


Abuse of statistics about computer crime

<barrett@liberation.cs.umass.edu>
Fri, 12 Apr 1996 12:52:50 -0400
The March 1996 issue of IEEE COMPUTER contains an article on the rise of
computer crime ("Security and Privacy TC," by Deborah Cooper and Charles
Pfleeger, pp. 118-119; TC = Technical Committee).  Based on a table of
statistics obtained from the CERT Coordination Center, the article claims
that computer crime is undergoing a "dramatic escalation."  Whether or not
this is true, the article is seriously flawed, and it points out the risks
of shoddy statistical reasoning.

Here is an excerpt from the table, which has the heading, "Computer
Emergency Response Team (CERT) statistics show that computer attacks are on
the rise."

        YEAR    INCIDENTS REPORTED
        ==========================
        1988            6
        1989          132
        1990          252
        1991          406
        1992          773
        1993         1334
        1994         2341

On first glance, this certainly appears to be a "dramatic escalation" in
computer crime... or does it?  Let's look at how much information was
not presented in the article.

The table heading discusses "attacks," but the table column says
"incidents."  So what exactly is an "incident?"  Is it a report of an
alleged attack?  (Likely, given that CERT is usually the recipient of
unsolicited reports.)  Or is it a verified attack, meaning that erroneous
reports were somehow weeded out?  If it was verified, how was it verified?
The article doesn't say.

I wrote to Pfleeger with this question, and he responded that "the source of
these statistics is CERT" and I would "have to contact them for the
interpretation of their data."  In other words, Pfleeger, Cooper, and IEEE
COMPUTER published a table of statistics that the authors did not not
themselves understand.  So I wrote to CERT, and their response indicated
that an "incident" is a report, and that they "don't talk to law enforcement
people at all" to verify that an attack is real "unless a site requests us
to."

The abuse of statistics gets worse.  While the number of incidents in the
table is approximately doubling every year, so is the population of the
Internet (source: The Economist, July 1995).  In other words, the number of
incidents grows linearly with the size of the population, which is
completely unsurprising.  This fact is not mentioned anywhere in the
article.  Pfleeger argued (by email) that "technical and physical security
controls" have improved since 1988, and yet incidents have continued to
increase "in spite of improved protection."  That is an interesting
hypothesis but hardly a reason to ignore the growth of the Net as a possible
source of increased reports.  The CERT representative reported that she
didn't "know why the authors of the article didn't mention the relationship
between the number of incidents and the number of Internet users."

Similarly, the visibility of CERT has grown greatly since 1988, and this
could account for an increase in reported incidents.  Again, this is not
mentioned in the article.  Both Pfleeger and CERT say that measuring CERT's
visibility is a non-trivial task, and I agree.  Still, the effect should
have at least been mentioned in the article.

Footnote 1 of the table mentions that "some incidents have ongoing activity
for long periods of time (i.e., more than a year)."  I asked Pfleeger
whether "ongoing activity" meant "ongoing penetration of a compromised
system," or "ongoing interaction with CERT," since the phrase is ambiguous.
Pfleeger DIDN'T KNOW and suggested I ask CERT.  He also didn't know whether
the phrase "some incidents" referred to a majority or a (possibly
insignificant) minority.  By highlighting the incidents with long ongoing
activity, the table takes on a negative slant.  After all, one could just as
easily have focused on the opposite, saying that "some incidents lasted only
a few minutes."

My intuition and experience tell me that security incidents are indeed
increasing.  In other words, I believe the basic premise of the article.
Nevertheless, the article's reasoning is flawed and contributes only to the
prevalent misinformation about computer crime and security.

Dan Barrett     dbarrett@ora.com     http://www.ora.com/item/bandits.html
Author, "Bandits on the Information Superhighway" (O'Reilly & Associates)


Phone-sex users on web index accidentally

<[Name withheld by request]>
Wed, 10 Apr 96
To see if any of my personal WWW home pages have been indexed by web
crawlers, I sometimes query the popular web search engines with my first and
last names.  Imagine my surprise when, amid the usual links, I found several
that referred to caller-id files!

Upon visiting the links, I discovered many text files containing a column of
phone numbers and a matching column of people's names.  The files were
broken up by month and year, and contained hundreds of listings each.  Some
of the names in the list were 'Pay Phone' and 'City of XXX' and 'State of
XXX'.  Often, a name and number would be repeated several times in a row,
presumably denoting multiple calls from one number.

When I removed all but the fully qualified host name from the URL address, I
was presented with the first HTML document that I'd found on this server.
It was functional, yet spartan: clearly intended for the page-developer's
use only.  From it, I ascertained that the phone lines from which the caller
-id's were taken were all named after different kinds of sexual activity.

Forgive me for jumping to conclusions, but I believe that these files were
created by a phone-sex service.  Perhaps they are used to identify satisfied
customers, or to help direct incoming calls to the proper 'talent'.

The RISKS: too many!  First, it is foolish to allow proprietary information
be stored on a server connected to the internet.  Second, any time that you
dial the phone, unless you're calling from a Pay Phone or the State of XXX,
the marketeers at the other end probably know who you are.  Finally, free
access to demographic data may be hazardous to your marriage, or job, or
whatever.


Re: The weakest link (Reifschneider, RISKS-18.02)

<ROBINSON_PAUL@Tandem.COM>
15 Apr 96 09:49:00 -0700
Sean Reifschneider reports that Social Security Administration employees
sold SSNs and "mother's maiden name" info to a credit-card fraud ring.  Many
credit card issuers require "activation" of newly-issued cards, i.e. the
recipient must call a toll-free number and give this kind of "identifying"
information before they can use the new card.

Actually, the weakest link is "the clerk who's paid $12K/year" at the
credit-card issuer.  Recently I received a new card, called the number, and
adamantly refused to give my SSN over the phone.  The somewhat flustered
clerk eventually activated my new card, having received only the credit-card
number and the zipcode (postal code) printed on the accompanying letter.  No
SSN, no "mother's maiden name," NOTHING else.

If all I need is the card and the letter, why pay off SSA employees?
I have written to the credit-card issuer, no response yet.

--paulr


Re: X-Confirm-Reading-To: Pegasus woes ... (Yamamoto, R 18 02)

David Woolley <david@djwhome.demon.co.uk>
Sun, 14 Apr 96 12:58 BST
>The "problem" is due to a new release of Pegasus which added a directed
>confirmation header field as well as keeping the old confirmation header

The new header was added precisely because the old version was causing
problems with mailing list, but people have to upgrade the reading version
not the sending version to gain the full benefit.

However, this whole thing shows the common risk that users will demand
certain features of a product ("read" receipts are a very popular feature
of Pegasus) without realising the full implications (namely they will get
a reply from every Pegasus user on the mailing list, and possibly compromise
the privacy of those subscribers).

There is, however, a very simple solution for MajorDomo and probably for
listserv, just filter out the offending headers.  The standard MajorDomo
already filters out Return-Receipt-To:, a rather more common, non-standard
header, with similar effects.  Adding such filters to MajorDomo is a
reasonable local customisation.

Although there are now safe standards for achieving these results, which
shouldn't propagate through a properly configured list server, it will be
many years, if ever (commercial factors, rather than good technical design
are now controlling the e-mail market), before they are widely implemented,
and more ad hoc methods of meeting the market demand for this feature will
arrive first.


X-Confirm-Reading-To: Pegasus woes ... (Yamamoto, RISKS-18.02)

Peter Yamamoto <pjyamamo@daisy.uwaterloo.ca>
Wed, 27 Mar 1996 00:47:51 -0500 (EST)
Two things about automatic e-mail confirmation, although the risk is nothing
new to RISKS readers...

Recently, on a mailing list I maintain, a Pegasus (the name of a Mac/Windows
e-mail reader) user posted a message with a line:

> X-Confirm-Reading-To: http://daisy.uwaterloo.ca/~pjyamamo/


Re: A note on e-mail ()

Davin Milun <milun@cs.Buffalo.EDU>
Fri, 12 Apr 1996 10:46:24 -0400 (EDT)
While I tend to disagree with your preference for "e-mail" over "email",
that pales in comparison for my dislike of the use of "email" as other than
a mass noun.

Sentences like "send me an email" or "I received an email today" bother me
intensely.  "Mail" is a mass noun --- no native English speaker would
replace "an email" with "a mail" in the above sentences!  But many casually
do it with "email", even though "email" is just "electronic mail".

Listen everyone, it's "send me some email" or "send me an email message" or
"send me a piece of email" etc..

(So, maybe PGN is correct after all.  Maybe we do need the hyphen to remind
people that "e-mail"/"email" is a modification of "mail".)

Davin Milun  milun@cs.Buffalo.EDU    http://www.cs.buffalo.edu/~milun/
Cory Search - Aquaria index: http://aquaria.cs.buffalo.edu/

  [And PGN left all of Davin's "email"s intact.  Am I ("Am I" = the French
  pronunciation for "email", sort of) Nice?]


Re: Notes on e-mail (Sandee 18.01, Stolz 18.02)

Jiri Baum <jiri@baum.com.au>
Sun, 14 Apr 1996 09:07:01 GMT
<> [...] "co=F6perate", "na=EFf", and "Bront=EB.".  [...] ...
<> Usenet (at least NNTP) is generally 8-bit transparent, and any European
<> soc.culture group will tell you that ISO 8859-1 usually works [...]

Nothing is so simple as it seems at first sight.

There is not only ISO 8859-1, but also ISO 8859-2, ISO 8859-3 etc. For a
practical example of the difficulties, see soc.culture.esperanto.
(Esperanto has the endearing feature that stripping supersigns tends to
cause a lot more confusion than in say Czech.) Most people there have given
up and are using the ugly method of a trailing x (which is human-readable
yet machine-tractable).

[...]

Using multipart/mixed and separate charsets for each section? While
that would be acceptable to people who have MIME, it would add to the
bulk of the headers that one has to skip in a plain text reader.

Of course, that's assuming that each contributor only posts in one charset.
Multi-charset contributions would be worse still... I guess it'll be a long
time before I can put my name on my Esperanto postings properly (the r
should be \v{r}, and the i should be \'{\i}).

Jiri Baum

Please report problems with the web pages to the maintainer

Top