precedence: bulk
Subject: RISKS DIGEST 18.82

RISKS-LIST: Risks-Forum Digest  Friday 14 February 1997  Volume 18 : Issue 82

  FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for further information, disclaimers, caveats, etc. *****

 Contents:
Does CNID really give you anonymity? (PGN)
48-bit RC5 bites the dust (PGN)
NASD loses records on 20,000 brokers (Stern)
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 (Edupage, 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)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Fri, 14 Feb 97 11:02:50 PST
From: "Peter G. Neumann" <[email protected]>
Subject: Does CNID really give you anonymity?

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!]

------------------------------

Date: Fri, 14 Feb 1997 8:02:49 PST
From: "Peter G. Neumann" <[email protected]>
Subject: 48-bit RC5 bites the dust

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!]

------------------------------

Date: Fri, 7 Feb 1997 09:16:18 -0500 (EST)
From: "Stern, just Stern" <[email protected]>
Subject: NASD loses records on 20,000 brokers

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
complaints.

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

------------------------------

Date: Fri, 14 Feb 1997 14:25:12 -0700 (MST)
From: [email protected] (Bear R Giles)
Subject: Risks of technical illustrations

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  [email protected]  [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.
 PGN]

------------------------------

Date: Wed, 12 Feb 1997 09:54:26 -0500 (EST)
From: Christopher Klaus <[email protected]>
Subject: NT Attacks

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
DLL.

* 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

Solution:

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
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP2/RPC-fix

There is a DNS beta that fixed the random character on the port attack.
It is available via ftp from rhino.microsoft.com, 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
http://www.iss.net/lists/general/0118.html

Solution:

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: ftp://ftp.iss.net/pub/lists/ntsecurity-digest.archive/v02.n114
or Knowledge Base article http://www.microsoft.com/kb/articles/q151/0/82.htm

Solution:

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:

         FPNWCLN

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.

Acknowledgments

Thanks to the posters of the NT Security Mailing list where almost all of
this information was derived.  To subscribe, send e-mail to [email protected]
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  http://www.iss.net/  (770)395-0150

------------------------------

Date:  Tue, 11 Feb 1997 14:46:08 +0100
From: Klaus Brunnstein <[email protected]>
Subject:  Hostile ActiveX Control demonstrated

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
"trustworthy".

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 :-)

------------------------------

Date: Sun, 09 Feb 1997 10:34:18 +0000
From: Joe Meadows <[email protected]>
Subject: More on the risks of ActiveX

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 risks.info apply]

------------------------------

Date: Wed, 12 Feb 1997 17:40:48 -0800
From: Mark Seecof <[email protected]>
Subject: Digital cameras may explode

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.

------------------------------

Date: Thu, 13 Feb 1997 13:35:26 -0500
From: [email protected]
Subject: Cell phones and car accidents (Edupage, 13 Feb 1997)

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)

------------------------------

Date: Fri, 07 Feb 1997 14:17:06 -0500
From: John Pescatore <[email protected]>
Subject: Risk of IRS Outsourcing Processing

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 [email protected] 301-947-7153, 301-527-0482 (fax)

------------------------------

Date: Thu, 6 Feb 1997 20:19:02 -0800
From: Sean Eric Fagan <[email protected]>
Subject: Re: Will-o'-the-w-ISP! More on AOL, Cyber Promotions (RISKS-18.81)

>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
domains).

Cyberpromo delenda est!

------------------------------

Date: Mon, 10 Feb 1997 09:50:58 +0500
From: Andrew Koenig <[email protected]>
Subject: Re: Word virus/C++ committee (Myers, RISKS-18.81)

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  [email protected]

------------------------------

Date: Sat, 8 Feb 97 20:19:23 EST
From: [email protected] (Mark Brader)
Subject: Re: Y2K?  Y1990 strikes again!

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, [email protected], SoftQuad Inc., Toronto

------------------------------

Date: 15 Aug 1996 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

------------------------------

End of RISKS-FORUM Digest 18.82
************************

You are viewing proxied material from gopher.quux.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.