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 35

Friday 29 August 1997

Contents

o Prosecution for pager interceptions
Steven Bellovin
o Spy phones trace cheating husbands -- and employees
Mathew
o Book burning on the Web: AOL and columnist sued
Mark Rebuck
o Federal Web Sites Lack Privacy Safeguards
Edupage
o Hacking Risks, Paying for tracking you down
Robert J. Perillo
o Tcl 8.0 Y2K Risk
Lloyd Wood
o Photocopier codes
Marcus L. Rowland
o Oracle web server on Unix and passwords
Dawn Myfanwy Cohen
o Relying on systems maintenance taking place in another time zone
Olivier MJ Crepin-Leblond
o Re: Spelling-checker risks
Dave Katz
o Mangled characters in text
"ET"
o Re: SET Risks
Tony Lewis
Martin Poole
o Intentional analysis, re: SET Risks
Charlie Lane
o Re: USC 47:227
Duane Thompson
o Re: Public loo guilty of making nuisance calls
Aaron M. Renn
o Re: Tobacco Deal Could Set Precedent for Would-be Net Censors
David T.S. Fraser
o Risks of believing the obvious, though impossible
Sam Lepore
PGN
Sam
o ICDCS-18 call for papers
Diego Latella
o Info on RISKS (comp.risks)

Prosecution for pager interceptions

Steven Bellovin <smb@research.att.com>
Wed, 27 Aug 1997 22:07:22 -0400
A New Jersey company has been charged with illegally intercepting and
selling messages sent via a paging service.  The messages -- the content of
which was sold to news organizations -- were intended for delivery to the
offices of various senior New York City officials, including the mayor's
office and various top police and fire department officers.

That alone wouldn't make this a story for RISKS.  What makes it interesting
is why these messages were sent via pager -- the police department
considered them to be too sensitive to broadcast on police radio
frequencies.  After all, anyone with a scanner could hear those messages,
but pager messages are blessed with special pixie dust known as "digital
format".  Besides -- intercepting those messages is illegal, unlike using a
scanner.

The obvious answer is to use cryptography, of course.  But does anyone make
a PGP-capable pager?

[Added note from Steve:]
The NYT story also quotes PGN as saying this is the first such case
[PGN was referring to the first prosecution] he knew of.  Actually, the
hacker community has been doing this for years -- there was a demo at
H.O.P.E. (Hackers on Planet Earth, Aug 13-14, 1994, New York) -- with a
screen displaying all incoming pages in real-time.

  [No surprise there.  That "community" is generally way ahead of the
  would-be "protectors" and users of the computer-communication
  infrastructure.  Incidentally, the name of the company is Breaking News
  Network, a wonderful pun in itself, although Breakin' News Network would
  have been even cuter.  PGN]

  [Moderator's comment on Steve's advice to use encryption: With
  the new legislation to pay medical schools *not* to teach students,
  perhaps we will enter an era when the U.S. Government pays
  cryptographers *not* to do research.  (I know April Fools' Day
  is still 7 months away, but I could not resist.)  PGN]

[A further note from Steve included an article by Amy Westfeldt in *The New
York Times* of 29 Aug 1997 to the effect that BNN denies intercepting the
messages, and blames two disgruntled former volunteers who were released six
months ago.  BNN claims it did not even have the facilities to do the
cloning/scanning.  BNN's attorney accused prosecutors and NYC officials of
targeting BNN because this incident had embarrassed Mayor Giuliani.  A
spokesman for the mayor countered, noting that this was a federal
prosecution, not a city action.  PGN Abstracting]


Spy phones trace cheating husbands -- and employees

mathew <meta@pobox.com>
Wed, 27 Aug 1997 10:40:50 -0400
Electronic Telegraph, <URL:http://www.telegraph.co.uk/>, 27th August 1997:

Spy phones trace cheating husbands (By Robert Uhlig, Technology Correspondent)

A MOBILE telephone being developed by British Telecom could soon spell an
end to the deceptions by idle employees, stressed executives and adulterers.
The Mobile Social Alarm or Mosa, currently under development at BT, will be
the first telephone that can send precise details of the caller's location
to the person receiving the call.  Workers will no longer be able to phone
the office pretending to be sick when they are at the beach and movements of
cheating spouses will be exposed because the phone will show the caller's
location to within 30 feet.

According to Don Golding, a mobile applications engineer in charge of the
project, companies will also be able to call the Mosa-phone without their
employees' knowledge to track staff.

What gets me about this story is the gleeful reporting of the fact that
companies will be able to call your phone and trace your exact location,
without your knowledge or consent -- and that this is apparently a
deliberately designed-in feature of the system.  Does Don Golding read
RISKS, I wonder?

mathew <URL:http://www.pobox.com/%7Emeta/>

  [The Southern California ladies will use a Her-Mosa Beach Model.  PGN]


Book burning on the Web: AOL and columnist sued

Mark Rebuck <rebuck@us.ibm.com>
Thu, 28 Aug 1997 12:49:27 -0400
Sidney Blumenthal, a former advisor to President Clinton, has filed a $30
million defamation lawsuit against cyber-columnist Matt Drudge and AOL.
Normally, I don't get too excited about defamation/slander suits.  However,
the following quote from William McDaniel, attorney for Mr. Drudge, managed
to get my attention:

> [McDaniel said,] "one special aspect of defamation over the Internet is
> that it is difficult to remove the false material" because it can be
> downloaded, printed or stored by any number of readers.

Perhaps I am just being paranoid, but McDaniel's statement sounds similar to
"Darn it, we can't burn books on the Web like we can in the real world!"

(I read about the lawsuit from an AP item in USA Today: www.usatoday.com.)

-Mark Rebuck,  rebuck@us.ibm.com


Federal Web Sites Lack Privacy Safeguards (Edupage)

Edupage Editors <educom@educom.unc.edu>
Thu, 28 Aug 1997 11:30:29 -0400
OMB Watch, a nonprofit group that monitors government activities, faults the
federal government for its lackadaisical approach to protecting the privacy
of government agency Web site visitors.  "There is no government-wide policy
regarding privacy concerns on federal Web sites...  Agencies collect
personal information about visitors to their Web sites, but fail to tell
them why that information is being collected and what it is being used for,"
says an OMB Watch information specialist.  Nearly half of 70 federal
agencies collect information about their online visitors, but only 11 inform
them how that information will be used.  Three agencies, including the
National Science Foundation, were collecting cookies -- a set of data that
enables the Web server to track a user's patterns and preferences -- but all
three have stopped following the release of OMB Watch's draft report.
(TechWire 27 Aug 1997; Edupage, 28 August 1997)


Hacking Risks, Paying for tracking you down

<Perillo@DOCKMASTER.NCSC.MIL>
Tue, 26 Aug 97 12:45 EDT
Wendell Dingus, a U.S. hacker, was sentenced by a Tennessee federal court in
late May to six months of home monitoring for violations of the amended 1986
Computer Fraud and Abuse Act.  Wendell Dingus admitted to a series of
attacks to gain unauthorized entry into U.S. Air Force and NASA computers
using a Vanderbilt University computer to obtain log-in passwords.

What is interesting about this case is that the damages to meet the $5,000
requirement of the Law were not based on the harm of the hacking, but based
on the cost of tracking and catching the hacker. The court ordered him to
pay $40,000 restitution to the Air Force Information Warfare Center (AFIWC,
San Antonio Tx) for their time and effort involved in tracking him.

According to Airmen at AFIWC, their not paid that much.  It also seems
strange that we are prosecuting people for computer crimes not based on the
damage that they may have caused, but based on the amount of time and money
it takes to track them down or fix the systems to prevent future
unauthorized entry?  When the police arrest a robber or burglar, they are
charged based on how much they stole, not on how much money, time, and
effort it took the police to catch them.

This may be caused by our failure to develop adequate risk models for
determining the true cost of an unauthorized computer access, or the correct
valuation of electronic content?

[Reference Secure Computing, Info Security News, July 1997,
 "Hacker Ordered to Pay $40,000 Restitution", page 19]

Robert J. Perillo, CCP       Richmond, VA      Perillo@dockmaster.ncsc.mil


Tcl 8.0 Y2K Risk

Lloyd Wood <L.Wood@surrey.ac.uk>
Tue, 26 Aug 1997 21:09:43 +0100 (BST)
Sun's scripting division has released Tcl 8.0, a fashionable bytecode
compiler reworking of the Tcl interpreter to help Tcl scale better.

Making it compilable required some changes in semantics, but there
were some other changes as well. In particular,

http://sunscript.sun.com/TclTkCore/8.0.html

Notes:

  There are also a few other minor incompatibilities in Tcl 8.0 and Tk 8.0:
  [..] 2.2-digit years are now parsed differently by the clock command to
  handle year 2000 issues better (years 00-38 are treated as 2000-2038
  instead of 1900-1938).

Supporting two-digit years in the first place was risky enough, but this
change is bound to catch a lot of people out.

It looks like the millennium problem may have come early for cutting-edge
Tcl scripters with legacy code.

<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641


Photocopier codes

"Marcus L. Rowland" <mrowland@ffutures.demon.co.uk>
Wed, 27 Aug 1997 07:50:25 +0100
I work in a school where the photocopier has a 5-digit key code; each
department has its own code, so that usage can be taken from the correct
budget. We probably have about 30 codes in use. In the course of time I've
had to do work for some other departments, and have been rather surprised to
learn that all of their codes begin with the same two digits, and that in
the _majority_ of cases it is possible to enter another department's code by
transposing two digits, omitting a digit, pressing the same digit twice
instead of once, etc. I also accidentally discovered that "99999" was a
valid but unused account, probably originally used for factory testing and
never closed. Since it wasn't supposed to exist it wasn't checked during the
billing process.

All of the department codes were apparently entered by a representative of
the copier company when the machine was supplied, and have never been
changed. The reason I've been given for leaving the codes unchanged is that
nobody would remember the new codes!

The risks here should be obvious; my department's copying costs last year
exceeded UKP 2000, and will be much higher this year because paper prices
have risen. The temptation to "accidentally" enter the wrong code is
sometimes very strong. In a business environment this form of cheating might
lead to another department's projects going over budget, with effects on
promotion etc. The manufacturers of these machines, and other coded devices,
should surely know that similar codes and unused accounts are likely to
cause problems, and instruct their installation personnel accordingly. And,
of course, sites should check these matters and change the codes
occasionally, not just leave everything to the manufacturers.

Marcus L. Rowland http://www.ffutures.demon.co.uk/


Oracle web server on Unix and passwords

Dawn Myfanwy Cohen <dcohen@paul.rutgers.edu>
Thu, 28 Aug 1997 10:34:33 -0400 (EDT)
Maybe I'm missing something because I'm kind of new to both Oracle and web
servers, but something strikes me as very wrong here.

When you install the Oracle web server on Unix, the installation guide goes
out of its way to tell you to set the umask to 022.  It then, somewhere
along the way sets up some configuration files which store some Oracle user
names and passwords in plain vanilla ASCII text.  These users correspond to
ones that own applications that should be run off the web server.  In
addition, the admin name and password for the web server itself are stored
in ASCII in these configuration files.  Depending on what exactly you are
doing with the server, your DBA name and password might also appear.

Seems kind of silly to me to go through all the contortions a DBMS goes
through to protect data only to have any old Unix user be able to get access
by just looking up some password.

You could argue that you should keep your database and Unix users on
different machines.  But first of all we don't have that luxury right now.
Second, to my knowledge there was no warning to that effect.  I don't have
time right now to experiment with seeing what breaks if I change the
protection of these files.

I guess the risks here are bad combinations of defaults ... default to store
passwords as ASCII ... default to store files as readable, etc.

--Dawn Cohen


Relying on systems maintenance taking place in another time zone

Olivier MJ Crepin-Leblond <ocl@gih.com>
Fri, 29 Aug 1997 13:43:39 +0100
The latest Network Solutions goof bumping NASDAQ off the net (Rodger,
RISKS-19.34) reminded me of Daniel Pouzzner's original post (RISKS-19.25)
describing the events when corrupted .COM and .NET DNS tables were released
at 2:30am EDT.

Obviously the idea behind releasing the files at 2:30am EDT is to minimise
the impact of updates on the geographically local network
population. Computer maintenance tasks are traditionally done at night for
that reason. The trouble with maintaining zone DNS files for the Internet is
that it's always 12 noon somewhere on the Net. So FOOBARS such as the one
described in RISKS-19.25 affected .COM and .NET users in Europe (morning
work) and Asia (daytime work) way more than in the US where most users were
asleep at that time).

It can therefore be argued that the fact that it took 4 hours before
corrected files were released, meant that European users lost 4 hours of
valuable daytime working time, while the error came-through virtually
unnoticed in the US. (apart from all of the e-mail bounces)

That's the RISK of relying on a system whose mission-critical maintenance
work takes place in another time zone.

Olivier MJ Crepin-Leblond, Ph.D. GIH Ltd, London, UK  http://www.gih.com


Re: Spelling-checker risks (Bird, RISKS-19.34)

Dave Katz <dkatz@juniper.net>
26 Aug 1997 23:33:17 -0700
The piece about "Semper Fi" being corrected to "Semi-pro fiddles" reminded
me of my favorite spell check faux pas.

One of the then-unique characteristics of MTS (the Michigan Terminal System,
a now-extinct o/s for IBM mainframes in the proud academic tradition) was
that it provided a spelling corrector using a Soundex variant--if you
accidentally typed "sigon", it would respond with, "Do you mean 'Signon'?"

After James Duderstadt was named President of the University of Michigan, it
was discovered that if you typed "Duderstadt", the system would respond, "Do
you mean 'dunderhead'?"  I believe it got a new dictionary entry shortly
thereafter.

Although there was no fallout in this particular case, it does underscore
the political risks of unchaperoned spell checkers.

  [Incidentally, several readers responded that it must have been the
  spelled-out "Semper fideles" that was corrected to "Semi-pro fiddles".
  I had assumed that was obvious from context, but apparently should have
  made it more explicit by editing the contribution and spelling it out!  PGN]


Mangled characters in text

"ET" <emergent@eval-apply.com>
Wed, 27 Aug 1997 09:41:33 -0400
In RISKS-19.33 and 19.34, I noticed the following text:

B&t.itN      [Barnes and Noble]
B&ytetN
AT&sglyT     [AT and T]

My guess is some interaction with some software in which ampersand is a
reserved character (like in HTML).  From context, it was easy to see that 4
apparently random characters were inserted after the ampersands in question.
I am curious to see what the second- and third-order mangling might produce.

  [Lots of systems and subsystems preempt commonly used characters.  PGN]


Re: SET Risks (Svigals, RISKS-19.31)

"Lewis, Tony" <tlewis@visa.com>
Mon, 25 Aug 1997 12:28:59 -0700
> The SET process claims to be better than using a credit card on the
> Internet.  However, the SET process has three serious exposures - confirmed
> with IBM and HP/Verifone.  The process does NOT know who is presenting the
> certificate.

The security of SET is based on the authentication that occurs before a
certificate is issued.  Once the cardholder has obtained the certificate,
the cardholder wallet will hold the certificate and the user's password
to the wallet prevents unauthorized access.

> The process does NOT know if merchant employees have
> redirected the certificate through another merchant.

SET payment instructions identify the merchant for whom they were created.
They cannot be redirected to another merchant.

> All of the critical software is directly accessible by the card users,
> merchant employees and bank employees.  Historically, these individuals
> have been the prime source of fraud in credit-card transaction systems.

SET is designed to prevent unauthorized parties from using payment cards
on the Internet.  It protects the transaction data as it flows between
computers.  There is no way that a transaction protocol can protect the
data from illicit use once it has arrived at its intended destination.

> There are more than 50 other card security products available for Internet
> usage.  They are generally simplier, faster, and avoid the SET exposures
> identified above.  Internet transaction users might try the viable
> alternatives.  jerome svigals, smartcard@sprynet.com

While I do not claim to have reviewed every possible means of payment on
the Internet, it is difficult to give any credibility to this claim.

1.  In order to know who is presenting a payment card, the system would need
a foolproof identity system.  Since no such system exists on a worldwide
basis, it is impossible for any of these 50 systems to overcome the first
exposure.

2.  In order to prevent merchant employees from redirecting transactions to
another merchant, the system would have to involve three parties in the
transaction: the cardholder, the merchant and a system to ensure that both
parties are doing business with whom they intend.  Any of these 50 systems
that only involve the cardholder and merchant cannot overcome the second
exposure.

3.  Any general-purpose card security product will have some aspect of the
software available on the user's computer.  Therefore, there is no way to
protect against access by the card user.  Further, unless the card processor
has changed their authorization and clearing systems, any Internet payment
system will continue to go through legacy systems at the acquirer and issuer
so there is no protection against access by the "bank" employees.  I do
expect it is likely that most card security products will protect against
unauthorized access to data by merchant employees, however, that will be
true whether the card security product implements SET or some other
protection mechanism.

In summary, SET does not attempt to address all of the issues raised by
jerome svigals, but his claim that every other product avoids the exposures
he described is questionable.

Tony Lewis (tlewis@visa.com), Chief Systems Architect, Internet Commerce
Visa International Service Association


Re: SET Risks (svigals, 19.34 & Sterling, 19.33)

<mpoole@uhea904.gb.ec.ps.net>
Wed, 27 Aug 1997 10:33:06 +0100 (BST)
The concept that Mondex is some sort of panacea for Internet commerce is one
of the more blatant pieces of hype I have yet seen in RISKS, and for one of
the simplest reasons: the number of PCs with smart-card readers.

Yet, SET appears to equally unsuited to the job, for the very reasons cited.

I keep getting the feeling that the only real money that will be made on
the Internet will that that reaped by the snake-oil merchants selling the
latest and greatest commerce system.

Martin Poole  mpoole@quatermass.gb.ec.ps.net


Intentional analysis, re: SET risks (Svigals, RISKS-19.34 et al)

Charlie Lane <CLane@iee.org>
Thu, 28 Aug 97 08:58:40 -0700
OK, lots of us are following the technical discussion about secure payment
with interest, but one aspect seems to be missing: the link to the (human)
intentions.

Here's the basic intention of a transaction: I want to make you a bit richer
(money in your account to spend) in return for you making me happier (giving
me something I want).

Now, notice that I'm not essentially concerned about who you are: the point
is that I do want to be assured that the person or organisation I am making
richer is the one that will provide me with a product.  It is the link
between product and payment that is the crux.

What I look for in a transaction is an assured offer of product for payment
(i.e., a validated advertisement) containing an assured route for payment
and an assurance that product will follow.

Unless those concerned with electronic payment tackle the whole intention
transaction from offer to receipt of product, the risks to the public will
remain.

(By the way, intentional analysis is also a big research topic in another
technical area: that of pre-analysing telecoms network services to discover
in advance any unwanted interactions, before large numbers of the public
start phoning help desks to complain.  If you can solve the intentional
analysis of transactions, you might be on the way to solving the wider
telecoms problem).

Charlie Lane


Re: USC 47:227 (Kabay, RISKS-19.34)

Duane Thompson <dst@netcom.com>
Thu, 28 Aug 1997 09:13:29 -0700 (PDT)
[...] My uninformed 2-cent comment:

My reading of USC 47:227 seems to support the argument that any unsolicited
e-mail is a violation of the section.  It defines "telephone facsimile
machine" as "equipment which has the capacity ...(B) to transcribe text or
images (or both) from an electronic signal received over a regular telephone
line onto paper."

My computer has that capacity.

Duane Thompson, Materials Management Solutions, Englewood, Colorado, USA
<a href="http://ourworld.compuserve.com/homepages/dst">http://ourworld.compuserve.com/homepages/dst   <dst@netcom.com>


Re: Public loo guilty of making nuisance calls

"Aaron M. Renn" <arenn@ix.netcom.com>
Tue, 26 Aug 1997 16:15:20 -0500
An interesting related incident.  We have a modem bank that sends faxes (not
junk, rest assured) out overnight in batch mode.  Well, during installation,
someone managed to wire two modems to the same circuit (or to cross some
wires or some such similar tragedy).  Since these modems needed do dial out
via a PBX, they had to dial "9" first.  For long distance, the next number
was a "1".  When two fax jobs kicked off at the same time, occasionally the
number sequence would end up as 9911, which dials 9 for an outside line,
then 911!  The police got called to this location every night and were not
amused.  This problem was not identified for quite some time because it was
assumed to be a software bug.  Just goes to show that our wire
infrastructure is not nearly as error free as we would like to think.

  [... A new twist on accidental 911 autodialing!  PGN]


Re: Tobacco Deal Could Set Precedent for Would-be Net Censors

"David T.S. Fraser" <fraserd@fox.nstn.ca>
Wed, 27 Aug 1997 15:04:22 -0300
It is important to remember that the deal reached among the various parties
in the tobacco settlement is, ultimately, a deal. As part of the give and
take of negotiation, the tobacco companies voluntarily agreed to this
restriction on their ability to advertise on the net. While it does have
precedential value for contracts and other settlements, it was not
arbitrarily imposed upon the tobacco companies by the government. A
settlement is merely a contract--voluntarily entered into--not to enforce a
claim in court. It is quite different, precedentially and constitutionally,
from a law prohibiting internet advertising of a particular product from a
foreign jurisdiction which is reachable from the jurisdiction in question.

David T.S. Fraser  Caledonia, NS, Canada  fraserd@fox.nstn.ca


Risks of believing the obvious, though impossible

Sam Lepore <lepore@dnai.com>
Wed, 27 Aug 1997 23:48:51 -0700
There is a risk in believing the obvious because it sounds scientific,
although it is impossible. This in turn can lead to a risk of believing
the impossible will provide you with a safety factor.

I read an article today about a solar study satellite launched into a
gravi-stationary orbit around the Earth at the point where Earth gravitation
and Sun gravitation are equalized - about 1 million miles out. The satellite
is to study solar winds, flares, and particle streams.

The article proclaimed the satellite would "give us a one hour warning of
solar storms that would otherwise not be available so sensitive ground
systems could be protected". It is obvious that the satellite will sense a
storm before it reaches Earth. But unless there is a "new physics" like
there is new math, the speed of light at which solar radiation travels is
relatively close to the speed of light at which radio emanations from the
satellite travel. So if the satellite senses a solar burst and radios its
finding, how is that signal going to get here an hour before the storm?

Oh, and at the commonly referenced speed of light, 1 million miles is
only about 6 seconds out.

Sam Lepore, San Francisco


Risks of believing the obvious, though impossible

RISKS List Owner <risko@csl.sri.com>
Thu, 28 Aug 97 14:14:34 PDT
Perhaps the physics are such that something in that remote environment can
more sensitively detect the early manifestations of the solar activity long
before we can from earth?


Risks of believing the obvious, though impossible

Sam Lepore <lepore@dnai.com>
Thu, 28 Aug 1997 22:41:57 -0700
Well, that would be the "obvious" part of my title.  Newspapers have a
way of reporting stories without detail so that only enough is explained
to make one think you understand.  I don't.

Sam Lepore, San Francisco


ICDCS-18 call for papers

Diego Latella <latella@cnuce.cnr.it>
Wed, 27 Aug 1997 15:09:00 +0200 (MET DST)
              CALL FOR PAPERS [excerpted for RISKS]
The 18th International Conference on Distributed Computing Systems
          Center of Mathematics and Computer Science (CWI)
                   Amsterdam, The Netherlands
                         26-29 May 1998

The purpose of this conference is to bring together developers and
researchers from universities, industry and government to advance the
science and technology in distributed computing.  The technical areas of the
conference include [many relevant to RISKS, including Mobile Systems,
Internet Applications, Interoperable Systems, Communication Protocols,
Fault Tolerance, Availability and Security, to name just a few.  PGN]

See http://infolabwww.kub.nl:2080/infolab/ .  Papers by 1 Oct 1997 to
Michael Papazoglou (M.P.Papazoglou@kub.nl), Tilburg Univ., INFOLAB, PO Box
90153, 5000 LE Tilburg, The Netherlands, Phone: +31-13-466-23-49/30-20
Fax: +31-13-466-30-69,

Please report problems with the web pages to the maintainer

Top