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 20 Issue 2

Saturday 3 October 1998

Contents

o Risks of Upgrades: Florida fingerprint system
Charles P Schultz
o Bank error delays 50,000 Ontario social assistance payments
Mark Brader
o More --possibly unpublished-- banking/credit card failures
Luc Bauwens
o Attack on blood databases was simulated
Dorothy Denning
o JavaScript Flaw in Netscape
Edupage
o Not all outages are bugs: taxi credit
George Michaelson
o Y2K police planning
Alex Klaus
o Re: Win NT C2 Certification
pchallin
o Education and other undesirable numbers
David Collier-Brown
o Less sinister reason for Disney link in porn site
Andrew Klossner
o Re: Sexy risks of searching for MP3
Michael Smith
o Re: Y2K risk in Netscape cookies
Jay Ball
o Re: How to bypass those pesky firewalls
Brad Ackerman
Phillip C. Reed
Chris DeLashmutt
o Information Security Educators Mailing List
Fred Cohen
o Info on RISKS (comp.risks)

Risks of Upgrades: Florida fingerprint system

CharlesP Schultz-ECS013 <CharlesP_Schultz-ECS013@email.mot.com>
Thu, 1 Oct 1998 18:10:11 -0500
Computer Glitch Ties Up Crime Probes
from *The Palm Beach Post*, 1 Oct 1998,
Monika Gonzalez, Palm Beach Post Staff Writer

This article reports that "dozens of crimes in Palm Beach County could be
going unsolved because the sheriff's computers can't compare fingerprints
found at crime scenes with those of criminals arrested in other parts of the
state."

The problem is a software compatibility problem that was caused by upgrades
made to the network of state and local fingerprint computers know as AFIS -
Automated Fingerprint Identification System. In 1996, the Palm Beach County
Sheriff's Office and the Florida Department of Law Enforcement both decided
to upgrade. Palm Beach finished their upgrade first, in October, 1996,
expecting to be compatible with the state's system about six months after
that.  However, the state upgraded their system beyond the capabilities of
the county's upgrade, making them incompatible, and they remain so to this
day.  Mark McDonald, Palm Beach County AFIS Supervisor "hopes" the two
systems can be compatible by January, 1999 after upgrading his system
again. (This should give them about a year of full operation before the Y2K
bug hits them!  - but I digress...)

Losses:
Palm Beach County was getting two to three fingerprint matches a month from
the state system. This comes to 48-72 cases that might be closed by now (2
years since October, 1996). Some of these matches may be discovered once the
systems are linked again, but the statute of limitations may have run out on
some of the crimes in question. Also, any belongings or evidence that might
have been recovered because of a timely fingerprint match may be lost. This
is exacerbated by the fact that Palm Beach County estimates it will take
another year to process the fingerprint backlog.

Lessons:
1) Plan and coordinate your upgrades carefully
2) Come to Palm Beach County to commit your crimes before they can trace
your fingerprints!

Charles P. Schultz <ecs013@email.mot.com>


Bank error delays 50,000 Ontario social assistance payments

Mark Brader <msb@sq.com>
Thu, 1 Oct 98 07:18:43 EDT
It isn't only Bank of Montreal customers who've been having trouble this
week.  Yesterday 50,000 Ontario social assistance (welfare) recipients who
receive this payment by direct deposit to their Toronto-Dominion (TD) Bank
accounts ... didn't.

This was the result of an error the day before.  The Royal Bank of Canada
actually deals with the provincial government on this, and they had prepared
as usual a file of 50,000 deposits to transmit to the TD Bank at 4:30 pm the
day before.  However, this time the date codes on the file were wrong.

Someone at the Royal Bank soon noticed the error and called the TD Bank to
notify them to expect a corrected file.  This was transmitted, still in good
time to be processed overnight as usual, but according to today's Toronto
Star, "a technician forgot to manually let the computer know that a new file
was in place."

The victims, of course, were precisely those people least able to cope with
even a 24-hour delay in payment.  They were basically thrown on the mercy of
their individual branch staff, who might, or might not, issue emergency
advances or provide overdraft protection.

The TD Bank is the fifth-largest in Canada; the Royal Bank is the largest.

--Mark Brader <msb@sq.com>


More --possibly unpublished-- banking/credit card failures

"Luc Bauwens" <bauwens@ucalgary.ca>
Fri, 2 Oct 98 9:00:03 MDT
Apparently, on 16 Sep 1998, the entire Diner's Club authentication system in
Belgium was off the air.  (I tried using mine unsuccessfully that day, and I
heard from another store, just before leaving on the following day, that
indeed, their whole network had been out that day for most of the day.)

Then, back to Canada, on 30 Sep I received the following e-mail from our
payroll people:

"We have been advised that there has been a failure in the transmission of
payroll deposit data between the Royal Bank and the Toronto Dominion Bank.
The result is that the U of C employees who are TD Bank customers did not
have their funds deposited this morning.  Our information is that the bank
is moving quickly to resolve this problem and that the funds will be
deposited no later than tomorrow morning.  If you have any concerns, please
contact your bank."

One wonders how common these types of occurrences are?  And how often
they remain unpublished?

Luc Bauwens, The University of Calgary, Mechanical and Manufacturing Eng.
Calgary AB T2N 1N4 Canada 1-403-220-5792 http://www.acs.ucalgary.ca/~bauwens


Attack on blood databases was simulated (Re: RISKS-19.97)

Dorothy Denning <denning@cs.georgetown.edu>
Fri, 2 Oct 1998 09:13:21 -0400
[(Correcting the record on Bob Brewin's previous article in *Federal
Computer Week*, cited incompletely in RISKS-19.97,) PGN]
According to a 30 Sep 1998 article by Bob Brewin in *Federal Computer Week*,
the attacks on DoD medical databases previously described were simulated as
part of a read team exercise.  A Pentagon spokeswoman told FCW that the
exercise was designed to "demonstrate potential impacts...if personnel
records, such as medical records with information on blood types of military
members, were the subject of hacker attacks."  The woman said that "No
records were electronically altered'' during the exercise.  Even then, the
exercise was against an incomplete demonstration model of DOD's Defense
Blood Standard System, which had been placed on the Web so that DOD users
could look at the new system.  In practice, the hospitals are said to
operate stand-alone systems that are not connected to the Internet.

  http://www.fcw.com/pubs/fcw/1998/0921/web-blood-9-22-98.html

Dorothy Denning


JavaScript Flaw in Netscape (Edupage)

Edupage Editors <educause@educause.unc.edu>
Tue, 29 Sep 1998
A computer consultant has identified a flaw in the Netscape browser that
would allow a malicious programmer using JavaScript to read the contents of
another user's cache (the temporary storage on a computer's hard drive), and
thereby get access to the user's files.  However, encrypted information,
including credit card numbers, would not be vulnerable from this flaw,
because they are not stored in cache.  Emphasizing that the flaw is
hypothetical and that no one has reported being affected by it so far, a
Netscape executive says the company is taking immediate steps to verify and
fix the problem.  Industry analyst Stan Dolberg says that the next 18 to 24
months will amount to a normal "shakedown cruise" for e-commerce, and that
"this kind of stress-testing is going to discover all kinds of flaws...
Today, in and of itself, this particular flaw is not earthshattering." (*USA
Today*, 28 Sep 1998; Edupage, 29 Sep 1998)


Not all outages are bugs: taxi credit

George Michaelson <ggm@dstc.edu.au>
Fri, 2 Oct 1998 16:51:56 +1000 (EST)
Lately, local taxis using automatic ATM cardswipe have been falling back on
manual payment. After the 20th time, I asked why, assuming it was bad
reception which was known to plague the system early on.  It turns out the
taxi agency has given the card-processing agency 6 weeks to settle on card
transactions. The drivers can convert paper-processed cards into cash
immediately, at a small discount (they trade like funny money among the
drivers, and small-shop owners and petrol stations) and really dislike having
a 6 week wait for settlement on the electronic funds transfer. Plus, the
cards incur a 3% process fee so the agency wins twice: once on the
processing fee, once on the interest earned putting the money in play for a
month or so.

I think this is a social RISK.  The engineering decision to go cashless is
fine, but the greedhead outcomes defeat things. Its still slow, its still
manual, but the drivers just *prefer* it.

-George


Y2K police planning

Alex Klaus <alex.klaus@sympatico.ca>
Sat, 03 Oct 1998 10:28:07 -0400
The *Ottawa Citizen* (03 Oct 1998) reports that the RCMP has banned
vacations for its 15,000 officers and 2,400 civilian members from Dec., 27,
1999 to March, 1, 2000. According to Dave Morreau, who heads the RCMP's Y2K
project the length of the ban was determined by the need to include " ...
all the dates that computer experts say ill prepared computer systems would
be likely to crash or malfunction."  For its part, "...  the force has
already fixed and tested about 90 per cent of its systems ... "  notes
Morreau. Additionally the article also reports RCMP attempts to create an
accurate picture of any potential Y2K problems are hindered by " ... many
businesses and utilities ... reluctant to discuss whether their systems have
been fixed for fear of facing [customer]lawsuits ..."  In a memo to the
force, Commissioner Murray noted the situation may be like last January's
Ice Storm, which affected Eastern Ontario and Quebec with power outages
etc. Though Murray does not expect problems throughout the whole period but
" ... problems probably of a limited duration may occur." The last time such
such an ban was issued the article notes, was during the Pope's 1984
Canadian visit.  The full text of the article can be found at
http://www.ottawacitizen.com/national/981003/1910271.html

[Though other police forces probably have these contingency plans in
effect, it is interesting to see how the Y2K bug is becoming noticed in
all quarters now.]


Re: Win NT C2 Certification

<pchallin@bama.com>
Fri, 2 Oct 1998 10:22:17 -0500
I got the following from Paul Thurrott's "Wininfo" dlist for Oct 1, 1998 (
http://www.wugnet.com/wininfo)  regarding Windows NT C2 Certification

Quoting<>>

An update on Windows NT 4.0 and the C2 evaluation

Last week, I got a tremendous amount of information about C2 from various
WinInfo readers and, originally, I had intended to publish most of it. But I
just received an interesting post from Frank Mayer, of Science Applications
Internal Corporation (SAIC), the company that Microsoft has contracted to
get Windows NT 4.0 evaluated for the C2 rating. Frank is a a long-standing
and well-respected member of the security community, which is one of the
reasons SAIC was chosen to work with Microsoft on the NT 4.0 evaluation. I
think I'll just present his own description of the status of Windows NT and
C2, since he does sum it up quite nicely and probably understands the
process better than most.

Here it is, only slightly edited for formatting.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

There appears to be much confusion with regard to Windows NT and the status
of its C2 evaluation.  I'll attempt to set the record straight with the
facts. My background with this topic runs from early in the evaluation
efforts in 1992, where as a department director at The Aerospace
Corporation, a federally funded research corporation, I was a member of the
government C2 evaluation team for the original Windows NT evaluation, to
today, where my organization at SAIC is conducting the current C2
evaluation.

Windows NT 3.5 was awarded a C2 rating in July 1995 (See this Web page:
http://www.radium.ncsc.mil/tpep/epl/entries/CSC-EPL-95-003.html). This was a
stand-alone evaluation (i.e. no networking was evaluated). The C2
configuration did require some permissions within the file system and
Registry to be changed from their out-of-the-box defaults (it is well known
that the default permission settings in Windows NT are not conservative from
a security perspective).  Other configuration and Registry settings were
also included as part of this evaluation, some optional (e.g., crash on
audit full) some not (e.g., "allocated" floppy and CD drive to interactive
user).  This is not atypical for C2 evaluated configurations.

As the Windows NT 3.5 evaluation was closing, discussions and planning
between Microsoft and the government for a networked Windows NT 3.51 (later
4.0) evaluation were taking place.  A team leader was assigned and a team
formed.  At this point (early 1996), I left Aerospace for SAIC and so had
no direct knowledge for the next 9 months or so.  In late 1996, SAIC and
Microsoft began discussions about SAIC helping Microsoft move forward with
the C2 evaluation of Windows NT 4.0.

In the summer of 1997, SAIC and Microsoft signed an agreement whereby SAIC
would help Microsoft re-start the C2 evaluation efforts for Windows NT 4.0
(See http://www.cist.saic.com/nt.html). Originally, we were to help
Microsoft work with a government evaluation team to facilitate the
evaluation.  In early 1998, we transitioned the effort into an SAIC-staffed
evaluation team under a government program that is commercializing the
product evaluation program (See
http://www.radium.ncsc.mil/tpep/ttap/index.html).

Our evaluation team has been working closely with Microsoft all year. A
major milestone for this evaluation, the first of two government technical
review boards (TRBs), will occur 29-30 September 1998.  This TRB is NOT the
point at which a "pass or fail" decision is made; rather it is intended to
"ensure that the evaluation team has performed sufficient analysis of the
product design" (See the "IPAR/Test Technical Review Board Meeting" section
at http://www.radium.ncsc.mil/tpep/ttap/Process.html). So it is indeed true
that Windows NT 4.0 has not completed a C2 evaluation for a network
configuration.  However, it is also true that significant effort is actively
being directed towards that end, and the evaluation is well into the
evaluation process.  The targeted evaluation version (subject to changes) is
Windows NT 4.0 with Service Pack 4 in a closed network configuration.

Finally, I'd like comment on C2. A "product" evaluation is a fairly in-depth
(by today's standard) analysis of an operating system (or other type of
technology) against a standard (e.g., C2).  The C2 requirements are entirely
contained on 3 pages of text.  It takes a lot of interpretation and analysis
to asses compliance of something as complex as an operating system with
something as simple as 3 pages of technical requirements.  In order to keep
the evaluation process tractable, an "evaluated configuration" is defined
that scopes the evaluation effort.  Rarely if ever would a C2 evaluated
product be "rated" with all the functionality supported by that product or
in its default configuration. This is OK and, I'll assert, even good.
Because what a C2 product evaluation is intended to provide is assurance
that, for the "evaluated configuration," a standard set of security features
(e.g., access and security auditing) at a standard level of assurance (e.g.,
internal design analysis and security functional testing) is assessed by an
independent third party at a level of detail more than product consumers
could afford.  A user/integrator would then take that product, understand
it's "evaluated configuration," and use that as a starting point for
building a secure system.  Certainly everyone deviates from evaluated
configurations.  However, now they have the opportunity to start from an
established and evaluated starting point.

Frank Mayer (mayerf@saic.com), Center for Information Security Technology,
Science Applications Internal Corporation

end quote <><><><>>

  [By TODAY's standards, the Orange Book C2 criteria are extremely minimal,
  and a C2 evaluation should not be overendowed in any case.  Indeed, the
  entire Orange Book evaluation criteria and the ensuing Rainbow series
  interpretations leave many opportunities for vulnerabilities.  For
  example, the Orange book says almost nothing about networking, which was
  relegated incompletely to the Red Book.  For a discussion of some of the
  limitations, see my paper, Rainbows and Arrows: How the Security Criteria
  Address Computer Misuse ["Do Not" might appropriately have prefaced
  "Address" in the title], in the Proceedings of the 1990 NSA/NIST National
  Security Conference, and a later paper by Willis Ware, A Retrospective of
  the Criteria Movement, in the 1995 incarnation of the same conference.  PGN]


Education and other undesirable numbers

David Collier-Brown <davecb@Canada.Sun.COM>
Fri, 02 Oct 1998 14:56:59 -0400
In a discussion of the Ontario education number (briefly mentioned
in RISKS-19.48), a quite unexpected risk raised its head.

A colleague had noted that ``the assignment of a number and collection of
data can proceed without having to inform you'', which is a risk in itself,
and speculated that a government might wish to apply an education number to
anyone, to serve as the government's universal citizen identifier.

Alas, this turns out to be more than mere speculation: in Ontario, there is
no particular interests in ever retiring any issued number: they persist
until the digits roll over to 0000000000 again.

This implies that any Ontario identifying number will be for life, and that
universal ones like education numbers will be attached to all citizens
within a generation, and finally that there will be no clashes with another
person within one's lifetime.

No additional impropriety by a government is needed: all the components are
already present.

    You <I>will</I> be given a universal citizen identifier.
    It may be used for any purpose mentioned in the statute
        or in regulations subsequently made under it.
    It will not be subject to the Protection of Privacy act, and
    The information to be collected will be ``personal information''
        which is defined to include such things as sexual
        orientation and political beliefs.

There is no particular reason to believe that Ontario is the only
jurisdiction with numbers which persist in this manner, or with weak
controls.

David Collier-Brown, 185 Ellerslie Ave., Willowdale, Ontario N2M 1Y3 CANADA
1-416-223-8968 | http://java.science.yorku.ca/~davecb  davecb@hobbes.ss.org


Less sinister reason for Disney link in porn site

Andrew Klossner <andrew@user2.teleport.com>
Fri, 02 Oct 1998 10:23:25 -0700
I believe the links to www.disney.com in porn web sites are for the opt-out
doors.  The usual first page presents buttons labeled "I am an adult, let me
in" and "I don't want to see porn."  Clicking the latter takes you to
Disney's page.  I think the resulting appearance of these sites, when
searching for "disney," is unintended.

Andrew Klossner (andrew@teleport.com)


Re: Sexy risks of searching for MP3 (Byrd, RISKS-20.01)

Michael Smith <emmenjay@zip.com.au>
Sat, 03 Oct 1998 22:25:31 +1100
>[...] Actually, the Web-search companies are well aware of unscrupulous
>Webmasters trying to manipulate their search systems, and they have been
>taking countermeasures for quite a while.

There seems to have been an improvement here.  Around 12 months ago, while
doing some research I did a search on www.altavista.com for someone who is
widely known in Australia.  The search results consisted almost entirely of
unrelated pornography sites.  Having read Don Byrd's article, I just
repeated the search on www.altavista.com and www.excite.com and in the top
20 hits for each, there wasn't one irrelevant hit.  (I didn't look past the
top 20).

Michael Smith, Emmenjay Consulting Pty Ltd  http://www.zip.com.au/~emmenjay/
emmenjay@zip.com.au
  [Contribution edited by PGN]


Re: Y2K risk in Netscape cookies (Seymour, RISKS-20.01)

jay ball <jay@invengen.com>
Fri, 02 Oct 1998 09:38:35 -0400
> The Netscape cookies specification ...
>     Wdy, DD-Mon-YY HH:MM:SS GMT

Well, in http://home.netscape.com/newsref/std/cookie_spec.html, the
official cookie standard says: Wdy, DD-Mon-YYYY HH:MM:SS GMT.  the url
which you referred is the 'how to implement cookies with java script'
page.  i'll trust the standard.

i trust the standard to all ends, even the examples at the bottom of the
page, with the demo of "09-Nov-99".

consistency.

jay ball  http://www.invengen.com  [one of several contributions...   PGN]


Re: How to bypass those pesky firewalls (Jackson, RISKS-20.01)

Brad Ackerman <bsa3@cornell.edu>
Fri, 2 Oct 1998 00:24:24 -0400 (EDT)
Turns out it's just checking for a recent version of Netscrape or Internet
Exploder.  The applet liked the Power Macintosh G3 I'm typing this on once
I downloaded the former.

In bloating the applet to qualify for the Intel program, United Media went a
bit too far -- I'd call the minimum recommended platform an RS/6000 SP
POWER2SC wide node, and I wish I were exaggerating.  I'd recommend two
towers of them (16 nodes) with the high-performance switch, but AFAIK no JVM
would know how to distribute the processor load over multiple nodes.

The RISK of this sort of thing is crummy Java applets and other bloatware
monopolizing USD 2e5+ computer equipment.  Our interactive login nodes are
crowded enough as is! [Yeah, there are processor quotas, but they can take a
few days to update -- the system really doesn't protect all that well
against UHF bogon emitters.]

Brad Ackerman, Cornell Theory Center


Re: How to bypass those pesky firewalls (Jackson, RISKS-20.01)

"Phillip C. Reed" <reedpc@libbey.com>
Fri, 02 Oct 1998 08:02:51 -0400
I have to say that it's a poorly designed security structure that can be
bypassed by doing ANYTHING to an inside client. If somebody on our net
messes with their browser settings, the best they can expect is that their
access remains unchanged. More likely, the browser will fail to connect to
the Internet at all.

Security controls must remain under control. Pretty much by definition, if
you've put a client on somebody's desktop, you've lost (some) control of it,
at least given today's operating system environment. Thus, the network
security must *not* depend on the client.

phil reed, libbey inc.  reedpc@libbey.com


Re: How to bypass those pesky firewalls (Jackson, RISKS-20.01)

Chris DeLashmutt <cdelashm@geocities.com>
Fri, 02 Oct 1998 10:03:49 -0400
First, Internet Explorer can (and should) be set up in such a way that users
don't have access to change those kinds of security parameters.  A small
administrative task can help to slightly lower the risks of using the
Internet.

Second, companies shouldn't just allow free reign to every site on the
internet.  Our location (only about 200 people) has implemented a pretty
good method of limiting access to sites from our internal network.  We
actually disallow all but a few select sites for our people to get to on the
web through our proxy server.  Tyrannical as it may seem, it does work
pretty well.  The administration required at the startup was pretty high in
the beginning, but it is seldom that we have to change the allowances.

Finally, I think relying on a piece of application software, like a web
browser, to handle your internet security seems like a pretty risky
venture. Firewalls are generally single point software/hardware solutions
that block access at the network layer (OSI model).  It seems to me that the
application-layer security features in Internet Explorer are meant more as
an augmentation or refinement to the lower level security provided by a
"Firewall".

    Summary
        Any serious approach to Internet security has to be comprehensive.
    --Microsoft White Paper: Internet Explorer Security.
    http://www.microsoft.com/windows/ie/security/ie4security.htm
    September 16, 1998


Information Security Educators Mailing List

Fred Cohen <fc@all.net>
Sun, 27 Sep 1998 11:34:23 -0700 (PDT)
Introducing:
    The Information Security Educators Mailing List
    secedu@all.net

Our mission is to provide an open forum for educators in information
security to discuss issues related to courses, curriculum, books, and
other education-related items.  It is also a forum to allow vendors and
providers of educational materials to provide information (but not
advertisements) to educators and a forum for those educators to discuss
those materials.

List Rules:

Rule 1: The mailing list is fully moderated.  Mailings are sent out no more
than once per day, often not for several days, and sometimes it takes even
longer.  Submissions may be edited for size, to remove garbage in headings,
excessive signature lines, and so forth.

Rule 2: You can sign up or off the list in the same way as you make
submissions to the list.  Because we are fully moderated, it all goes to the
same place anyway.

Rule 3: Be polite and respectful or it won't be published.

To submit, sign-up, or remove email to:

        secedu@all.net

The mailing list's Web page is:
        http://all.net/edu/index.html

I try to find interesting pointers for my readers and place them here.  If
you would like to add a pointer to your Web page, submit it to the list and
we will consider your submission.

Please report problems with the web pages to the maintainer

Top