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 16

Saturday 17 May 1997

Contents

o Power outage crashes 1529 Bank of America ATMs
Mathew Lodge
o Poorly debugged new software results in $98,000 mistake
Tim Rushing
o More high-tech driver's license systems stolen
Gary Grossoehme
o On-line brokerage-trading passwords in plaintext
Cliff Helsel
o Security of Social Security Administration Database
John Pescatore
o Re: MD5 weakness and possible consequences
Wayne Mesard
Geoffrey Leeming
o The Year 65536 bug bites early!
Joshua M Bieber
o Re: ~2K
Bob Frankston
Peter B. Ladkin
o newmediagroup.com headers were forged in junk e-mailing; retaliation against my public anti-SPAM activities
Jim Youll
o Re: ACM lacks $50 -- or not...
James K. Huggins
Fred Cohen
o ``Electronic Democracy'' by Browning
Rob Slade
o Info on RISKS (comp.risks)

Power outage crashes 1529 Bank of America ATMs

Mathew Lodge <...@cisco.com>
Wed, 14 May 1997 13:28:30 -0700
Following the story in RISKS-19.13 (and its followup in RISKS 19.14), the
*San Francisco Chronicle*, 14 May 1997, carries a story about an unexpected
power outage due to human error.

Bank of America had the problem during ``routine maintenance on half of an
electrical substation the bank operates at a data processing center at
Market Street and South Van Ness in San Francisco, a worker accidentally
shut off power to the online unit.''

The supply was quickly restored, but ATMs were out of action for 2 hours as
the entire ATM network had to be rebooted. The article does not explain why
this had to happen. The result was that 1529 ATMs (all of Northern
California, approx 40% of Bank of America's ATMs) displayed ``Sorry this
Versateller ATM is temporarily unavailable.''

The system that allows bank tellers to access customer accounts held at
other branches was also down, so customers who were not at their own branch
couldn't even go into the bank to get money.

B of A is apparently investigating how one power failure can bring down the
entire Northern California ATM network...

Mathew Lodge, Product Manager, Cisco Systems, +1 408 527 4908

  [They should have been reading RISKS!  It would have been obvious.  PGN]


Poorly debugged new software results in $98,000 mistake

Tim Rushing <tim@rushing.com>
Thu, 15 May 1997 22:55:04 -0600
Over 3 years ago, Barry Lyn Stoller was mistakenly sent a refund check for
$98,002 for a $1.99 box of Ex-Lax.  Apparently, a buggy new software system
had used his ZIP code (98002, for Auburn, Washington) instead of the $1.99
amount.  Stoller deposited the check in his savings account, cleaned out the
account, and then disappeared for three years.  He was apprehended only
because a routine police check turned up the earlier warrant.  He has now
pleaded guilty to first-degree theft.  [Source: on-line edition
<http://www.seattletimes.com/extra/browse/html97/xlax_051597.html>]
of the *Seattle Times*, 15 May 1997, PGN Abstracting]


More high-tech driver's license systems stolen

<GaryG4430@aol.com>
Fri, 16 May 1997 15:05:31 -0400 (EDT)
Remember the five systems stolen from the Florida DMV? The ones that make
the ``Unforgeable'' licenses? (RISKS-18.94)  Well, now it's Oregon's turn...
(Note: Lake Oswego is a "high income" suburb of Portland.)

The Oregon Department of Motor Vehicles is now using a ``credit-card'' style
of license.  Over the weekend, burglars snatched more than $15,000 worth of
digital photo licensing equipment from the Lake Oswego Driver and Motor
Vehicle Services office, which was discovered Monday morning (12 May 1997).
The equipment included a computer, Polaroid printers, cables, a blue photo
background, and a Polaroid camera.  This is reportedly the first theft of
such equipment, and there are no suspects.  Dan Dlugonski, customer service
manager of the Lake Oswego DMV office, is quoted as follows: ``But even this
theft may not have given forgers the coup they hoped for.  One item which is
critical to the production of the new license is kept under lock and key
each night.  And the equipment that was stolen will not work unless it is
hooked into a special database.''  [Source: *Oregonian*, 15 May 1997, Metro
section, Cities and Suburbs. Lake Oswego]

Comment: Anyone want to guess, with the printer, camera, supplies, etc, but
no ``database'' what the probabilities are of someone being able to make a
driver's license that at least LOOKS right?  Now, if the ``print head'' of
the Polaroid printer is removable and locked away, maybe they got nothing.
(I hope that's a good safe!)  I suspect there will be more to follow.

Gary Grossoehme, Oregon Electronics

   [As we go, so goes Oswego.  PGN]


On-line brokerage-trading passwords in plaintext

chelsel <chelsel@spacelab.net>
Fri, 16 May 1997 11:25:08 -0400
A few months ago, I was using an on-line discount brokerage company E*Trade
To Do My Trading With.  Their Web site uses two passwords to control access,
one password controls access to account information, balances, stock quotes,
etc., the second password is used to confirm a trade.  Recently I had a
problem connecting with their site and needed to contact the company for
service.  As part of their telephone verification procedure, ie phone
number, address, mother's maiden name, etc., they ASKED for my logon
password.  After questioning the Customer Support person she said that they
can see my password on their screens.  I asked her if she also had my
trading password and she confirmed that she did by reading it back to me.
Needless to say I sold out my position with this brokerage firm and I'm
looking at using another brokerage service.

Cliff Helsel  chelsel@spacelab.net


Security of Social Security Administration Database

John Pescatore <johnp@tis.com>
Fri, 16 May 1997 08:56:38 -0400
I was asked by the SSA to be on a panel at their 6 May public forum in
Hartford, CT, the start of a 6-city tour to get public input on what to do
about making PEBES information available over the Internet.

Each public forum has three panels: privacy advocates, computer/technology
weenies, and commercial organizations.  The Hartford panel included Robert
Ellis Smith on the privacy panel; myself, Pete Troxel from IBM and others on
the computer weenie panel; and Lynn McNulty (now of RSA) and others from
Chase Manhattan, Pitney Bowes, and the Hartford insurance company on the
commercial panel.

We all pretty much told the SSA, and Congresswoman Kennelly (sp?) who
chaired this session, pretty much the same thing as PGN's
http://www.csl.sri.com/neumann/ssa.html says: making PEBES data available
over the Internet *can* be done securely, authentication is only part of the
issue, fraud detection needs to be used, it is a system level issue, an open
review is required, issuing PINs or passwords in an out of band manner would
be a good first step, etc.

I particularly pushed the open review issue, saying security through
obscurity is long dead.  The SSA has had computer security folks in prior to
turning interactive PEBES online, but it certainly wasn't an open review.

The uproar over PEBES is a little silly, since it only made it marginally
easier for fraud to happen, and in large part is the result of a widespread
fear of some form of National ID Card.  Senator Moynihan and Rep. Bill
McCollum, Republican of Florida, seem to be pushing turning the SSN into
such a form of national ID card, it has always been political suicide - ask
the US Postal Service.

Until the government implements a coherent strategy for US citizens using
strong authentication for obtaining electronic government services, the cost
of implementing those electronic services will always outweigh the savings.

John Pescatore
Trusted Information Systems             301-947-7153
15204 Omega Drive, 3rd floor            301-527-0482 (fax)
Rockville, MD  20850                    johnp@tis.com

  [For my SSA forum appearance in San Jose on 28 May, I added some caveats
  that may arise from relying on a public key infrastructure:
  http:/www.csl.sri.com/neumann/ssaforum.html]


Re: MD5 weakness and possible consequences (Koenig, RISKS-19.14)

Wayne Mesard <wmesard@engr.sgi.com>
Fri, 16 May 1997 16:16:03 -0400
> There is a chance that a malicious attacker can create two files with the
> same MD5 hash, if he can create both files.
> Consequences?  Yet another reson to distrust code signing.

The solution to this problem follows directly from the analogy to paper
documents.  In a gentler age, certified documents would be physically
altered by the stamp, seal or embossing mark of the authenticator.

I propose that when a digital document is certified, the certifier should
first make a small, random, benign change to the document, compute the
checksum on the *modified* document, and then sign that.

In executables, space could be left for this ``seal'' by compiling in an
otherwise unused data element (e.g., char sign_here[32] = "__sign_here__").
For interpreted documents, (including PostScript) an embedded comment can be
used.

Because the author won't know the document's checksum a priori, s/he won't
be able to construct its evil twin.

Wayne


Re: MD5 weakness and possible consequences (Re: RISKS-19.14)

Geoffrey Leeming <geoffrey@jcp.co.uk>
Fri, 16 May 1997 14:13:11 +0100
Thomas Koenig is correct about the weakness in MD5, but recent postings in
sci.crypt mention that he might be incorrect in the possible consequences.
The weakness essentially allows an attacker to create two files that would
have the same MD5 checksum, under very stringent conditions.  However, the
chances of finding two executable, meaningful pieces of code that would have
the same checksum are so low that it can be considered computationally
infeasible to do so.

A more plausible consequence is that two cryptographic keys are created that
have the same MD5 checksum.  Then any digital certificate for one key would
be valid for the second as well.


The Year 65536 bug bites early!

"Joshua M Bieber (852-5436)" <jbieber@VNET.IBM.COM>
Fri, 16 May 97 12:49:19 EDT
The IBM Mainframe comes with a support processor that has the ability to
load patches into the system.  The set of patches could be loaded either
manually or at a scheduled time in the future.  We provide the scheduled
capability so that the user can have the patch installed at a time when the
mainframe workload is light (such as the wee morning hours).

Some of the patches requires that the support processor gets rebooted (so
that it can install dynalink files that can't be installed while the support
processor is running).  When the patch is installed, it reboots again to
finish the patch process (update files, to re-activate the system) The patch
clean-up routine is invoked via scheduled operation which somehow knows that
there is a scheduled patch operation that must be started on the second
reboot and starts the patch cleanup routine and system activation.

The patch routine initially creates a scheduled operation to kick off the
clean up routine before starting the initial reboot.  Since a date and time
must be provided, the value was set to the first of the next month.  This
ensures that the scheduled operation won't be kicked off before the reboot.

Several years ago on a customer's machine, a patch took place via scheduled
operation.  Patch rebooted the system which installed the patch.  On the
second reboot, due to a bug that has nothing to do with either scheduled
operation or patch, scheduled operation patch handling routine was bypassed
and the patch never performed the clean up routine.  You guessed it.  On the
first of the following month scheduled operation kicked off the patch
cleanup which did its job and reactivated the system.  At the time it did
this (which was in the wee hours of the morning) the customer in question
happened to be working on the system and I won't describe the customer's
reaction at that time.

The patch routine was patched so that the date of the cleanup routine will
start on the 31st of December, FEFF (hex).  To explain, scheduled operation
has a beginning time window and end time window - since the end time window
was not specified, it defaults to 256 years later or FFFF (hex).  This way
if the patch cleanup routine happens to be inadvertently left behind, it
will remain stuck on the queue until long after we all retire if it doesn't
get cleaned up.

After this patch was carefully tested and made available to all of our
customers, we learned that some of our customers in Japan was no longer able
to have their code patched - either manually or automatically.  Upon further
analysis, we concluded that these customers configured their system using
local time instead of UTC.  So when patch created the scheduled operation,
it had a start window at Dec 31, FEFF, end window at Dec 31, FFFF.  One of
scheduled operation's job was to ensure that the end window is at a later
time than the start window, otherwise scheduled operation is rejected.  But,
before this date comparison was made, Scheduled Operations converted the
local time to UTC.  By adding a few hours, the start window became Jan 1st,
FF00 and the end window - you guessed it - Jan 1st, 0000.  Unable to verify
that year 0000 > FF00, it rejected the request and thus the patch was unable
to do its job.  Our solution was to change the start window to Dec 25, FEFF
and plan our retirement a week earlier.

Josh Bieber, Support Processor Console Functions Microcode, Department G41
Office 250-1M003, Glendale Lab - Endicott, NY


Re: ~2K

"Bob Frankston" <bobf@Frankston.com>
Thu, 15 May 1997 12:38 -0400
As if we didn't have enough problems, we don't know when the year 2000
starts.  Even more of a problem for the year 2000.  It all depends upon how
many dams we build, what the whether is and all the other functions that
reflect the rotation of the Earth.

The culprit is the leap second.  Not a big deal if our watches are off by a
second or so once in a while -- they are rarely that accurate.  A very big
deal for those who depend on the most minute positioning of the stars
relative to the Earth.

But computers are caught in the middle since they must convert between
representations and there is simply no way to convert between future years
and the number of seconds since a base date because the leap second is
based on unknown events in the future.

It's as if the inch were based on the length of the current King's thumb.
Hard to write real estate deeds using such a measure.

The solution is very obvious.  Just stop this silliness about leap seconds.
Of course, astronomers will need to keep their correction factor but they
care enough to do it.  The rest of us can easily live a small error.  I'm
not worried about being a day off in the year 100K.

Is this a real problem? Assuming I'm correct about the definition of time
conversions, the answer is yes.  You simply can't write a program that
compares two converted representations of a year.  Technically because you
can't do the conversion repeatably and pragmatically because I don't know of
real conversion routines that have the necessary leap second tables anyway.
Worse if a few actually do.

And one is allowed to write:
  Date CurrentDate;
  same = Date("Jan 1, 2000") == CurrentDate.
This is the proper way to write the code and the == operator is not
supposed to know ``Oh, it's a year comparison, I can fudge it.''


Re: ~2K (Frankston, RISKS-19.16)

"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>
Thu, 15 May 1997 21:30:14 +0200
Bob Frankston effectively suggests running Internet (or Intranet) machines
on TAI.  Both TAI and UTC are based on the same second standard - the
difference is just leap seconds, which, as he notes, is dependent on human
decision rather than an algorithm.  The current NTP (Network Time Protocol)
is a distributed adaptive algorithm for clock synchronisation based on a
server hierarchy: one obtains the time from three servers with short
transmission delays (measured experimentally and adaptively) and uses
continuous adaptation to improve synchronisation of the local clock time
with that distributed by the servers. The servers are `stratified' according
to quality.  For example, the Stratum 1 servers in Erlangen and Osnabrueck
in Germany get the time from the PTB radio standard UTC clock broadcast from
Frankfurt; Stratum 2 servers will use these as sync sources, etc on down.

So the first disadvantage of Bob's suggestion is that we'd need to know
leap-second history in order to synchronise our nets to TAI, rather than
letting leaping tocs [tics?] lie.  But, he may point out, at least we only
have to know the past rather than divine the future the same way as
Parisians.  A second disadvantage to his suggestions is that there's no
technical reason why GPS should not soon become part of the Internet, when
we all have pocket servers/browsers/mailers/videoplayers and we're running
IP addresses through satellites.  So we'll be bound to UTC.  And of course
anyone who wants or needs to can recalculate TAI from UTC.  But he does make
a case for using both, or at least being more careful with algorithms
relying on time calculations.

There are certain physical limits to what can be done in the way of
synchronisation.  I have just learned from Ben Torrey
(reuben.g.torrey@ac.com) that from what he understands, due to the effects
of gravity as predicted by Einstein's GenRel, the atomic clock in Denver, a
mile high in the Rockies, runs a few microseconds per year slower than the
one in London, i.e., real physical processes run that much slower.  He
suggests that may have some consequences for the local lifestyle.  Indeed so
- as has been known to Californians for some decades, the higher you are,
the slower you move......

Peter Ladkin, Universitaet Bielefeld, Postfach 10 01 31, D-33501, Bielefeld,
Germany  http://www.rvs.uni-bielefeld.de  +49(0)521 106-5326/5325/2952


newmediagroup.com headers were forged in junk e-mailing;

Jim Youll <jim@newmediagroup.com>
Thu, 15 May 1997 20:01:52 -0400
         retaliation against my public anti-SPAM activities

We are a very small company.  We are being attacked electronically, because
of my public anti-spam stance:

(A) Our server was subjected to an inbound bombing from the hijacked
servers into our mailserver last night (14 May 1997).

(B) Thousands of messages were sent OUT today (15 May) from the same
hijacked servers, resulting in a torrent of complaining, hostile, violent
mail to our mailboxes.  Some people began to mailbomb us with large
documents.

I have 99.9% confidence that the hostile messages were injected into the net
from a computer dialed into enterprise.net, a UK ISP, and have the
corroborating records to prove it, at least everything I can get without
cooperation from enterprise.net.  I am unable to reach anyone at
enterprise.net who will assist in this investigation.

The messages were relayed off nevwest.com and freenet.carleton.ca SMTP servers.

The administrators at these sites have not been terribly supportive, though
they claim to be working on it.  They have also received quite a bit of
inbound mail, but appear somewhat unsure about what to do or ``how that
happened''.  They've asked me if *I* sent the messages.

Complete details of the attack and my anti-junkmail posting which started
all this appear here:
    http://www.agentzero.com/junkmail

The message I have sent out follows.  I need support from the UK.  I am
prepared to do whatever it takes to get a prosecution.

-- quoted message follows --

My domain newmediagroup.com is under attack by someone who doesn't like my
MILITANT, PUBLIC ANTI-SPAM stance.  To date, their actions have included
sending apparently several thousand e-mail messages, forged showing my name
as the sender.  In addition, this same party or someone working with them
conducted a denial-of-service attack on our system last night, 14 May.  See
http://www.agentzero.com/junkmail, including system logs clearly showing the
terrorists' use of third-party unsecured SMTP servers as relays (which you
will also see by looking at the headers of the messages that were sent).

Their attack has also included threats of harm against me.

PLEASE let people know this did not originate at newmediagroup.com.  It is a
complete forgery.  We are TRYING to investigate and at the moment have a
number of backbone carriers and MCI security, involved.  I am doing all I
can.  PLEASE tell people to stop writing to complain.  This did not come
from us.  We don't spam.  I am FIGHTING spam and that is why I was targeted
in this manner.  When you see their mail-bomb messages to me, you will
understand.

I am seeking cooperation from the sites that were used as relays.  Sheila,
apparently an administrator at freenet.carleton.ca. (office@ is their e-mail
address; if you have received junk that bounced off their mailer, I STRONGLY
suggest you contact them and demand the holes be closed.)  Carleton Freenet
has notified me (15 May 1997, 1600 EDT by e-mail) that they will not release
their SMTP logs, which would show the origin of the message injected into
their mailer.  A man reached at nevwest.com said he had ``one technician
working on it'' but really didn't understand the specifics, and was not very
excited about helping.  This is all very exciting for electronic terrorists,
I am sure.

New Media Group (and I in particular!) do not send or generate commercial
e-mail.  Ever.  We are a small Internet presence provider working closely
and on-site with clients in the Midwestern US.  Only.  We do not seek,
service, or advertise to anyone outside that area, and we do not use e-mail
for advertising.

Copies of all logs and the threatening messages which came here have been
forwarded to security officers at all ISPs we could identify, and at the
security offices of backbone providers involved in this.  We're trying, but
it will be difficult to identify who did this.  We're trying.  I fully
intend to press criminal and civil charges at the very moment an indictment
becomes feasible.

The reason we have been targeted is that I (personally, not this company)
have been leading a campaign AGAINST junk e-mail.  Please help me find out
who did this.

If you look at the headers, you will see that the messages did not come from
here.  The incoming messages threatened more attacks unless I stop my
campaign to free people from unwanted junk e-mail.  This is terrorism, plain
and simple and I call on the entire Internet community to help track down
the responsible parties.  I will appreciate any assistance you can provide.

I am offering a reward of $1,000 for information leading to the arrest and
conviction of the perpetrators of this crime.

NOTE ADDED 16 May 1997:

We were hit again overnight 15 to 16 May.  This time messages were sent to
many addresses in the U.S.  Primarily the incoming has been bouncing due to
bogus or no-longer-in-use names at these locations.  The nature of the
addressing suggests that the names were culled from newsgroups and other
public sources, and that the system doing the gathering went back some
distance in time to get them, as many were expired.

... It's been a busy couple of days.  We have received approximately 2,500
undeliverable messages in the last few hours.  (Normal is 20-50 per day.)
The incoming complaints and attacks are slowing, because I think people are
learning that jim@newmediagroup.com is ANTI-junk.  Word is getting out, and
hopefully that will help in the future.


Re: ACM lacks $50 -- or not... (RISKS-19.15)

James K. Huggins <huggins@eecs.umich.edu>
15 May 1997 17:48:29 -0400
Actually, InterNIC lists two reasons for a domain status to be on hold
(besides an official delete request): non-payment and lack of name service
(see http://rs.internic.net/support/tele/domain-delete-domain.html).  (I
think disputes over a domain name might cause a hold as well.)

A representative from InterNIC said that they don't release the reason for
putting a domain on-hold to third parties.  A representative at ACM member
services whom I called (since I, too, rely on the service) stated that the
problem was with their ISP.  So it's entirely possible that the name server
that serves acm.org failed and InterNIC detected the failure.  In any event,
the problem was resolved within 24 hours.

Jim Huggins (huggins@umich.edu / huggins@acm.org)


Re: ACM lacks $50 -- or not... (RISKS-19.15)

Fred Cohen <fc@ca.sandia.gov>
Fri, 16 May 1997 10:59:27 -0700 (PDT)
I would bet that it's the InterNIC - given my experience with them. ...

We moved in mid-1996 from Ohio to California, changed the corporate name,
got new phone numbers, etc., but, we wanted to keep our Internet domain name
(all.net).  To make a long story short, it took them almost a year to update
our information, and they only did it after we repeatedly refused to pay
them their fee (we were 8 months or so late by this point) until we got a
paper copy of the bill (which they were sending off into the ether
somewhere).  They also used a wrong credit card number (despite reading it
back to me correctly, they couldn't manage to submit it correctly), it took
them several hours to get to someone at their site who could tell me that
they couldn't change our InterNIC information unless they got e-mail from
our site (which is impossible, unless you forge e-mail, when your site is
off the air because they have terminated their services).  Their automated
mail-bots can't handle replies correctly, and there doesn't seem to be a
process for escalating to a human being.  Eventually, I was able to get the
problem partially corrected, but it shouldn't take 30 phone calls, 15 e-mail
messages, and nearly a year to change an address so they can get paid $50.

I, for one, am in favor of alternative InterNICs.  Let's make this a
competitive industry and see if they can survive with this shoddy business
practice in the real world.

Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225


"Electronic Democracy" by Browning

"Rob Slade" <roberts@mukluk.hq.decus.ca>
Fri, 16 May 1997 10:35:51 EST
BKELCDEM.RVW   961210

``Electronic Democracy'', Graeme Browning, 1996, 0-910965-20-X, U$19.95
%A  Graeme Browning brow@clark.net
%C  462 Danbury Road, Wilton, CT   06897-2126
%D  1996
%G  0-910965-20-X
%I  Pemberton Press Books/Online Inc.
%O  U$19.95 +1-800-248-8466 203-761-1466 fax: +1-203-761-1444 online@well.com
%P  200
%T  ``Electronic Democracy: Using the Internet to Influence American Politics''

Maxwell's "How to Access the Federal Government on the Internet" (cf.
BKHAFGOI.RVW) tells what your (US) government can do for you.  Casey's "The
Hill on the Net" (cf. BKHILNET.RVW) is a kind of personal memoir of
exploration of the use of technology among politicians.  Browning here
provides the basics, background and case studies for grassroots use of the
net to affect and influence the political process.

The first three chapters contain anecdotal accounts of specific political
events that have been influenced by net-based activities.  This is readable,
interesting, and even informative, but many similar works go no further.
Browning proceeds to advise on acceptable tactics on the net, as well as the
potential downside to political use of the Internet.  There is a brief look
at some related technologies, and a set of resources (which the author
admits are personally selected and not exhaustive).

A realistic, useful, and balanced guide.

copyright Robert M. Slade, 1997   BKELCDEM.RVW   961210
roberts@decus.ca  rslade@vcn.bc.ca  rslade@vanisl.decus.ca

Please report problems with the web pages to the maintainer