The RISKS Digest
Volume 18 Issue 82

Friday, 14th February 1997

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


Does CNID really give you anonymity?
48-bit RC5 bites the dust
NASD loses records on 20,000 brokers
Risks of technical illustrations
Bear R Giles
NT Attacks
Christopher Klaus
Hostile ActiveX Control demonstrated
Klaus Brunnstein
More on the risks of ActiveX
Joe Meadows
Digital cameras may explode
Mark Seecof
Cell phones and car accidents
13 Feb 1997
Risk of IRS Outsourcing Processing
John Pescatore
Re: Will-o'-the-w-ISP! More on AOL, Cyber Promotions
Sean Eric Fagan
Re: Word virus/C++ committee
Andrew Koenig
Re: Y2K? Y1990 strikes again!
Mark Brader
Info on RISKS (comp.risks)

Does CNID really give you anonymity?

"Peter G. Neumann" <>
Fri, 14 Feb 97 11:02:50 PST
>From the time of an upgrade on 1 Jan 1997 until 26 Jan 1997, the mechanisms
that are supposed to block the Calling Number ID (misnamed Caller ID)
service FAILED in the 510 and 415 areas codes.  As many as 516 businesses
with PBXs were able to obtain calling numbers despite presumed blocking.
(Something on the order of 50% of the subscribers are rumored to have
requested blocking.)  [Source: *San Francisco Chronicle*, 14 Feb 1991.
Watch out if you thought you were sending anonymous tele-valentines to
companies with PBXs!]

48-bit RC5 bites the dust

"Peter G. Neumann" <>
Fri, 14 Feb 1997 8:02:49 PST
In RISKS-18.81, we noted that Ian Goldberg of U.C. Berkeley had cracked the
40-bit RC5 in 3.5 hours — the first step in the RSA Data Security challenge
posed on 28 Jan 1997.  The second step was taken on 10 Feb 1997 by Germano
Caronni, a graduate student at the Swiss Federal Institute of Technology.
Caronni (with a lot of help from his friends) has recovered the key for text
encrypted with 48-bit RC5, with the help of 3,500 computers and attaining an
peak rate of 1.5 trillion keys searched per hour, over a period of 312
hours.  A press release from RSA (given some circulation in the media) on
gives some details.  Close to the median expected effort, about 57% of the
key space was exhausted.  The Caronni team is now working on the next
challenge, RC5-56.  It is easy to clone yourself through virtual
replication.  [In this case, the team has a lot of Caronnis!]

NASD loses records on 20,000 brokers

"Stern, just Stern" <>
Fri, 7 Feb 1997 09:16:18 -0500 (EST)
The National Association of Securities Dealers (NASD) is the self-regulatory
organization that oversees broker-dealers and their employees in the United
States. It maintains a database of brokers and any disciplinary action taken
against them, a database that the public can access by calling Disclosure,
Inc. (1-800-638-8241 in the U.S.)  It's a good idea before doing business
with a new broker-dealer or a new broker to call Disclosure to check if they
have been a problem for other investors in the past.

Unfortunately, the NASD has purged 20,000 records from their files.
According to the Associated Press,

  The NASD said it inadvertently issued faulty guidelines telling
  clerks that "revised'' rules allowed them to purge a broad range of
  disciplinary data from the central registration depository.

The risks are (at least) threefold.  First, that investors will not have
access to this valuable information and that people may deal with
unscrupulous brokers as a result.  Second, other regulatory agencies that
rely upon the NASD's record will not be able to perform their functions.
Thirdly, the NASD itself will not be able to refer to past disciplinary
records on these brokers in deciding penalties in response to new

The NASD believes it will be able to reconstruct its records in a couple of

Risks of technical illustrations

Bear R Giles <>
Fri, 14 Feb 1997 14:25:12 -0700 (MST)
In this month's _Scientific American_ there is a section on the Internet.
The first full-page graphic has a flow-chart-like diagram over the user's
monitor.  One line near the top illustrates the risks of technical
illustrations without careful review by a knowledgeable person:

   (Conditional box)
   "Already open for exclusive use and not the supper user?"

This error isn't as bad as the _Dr Dobb's_ cover illustration of a
"red-black" tree where the elements of the tree weren't sorted (*oops*), or
another "photorealistic" depiction of a lightbulb that could never be
screwed into any socket on this planet (due to the image being flipped
during layout), but it's still enough for me to wonder how much care went
into the other graphics in the article.

At least all of the countries in the European/middle Eastern map appear to
be present.  (Unlike a major newsweekly that attempted a very creative
approach to regional peace a few years back. :-)

Bear R Giles  [Pay to the Bear-R? or the Bare "R"?  PGN]

  [I had to point out in my role as panel chair for the cryptographer's
  panel at the January 1997 RSA Data Security Conference that the artist who
  rendered the giant version of the standard RSA two-key logo had neglected
  to realize that the two keys were supposed to fit together.  They did not.

NT Attacks

Christopher Klaus <>
Wed, 12 Feb 1997 09:54:26 -0500 (EST)
Summary of recent attacks that have become more well known.

These attacks have been discussed on NT Security mailing list but the
knowledge about them has not spread widely outside of the security mailing
list circle: NT CPU Port Attacks, NT DNS Denial Attack, NT Trojan Password

* NT CPU Port Attacks

On NT 3.51 and NT 4.0, there are TCP ports that are open that when an
attacker connects to them, types in some random characters, and drops
the connection, the CPU on the machine goes to 100% usage.

For example, connect to TCP port 135 (RPC server), type in
"thiswilldoacpuattack" and disconnect.  Then check the CPU usage.  The
CPU will be at 100% usage and the machine will be noticeably slower.  It
is possible to kill and restart the rpcss process to stop the CPU usage.

DNS (TCP port 53 & 65589) is susceptible to this attack as well.  In
16-bits, port 65589 is port 53.  65589 = 0x10035. 53 = 0x35


On NT 4.0, there is filter capability to block all TCP ports except
needed critical ones.  You may want to enable that.

There is a hotfix available on

There is a DNS beta that fixed the random character on the port attack.
It is available via ftp from, log on as DNSBeta with
a password of DNSBeta. In the /service_pack3/x86 directory there is a
file called DNS.EXE dated 1/26/97.

* NT DNS Denial Attack

If an attacker spoofs a response that the DNS never requested, DNS will
terminate.  There is an advisory on this available at


Currently, Microsoft is working on a solution.

* NT Trojan Password DLL

On NT 4.0 and 3.51, there is some entries in the registry that point to
a DLL that does not exist, that lets an attacker to put their own DLL in
place.  There is one DLL that will capture all password changes into a
file, so an attacker can obtain any passwords that get changed pertaining to
passwords residing on that machine.  Ideally for an attacker, placing the DLL
on a domain controller machine where most password changes can take place may
produce the greatest amount of password information.

More information is available with source code for the password changer
DLL at:
or Knowledge Base article


To defend against this type of Trojan attack is to protect
access to your registry fiercely. A routine part of your security
maintenance checks should be to take a close look at this registry key:

          HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\Notification Packages

Make sure that it does not contain any strange entries. NT 4.0 ships
with a single entry to this registry key:


If anything else in this registry entry, find out what it is and whether or
not it's needed. If not sure, remove the errant entry immediately.  Netware
requires the DLL, so if you already have installed the Netware DLL, then it
should have be installed admin-writable only.  If you do not have the
Netware DLL installed, make sure the register entry is blank.


Thanks to the posters of the NT Security Mailing list where almost all of
this information was derived.  To subscribe, send e-mail to
and within the body of the message, type: "subscribe ntsecurity".

Christopher William Klaus, Internet Security Systems, Inc., 41 Perimeter
Center #660, East,Atlanta,GA 30346  (770)395-0150

Hostile ActiveX Control demonstrated

Klaus Brunnstein <>
Tue, 11 Feb 1997 14:46:08 +0100
In a German TV show, 3 East German hackers (remotely linked to in/famous
Chaos Computer Club) demonstrated how inherent risks of Microsoft`s ActiveX
technology can expropriate naive users.

The hackers prepared a Web page attracting interest of surfers ("Becoming
millionaire in 5 minutes"). When this Webpage was contacted via Microsoft`s
Internet Explorer, an ActiveX control would be downloaded into the victims
computer. This control would access Quicken (a program aimed at assisting
electronic banking) to generate a transaction form to transfer some
electronic cheque to some account specified by the hackers; this cheque
would be trans- mitted with the next collective remittance. This may be the
first "Hostile Control" which has been demonstrated in the public (btw:
several Hostile Java Applets have appeared at several Internet sites; as
such Hostile Applets as well as experiments with Java "viruses" have not
been publicly displayed, the broad public tends to assume that Java Applets
are "secure" :-).

According to some Microsoft expert, "all users should know" that ActiveX may
have such side-effects which may include sniffing of disks as well as remote
installation of software. A spokesman representing Microsoft Germany even
suggested to disable ActiveX if the system is used for purposes of
electronic fund transfer. Concerning general protective action against
malign effects of ActiveX, Microsoft suggests using its ActiveX
"certification" option: users should "only allow" remote access from
"trustworthy" programmers.  A 3-level scheme (low - medium -high) of trust
is supported. On "high", only controls with an "authenticode" are permitted;
no warning is given when such a code is detected. Any programmer can buy his
authenticode for 20 dollar.

Any risk? No risk if you regard Microsoft or its affiliated programmers as

Klaus Brunnstein (10 Feb 1997)

PS: concerning "trustworthiness": apart from many safety and security
problems, users owe Microsoft the deployment of the first Macro virus
(Concept.A), and the proliferation of several Wazzu`s which have escaped
from several Microsoft CD- ROMs and WWW pages to the "interested
public". Users will experience major problems with enhanced macro viruses to
work under Office 97, and users will see more platforms to be
attacked. Thanx to Microsoft :-)

More on the risks of ActiveX

Joe Meadows <>
Sun, 09 Feb 1997 10:34:18 +0000
While the security community has fully recognized the risk of accepting
controls from untrusted sources, it seems to have completely ignored a
secondary risk of an existing control being subverted in unexpected ways.
Perhaps all of the controls that come with MSIE are perfectly safe, and
can't be subverted in any way (no buffer overflows, no mistakes), but it
seems highly unlikely that _all_ controls are written so perfectly.

Since one is basically giving away control of ones desktop to a web author
by enabling ActiveX within a browser, many companies are avoiding the
technology like the plague. Filtering it out at ones firewall is hardly
effective, unless one were to parse through every HTML page and
automatically remove the components that drive ActiveX (i.e. VBscript, the
Object tag, etc). Not allowing ActiveX to be enabled in a web browser would
seem to be a minimum requirement, not allowing browsers that support ActiveX
would seem to be even better (and easier for a firewall implementation to
handle - if the firewall sees that the user agent supports it, it could
refuse to service it).

Until the vendor gives us more control over when/how a control gets _used_
(not just control over when they get downloaded), I'll personally avoid the
technology. I hope Dan Wallach's supposition that the vendors are working on
it is true, but if they are, they're keeping awfully quiet about it
(refusing to acknowledge that there even _is_ a problem). Of course, that's
nothing new. "Full disclosure" of security bugs has done more for improving
security in the last few years than 20 years of discussion about "risks" has
done (not to belittle the work done by the readers of _this_ mailing
list/newsgroup, I just wish vendors would recognize that todays risks are
tomorrows exploits).

Joe Meadows [as always, usual disclaimers in apply]

Digital cameras may explode

Mark Seecof <>
Wed, 12 Feb 1997 17:40:48 -0800
Eastman Kodak Company has announced a product safety recall for some of its
digital cameras because their battery packs overheat and rupture when
charged.  Only about 1900 "professional" cameras in the DCS 420 and 460, and
AP NC 2000 series are affected.  Kodak will handle replacement requests at
(800) 698-3324 in the USA or through Kodak representatives overseas.

This is barely a computer RISK.  Ordinary cameras usually have tiny
batteries and no provision for connection to mains power.  So long as
"digital" means "using lots of electrical power" portable digital devices
may pose physical risks that older technologies do not engender.

Mark S.

Cell phones and car accidents (Edupage, 13 Feb 1997)

Thu, 13 Feb 1997 13:35:26 -0500
Researchers at the University of Toronto say that drivers whose attention is
distracted while talking on a cellular phone are four times more likely to
be involved in an accident.  However, insurance companies do not plan to
raise insurance premiums, because accident rates have not increased overall.
The researchers also found little difference between the use of a receiver
or hands-free model of phone, indicating that the problem is one of mental,
rather than physical preoccupation. (*Toronto Globe & Mail*, 13 Feb 97, A1;
Edupage, 13 Feb 1997)

Risk of IRS Outsourcing Processing

John Pescatore <>
Fri, 07 Feb 1997 14:17:06 -0500
In RISKS-18.81 about the IRS axing the Tax System Modernization project, PGN
added a parenthetical comment:

<>Gross is proposing to contract out the processing of individual
  returns to commercial firms (which raises all sorts of privacy issues),
  although that is only a small portion of the processing demands.<<

This has shown up elsewhere, I guess expressing a concern that if the IRS
used commercial firms to process tax returns, the risks to taxpayer privacy
might *increase.* This concern must flow from a belief that a government
agency or employee is less likely to compromise the privacy of a return than
would a private sector employee.

Of course, the government agency usually has a monopoly on processing and
the government employee generally has little to fear as far as termination
of employment due to inapropriate handling of sensitive materials. So, I
think the motivation for meeting privacy standards is good deal stronger in
the private sector.

>From a privacy perspective, I don't think too many of us would want a
government agency preparing our tax returns, handling our checking account,
or storing the records of counseling sessions - yet we routinely rely on
commercial firms for those private matters.

The real risk of outsourcing such processing will be the realization that
there are no defined policy/procedures/standards for what constitutes proper
handling to maintain some level of privacy. If encryption is to be used, how
strong? etc.

John Pescatore, Trusted Information Systems, 15204 Omega Drive,
Rockville, MD 20850 301-947-7153, 301-527-0482 (fax)

Re: Will-o'-the-w-ISP! More on AOL, Cyber Promotions (RISKS-18.81)

Sean Eric Fagan <sef@Kithrup.COM>
Thu, 6 Feb 1997 20:19:02 -0800
>3. Cyber Promotions Inc got dinged twice this week.  .... federal court
>barred them from falsifying their FROM: addresses.  ...

I assume the last one refers to the settlement between CP and AOL.  That is,
unfortunately, not what it said.

The settlement AOL and CP signed onto says that CP will not be legally
barred from sending e-mail to AOL's customers, but that they may do so only
from a specified list of domains (five domain names, to be precise).  AOL
customers who wish to receive these messages (and AOL people assure me that,
strange as it may seem, there are some who do!) can do so by disabling the
PreferredMail blocking system.

The benefit to AOL, of course, is that they will no longer have to update
their list of blocked domains daily with whatever new domains CP came up
with (some of which were not real, and some of which weren't even valid

Cyberpromo delenda est!

Re: Word virus/C++ committee (Myers, RISKS-18.81)

Andrew Koenig <>
Mon, 10 Feb 1997 09:50:58 +0500
In RISKS-18.81, Nathan Myers talks about a Word virus that apparently got
loose during a recent meeting of the C++ standards committee.

I have a few more remarks to add:

    1. At the time of the meeting, Microsoft had had a program
       available for more than a year that would detect and
       remove such viruses.  Nevertheless, only a few committee
       members had that program installed on their machines.

    2. The present version of Word has automatic macro execution
       turned off by default, so such viruses cannot propagate
       without explicit user action.

    3. Troff has had the capability for similar viruses for many
       years.  I suspect that the reason it hasn't been a problem
       has been the relatively smaller number of users.

Once the existence of Word macro viruses became known, I think
Microsoft acted reasonably promptly to make a defense available.  Yes,
they should have been aware of the possibility before that, but
I think it's going a bit too far to say they deserve to be sued.
Lots of software companies have done worse.

Andrew Koenig

Re: Y2K? Y1990 strikes again!

Mark Brader <>
Sat, 8 Feb 97 20:19:23 EST
Never mind 2000, some people are still having trouble dealing with 1990.

A recent posting by Steve Lau in misc.transport.urban-transit refers to
certain tickets used for combined travel on BART and Muni, two transit
systems in the San Francisco area.  Among other problems, he reports that:

> the machines that dispense them can't print dates beyond 12-31-89.  All
> of the tickets come out dated 1987.  Last year they came out dated 1986.

And, yes, on at least one occasion it was claimed that his ticket was ten
years out of date!

Mark Brader,, SoftQuad Inc., Toronto

Please report problems with the web pages to the maintainer