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 62

Monday 9 March 1998

Contents

o New HDTV signal shuts down Baylor heart monitors
John P McGraw
o The anti-crypto rhetoric ratchets up
Carl Ellison
o Atlantic Monthly article on "The Lessons of ValueJet 592"
Andrew Patrick
o RISKS of reverse telephone lookup systems
Matt Welsh
o Re: CyberAttack on the Pentagon
Mike Perry
o NAB accidentally spams its membership list
Ed Fischer
o Update on Windows NT denial-of-service attacks
Matt Welsh
o Re: Auckland power outage recovery risks
R.J. Burkhart
o Newspaper spelling checker forgets Europe
Scott Ruthfield
o Re: Year 2100 compliance?
Jonathan de Boyne Pollard
o The Deception ToolKit
Fred Cohen
o 5th ACM Conference on Computer and Communications Security final CFP
Gene Tsudik
o Formal Methods for Industrial Critical Systems, CFP
Diego Latella
o Telecommunications Policy Research Conference 98, CFP
Juan F. Riveros
o Info on RISKS (comp.risks)

New HDTV signal shuts down Baylor heart monitors

"Mcgraw, John P" <john.mcgraw@eds.com>
Thu, 5 Mar 1998 11:26:43 -0600
On 26 Feb 1998, WFAA TV (Channel 8) in Dallas turned on their new digital
HDTV signal.  As a result, 12 heart monitors stopped working in a Baylor
University Medical Center heart surgery recovery unit; they happened to be
on the same frequency.  The monitors were made in the mid-1980s, and were
slated for replacement.  [But the patients weren't?]  In the interim, WFAA
has stopped transmitting -- because there are no commercial receivers yet
anyway.  [Source: * Dallas Morning News*, 5 Mar 1998.  PGN Abstracting]

John P. McGraw, CISSP, EDS Security, Technology Planning
5400 Legacy Drive, Plano, TX  75024

  [Also noted by many others.  TNX to all of you.  PGN]


The anti-crypto rhetoric ratchets up

Carl Ellison <cme@cybercash.com>
Fri, 06 Mar 1998 20:21:26 -0500
An excerpt from a transcript of Louis Freeh, addressing Congress:

> ENCRYPTION
>
> ONE OF THE MOST DIFFICULT CHALLENGES FACING ALL OF LAW ENFORCEMENT IS HOW
> RAPIDLY TERRORISTS AND CRIMINALS ADOPT ADVANCED TECHNOLOGIES TO THWART LAW
> ENFORCEMENT'S ABILITY TO INVESTIGATE THOSE WHO WISH TO DO HARM TO OUR
> NATION AND ITS CITIZENS. THAT IS WHY ENCRYPTION IS ONE OF THE MOST
> IMPORTANT ISSUES CONFRONTING LAW ENFORCEMENT.

Really, Louis?

Rum runners used strong crypto in the 1920's, hiring their own
cryptographers to create codes and ciphers stronger than those in use by
governments of the day -- in order to communicate with their ships at sea
and tell them when/where to land to avoid the cops.  That's a major head
start.  With all this rapid adoption, all criminals in the world should be
using strong crypto of their own invention by now.

How come Dorothy Denning didn't find any significant use of crypto by
criminals in her survey of law enforcement officers?

Modern criminals are too lazy to roll their own, maybe?

They could have bought encrypting telephones in the 1980's from Crypto AG in
Switzerland.  They were expensive, but they were reasonable.  They were too
expensive for us honest citizens, but if a criminal doesn't have money to
throw around, he's not very interesting to you either, right?

They could have bought even stronger encrypting cellular telephones for a
few thousand dollars from Cylink, in the early 1990's.  Did they?  Dorothy
didn't find it.

They could have started using PGPFone for free when it came out years ago.
Did they?

This is only one source of inaccuracy in your presentation, but it hits me
especially strongly since it seems designed to create an impression of
impending doom, perhaps to justify emergency powers as one might have when
starting a war.  The civilians of this world have invented and used strong
cryptography for over 3000 years, and the citizens of this country have had
the right to use that strong cryptography in order to attempt to keep
secrets from the government for the entire history of this country.  Trying
to change that is a major change in the balance of power.

[See <http://www.clark.net/pub/cme/html/civ-own-crypto.html> for details.]

I realize that we voted to give you the gun to carry and we thank you in law
enforcement for risking to be shot.  However, the fact that you carry the
gun does not mean that we citizens need to obey you or even to give you
extra powers.  If anything, the fact that you are empowered to carry guns
means that you should have fewer powers than normal, unarmed citizens, IMHO.

Carl M. Ellison, CyberCash, Inc., 207 Grindall Street, Baltimore MD 21230-4103
(410) 727-4288  cme@cybercash.com   http://www.clark.net/pub/cme


Atlantic Monthly article on "The Lessons of ValueJet 592"

"Andrew Patrick" <andrew@calvin.dgbt.doc.ca>
Fri, 6 Mar 1998 11:09:33 -0500
There is an interesting article in the March issue of Atlantic Monthly
called "The Lessons of ValueJet 592" by William Langewiesche.

http://www.theatlantic.com/issues/98mar/valujet1.htm

SUMMARY:  "As a reconstruction of this terrible crash suggests, in complex
systems some accidents may be "normal" -- and trying to prevent them all
could even make operations more dangerous."

The author makes an interesting distinction between "procedural" (something
was done wrong), "engineered" (something was built wrong), and "system"
accidents.  He argues that system accidents arise from increasingly complex
organizations and activities, such as commercial airlines, and may be
difficult or impossible to prevent.

Andrew Patrick, Ph.D., Communications Research Centre, Ottawa CANADA
andrew@calvin.dgbt.doc.ca http://debra.dgbt.doc.ca/~andrew 1-613-990-4675


RISKS of reverse telephone lookup systems

Matt Welsh <mdw@now.CS.Berkeley.EDU>
6 Mar 1998 21:41:23 GMT
Two sites, AT&T Lab's AnyWho (http://www.anywho.com:81/telq.html) and
555-1212.com (http://www.555-1212.com/whte_us.htm), now provide reverse
telephone lookup searches for US numbers on the Web. The AnyWho service is
somewhat more powerful than 555-1212.com: not only is exact telephone number
lookup available, but _inexact_ searches as well (you can search on
telephone number substrings as prefix or suffix - e.g., all numbers of the
form 510-644-xxxx).  [WILL THAT GET CENSORED?  PGN]

A typical telephone lookup on AnyWho will consist of the name and street
address of the person/business owning the number, a link to a map of the
address, and (in some cases) the ability to click on the street name and
return a list of all names, addresses, and telephone numbers of other people
living on the same street! Talk about "there goes the neighborhood..."

There is also a link which allows you to update or remove the entry -- in
order to confirm the change, you must call the 1-800 number provided from
the telephone corresponding to the entry, and enter a confirmation number
listed on the web page. Changes to the database are immediate.  One may also
send in a signed update request via U.S. Mail. It's not clear whether a
"change of number" request must be phoned in from the new number of the old
number -- the former means that virtually anyone can redirect listings to
their number, and the latter makes it difficult to change a listing after
the fact (as well as allows the owner of a recycled number to update someone
else's listing).

The RISKS? Well, privacy risks are obvious -- this system appears to be a
real boon to prank callers, stalkers, and anyone with a Caller ID device or
1-800 number. In the latter case geographic data could be collected on every
caller, and more advanced searches could correlate this information with
other data available on the Net about the caller.

M. Welsh, mdw@cs.berkeley.edu, UC Berkeley Computer Science Division


Re: CyberAttack on the Pentagon (Murray, RISKS-19.61)

<Mike_Perry@DGE.ceo.dg.com>
Wed, 4 Mar 1998 21:01:56 est
>That not only will secure products not be favored in the market
>place, they are often punished.  [...]

This doesn't just apply to computer systems.  Try buying a car that has even
a remotely decent security system as standard - in consumer tests most new
cars can be broken into and started by a 'thief' in times measured in
seconds, not minutes.

Nor does safety sell - the car I drive, (which won the European Car Of The
Year award in 1996) comes as standard with goodies like alloy wheels and
aircon, but antilock brakes are an optional extra.

Just as legislation was needed to force car makers to fit, and then drivers
to use, safety devices, so legislation will be needed to force makers and
users of computer systems to fit and use good security.


NAB accidentally spams its membership list

<Ed Fischer>
Wed, 4 Mar 1998 15:52:29 EST
Through an apparently misconfigured mailing list server, the National
Association of Broadcasters (NAB) this week created an e-mail nightmare for
more than a thousand of its members.

On 3 Mar 1998, the Convention department sent out -- unsolicited --
advertising messages for its upcoming annual meeting to about 1,100 members.
Included in the mailing were instructions for being removed from the list.
However, the address given in those instructions merely remailed the
"remove" request back to all of the other addresses on the list.

Early responders are now being deluged with responses from confused
recipients, as well as with "bounce" messages from another approximately 800
invalid addresses which were on the NAB's list.

The NAB's Tom Adamson said the list server has been turned off, although he
acknowledged that the damage has already been done.

Ed Fischer, Director, Information Systems
Post-Newsweek Stations, Inc., Hartford, Connecticut


Update on Windows NT denial-of-service attacks

Matt Welsh <mdw@now.CS.Berkeley.EDU>
5 Mar 1998 19:13:55 GMT
Last night, Microsoft posted a security bulletin at
    http://www.microsoft.com/security/netdos.htm
describing the network denial-of-service attacks on Windows NT and 95
systems, which is commonly referred to as the "New Tear", "Bonk", or
"Boink" attacks. The fix to the problem released in NT 4.0 Service Pack 3,
and patches for Windows 95 are available.

>From the Microsoft Knowledge Base information on this problem: "The modified
teardrop attack works by sending pairs of deliberately constructed IP
fragments which are reassembled into an invalid UDP datagram. Overlapping
offsets cause the second packet to overwrite data in the middle of the UDP
header contained in the first packet in such a way that the datagrams are
left incomplete."

Interestingly, the information on Microsoft's web pages seems to be somewhat
conflicting, and it's difficult to tell exactly which of the multiple known
NT TCP/IP stack bugs are being addressed here, and which patches are needed
to prevent them.

M. Welsh, mdw@cs.berkeley.edu, UC Berkeley

  [For the CERT special edition of summary reports on denial of service
  attacks, see      ftp://ftp.cert.org/pub/cert_summaries/ .  PGN]


Re: Auckland power outage recovery risks (Gutmann, RISKS-19.61)

"RJBurkhart[ECip]" <BoBURK_ECip_LTD@compuserve.com>
Fri, 6 Mar 1998 19:04:14 -0500
After almost two weeks, attempts to restore power on 3 Mar 1998 failed
again, with officials predicting downtown Auckland will be blacked out for
another 10 weeks.  At least 2,000 businesses are affected.  [PGN Abstracting
from various articles, including www.startribune.com, which has power.]

R.J. (Bob) Burkhart  :  Management Support Solutions, Inc.
Twin Cities, MN  55431-1774  :  73520.3701@compuserve.com


Newspaper spelling checker forgets Europe

Scott Ruthfield <indigo@owlnet.rice.edu>
Mon, 9 Mar 1998 02:02:48 -0600 (CST)
While the follies of spelling checkers is well-known, I thought this
deserved special mention. File this one in the irony department: in the 3/9
_Houston Chronicle_, in an article with the headline "Panel to confront
math, science woes of children," the following phrase appears:

  "... 21-nation study, in which U.S. 12th-graders ranked 19th in math,
  outperforming only Cypress and South Africa."

(If the problem isn't clear, note the fourth-from-last word.)

The risks here are multifold, including just looking foolish. One would
assume that a newspaper's spelling checker would include foreign countries
(assuming the editors got it right, of course).

Note that the byline on this article is the Los Angeles Times, so this
problem could have originated there and propagated.

Scott Ruthfield, Rice University, Graduate Student, Computer Science


Re: Year 2100 compliance? (Shimomura, RISKS-19.60)

Jonathan de Boyne Pollard <jdebp@donor2.demon.co.uk>
09 Mar 98 11:02:56 +0000
Tsutomu Shimomura <tsutomu@ariel.sdsc.edu> quoted the information on the Y2K
firmware fix for the IBM PC RTC from American Megatrends
(http://www.amibios.com/support/2000.html) and noted that the documentation
implies that there will be a Year 2100 Problem.

However, it should be noted in order to keep this in perspective that the
windowing fix employed by many BIOS vendors (and also by some operating
systems vendors -- IBM's OS/2 Warp includes this same windowing fix in its
CLOCK01.SYS and CLOCK02.SYS device drivers, for example) is quite capable of
being modified after the year 2000 and before the year 2100, substituting
"21" for "20".  Sliding the window like this every 100 years should thus be
possible.  Given the turnover in BIOS code, it also seems to be likely.

It is also important to consider the possible variations on the windowing
fix used.  If the algorithm is "if the year byte is less than 80, write the
value 20 to the century byte", then it will fail in 2100, as suggested.
However, an alternative, and equally valid, scheme is "if the year byte is
less than 80, write the value 20 to the century byte, otherwise write the
value 19".  This scheme fails 20 years earlier, in 2080.

Although the former algorithm may seem the one wanted, the latter algorithm
is a more likely one for two reasons.  First, it is easy and intuitive to
code in C and C++ ("century = (year < 80) ? 20 : 19").  Second, it allows
for the century to go backwards.  This second point may seem bizarre, until
one realises that the BIOS testing methodologies for "Year 2000 correctness"
almost always do *not* reflect exactly what will happen in the year 2000.
When the year 2000 comes around, the calendar time will only go forward.
But the testing procedures employed *now*, *before* the year 2000, involve
setting the clock forward and *then* resetting it *back* to the current date
and time once the test is over.  Obviously, whilst a BIOS which works in the
forward direction is acceptable, and will quite acceptably deal with what
will actually happen in the PC's RTC come the year 2000; if the machine ends
up with the current date and time stuck in the 21st century after a program
that tests the BIOS for year 2000 compliance has been run, the BIOS will be
*perceived* by many as *not* dealing properly with the year 2000 problem in
the PC's RTC chip.

IBM's CLOCK02.SYS in OS/2 Warp is one piece of software that I can verify
*does* use the latter algorithm, and thus as predicted both (1) applies the
fix to the century byte in the PC RTC's NVRAM in both directions and (2)
breaks down in the year 2080.  This highlights, incidentally, one of the
more ironic requirements for testing one's BIOS for the presence of an RTC
fix: one needs an operating system that *isn't* Year 2000 compliant itself.
One cannot run programs for testing the BIOS on OS/2 Warp, because by the
time that the operating system has booted and the test programs are run, the
RTC fix in OS/2's clock device driver has overridden whatever RTC fix was
applied by the BIOS.

Which brings us back to American Megatrends, and its claim that its BIOS RTC
fix will work correctly until the year 2099.  Would any RISKS readers with a
Year 2000 compliant AMI BIOS, and an operating system that *isn't* Year 2000
compliant, care to check what AMI BIOS does come the year 2080 ?

 > JdeBP <


The Deception ToolKit

Fred Cohen <fc@all.net>
Mon, 9 Mar 1998 05:52:28 -0800 (PST)
I would like to announce and introduce a new security tool available for free
from over the Internet - The Deception ToolKit - available from http://all.net/

The Deception ToolKit (DTK) is a toolkit designed to give defenders a couple
of orders of magnitude advantage over attackers.

The basic idea is not new. We use deception to counter attacks. In the case
of DTK, the deception is intended to make it appear to attackers as if the
system running DTK has a large number of widely known vulnerabilities. DTK's
deception is programmable, but it is typically limited to producing output
in response to attacker input in such a way as to simulate the behavior of a
system which is vulnerable to the attackers method. This has a few
interesting side effects:

  It increases the attacker's workload because they can't easily tell
  which of their attack attempts works and which fail. For example, if
  an attack produces what appears to be a Unix password file, the
  attacker would normally run "Crack" to try to break into the system.
  But if the password file is a fake, it consumes the attackers time and
  effort to no result.

  It allows us to track attacker attempts at entry and respond before
  they come across a vulnerability we are susceptible to. For example,
  when the attacker tries to use a known Sendmail attack against our
  site, we record all of their entries to track their techniques. With
  this deception in place, we have no problem picking up port scans,
  password guessing, and all manner of other attack attempts as they happen.

  It sours the milk - so to speak. If one person uses DTK, they can see
  attacks coming well ahead of time. If a few others start using it, we
  will probably exhaust the attackers and they will go somewhere else to
  run their attacks. If a lot of people use DTK, the attackers will find
  that they need to spend 100 times the effort to break into systems and
  that they have a high risk of detection well before their attempts succeed.

  If enough people adopt DTK and work together to keep it's deceptions
  up to date, we will eliminate all but the most sophisticated
  attackers, and all the copy-cat attacks will be detected soon after
  they are released to the wide hacking community. This will not only
  sour the milk, it will also up the ante for would-be copy-cat
  attackers and, as a side effect, reduce the "noise" level of attacks to
  allow us to more clearly see the more serious attackers and track them down.

  If DTK becomes very widespread, one of DTK's key deceptions will
  become very effective. This deception is port 507 - which we have
  staked a claim for as the deception port. Port 507 indicates whether
  the machine you are attempting to connect to is running a deception
  defense. Naturally, attackers who wish to avoid deceptive defenses
  will check there first, and eventually, simply running the deceptive
  defense notifier will be adequate to eliminate many of the attackers.
  Of course some of us defenders will not turn on the deception
  announcement message so we can track new attack attempts by those who
  avoid deceptive defenses, so... the attacker's level of uncertainty
  rises, and the information world becomes a safer place to work.

Your positive and helpful comments are appreciated.  FC

Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:510-454-0171


5th ACM Conference on Computer and Communications Security final CFP

Gene Tsudik <tsudik@pollux.usc.edu>
Mon, 9 Mar 1998 09:05:09 -0800 (PST)
                          Final Call for Papers
                          Fifth ACM Conference on
                    Computer and Communications Security
                          San Francisco, California
                             November 3-5, 1998
                           Sponsored by ACM SIGSAC

Papers offering novel research contributions in any aspect of computer
security are solicited for submission to the Fifth ACM Conference on
Computer and Communications Security. Papers may present theory, technique,
applications, or practical experience on topics including but not limited to

 access control        authentication          accounting and audit
 mobile code security  applied cryptography    data/system integrity
 cryptographic         electronic commerce     intrusion detection protocols
 key management        privacy and anonymity   intellectual property protection
 information warfare   secure networking       secure operating systems
 viruses and worms     security management     distributed systems security
 database security     smart-cards and secure  security verification
                       PDAs

Paper submissions due: April 3, 1998
Panel proposals due: May 1, 1998

General chair:            Li Gong, JavaSoft
Program chair:
  Mike Reiter, AT&T Labs, Room A269, 180 Park Avenue
  Florham Park, NJ 07932-0971 USA, phone: +973-360-8349

For more information, visit http://www.research.att.com/~reiter/ccs5
            or  http://www.isi.edu/~gts/cfp.html


Formal Methods for Industrial Critical Systems, CFP

Diego Latella <d.latella@cnuce.cnr.it>
Mon, 9 Mar 1998 16:06:52 +0100 (MET)
Journal of Science of Computer Programming
Editor-in-Chief: Prof. Michel Sintzoff

SPECIAL ISSUE ON
Formal Methods for Industrial Critical Systems

Guest Editors: Jorge Cuellar, Stefania Gnesi, Diego Latella
 <><> C A L L   F O R   P A P E R S  <<<<

The Journal of Science of Computing Programming has planned a special issue
on the use of formal methods in the industry for the development of critical
systems.  This special issue is promoted by the Working Group on Formal
Methods for Industrial Critical Systems of the European Research Consortium
on Informatics and Mathematics (ERCIM - http://www-ercim.inria.fr/).

Guest Editors: Jorge Cuellar (Siemens), Stefania Gnesi (CNR-IEI,FMICS),
Diego Latella (CNR-CNUCE,FMICS)

IMPORTANT DATE: Deadline for submission : April 30th, 1998

For guidelines, contact
  S. Gnesi, CNR - Ist. Elaborazione dell'Informazione,
  Via S. Maria 46,  I56126 Pisa - ITALY
  phone: +39-50-593489, fax  : +39-50-554342  gnesi@iei.pi.cnr.it


Telecommunications Policy Research Conference 98, CFP

"Juan F. Riveros" <riverosq@umich.edu>
Wed, 4 Mar 1998 12:53:31 -0500 (EST)
CALL FOR PAPERS
The Twenty-Sixth Annual TELECOMMUNICATIONS POLICY RESEARCH CONFERENCE
3-5 October 1998, Radisson Mark Plaza, Alexandria, Virginia
  http://www.si.umich.edu/~prie/tprc/

The Telecommunications Policy Research Conference (TPRC) is an annual forum
for dialogue among scholars and decision-makers from the public and private
sectors engaged in communication and information policy.  The purpose of the
conference is to acquaint policymakers with the best of recent research and
to familiarize researchers with the knowledge needs of policymakers and
industry.  The TPRC program is assembled from submitted abstracts, invited
papers and proposals for complete sessions.

TPRC is now soliciting research papers or session proposals for presentation
at its 1998 conference.  Papers should be based on current theoretical
and/or empirical research relevant to the making of communication and
information policy, and may be from any disciplinary perspective.  TPRC
welcomes national, international, or comparative studies.  Subject areas of
particular interest include, but are not limited to:

*   1996 Telecom Act
*       Universal Service
*   Wireless Services
*       Unintended Consequences of Regulation
*   Unbundling the Local Loop
*       State Regulation
*   Convergence:  Technological Developments and Regulatory Implications
*       Privacy (Crypto, Anonymity, Personal Data)
*   Intellectual Property
*       Content Control
*   Information Infrastructure Security
*       Taxation of Internet Services
*   Antitrust, Concentration and Mergers
*       Household Information Environments
*   Internet and Telephone Numbers and Names
*       Internet Jurisdiction
*   Software Competition
*       Internet/Intranet Effects on Organizations
*   Electronic Commerce
*       Communication Reform in Developing Countries
*   Spectrum Allocation and Auctions
*       New Satellite Systems
*   Infrastructure Investment
*       Pirate Broadcasting
*   Transition to Digital TV
*       Competitive Models of Mass Media
   [Lots of RISKS issues there!
   Check their Web site for instructions on submissions.
   Sorry, I don't seem to have the due date.  PGN]

Inquiries to Dawn Higgins, Telecommunications Policy Research Conference,
P.O. Box 19203, Washington, DC 20036 1-202-452-9033

Please report problems with the web pages to the maintainer

Top